idnits 2.17.1 draft-watson-sipping-nai-reqs-00.txt: -(33): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(90): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(93): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(102): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(106): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(116): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(117): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(119): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(123): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(124): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(127): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(128): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(131): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(132): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(207): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(248): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There are 18 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope of this document.' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 9. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 126 instances of too long lines in the document, the longest one being 159 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 123: '...ements such as �A trusted node SHALL...' RFC 2119 keyword, line 125: '... SHALL...�....' RFC 2119 keyword, line 157: '... A node SHOULD disregard Netw...' RFC 2119 keyword, line 160: '... MAY pass it on to oth...' RFC 2119 keyword, line 198: '...mechanism of 3.2 SHALL NOT be used i.e...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2002) is 8018 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 248 looks like a reference -- Missing reference section? '2' on line 251 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Mark Watson 3 Document: draft-watson-sipping-nai-reqs-00.txt Nortel Networks 5 Category: Informational 6 Expires November 2002 May 2002 8 Short term requirements for Network Asserted Identity 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 There is no requirement for identities identities asserted by a UA in 33 a SIP message to be anything other than the user�s desired alias. An 34 authenticated identity of a user can be obtained using SIP 35 authentication, however it is unlikely that the necessary Public Key 36 Infrastructure to facilitate this for UAs will be available soon. 38 A Network Asserted Identity is an identity obtained by a SIP network 39 intermediary as a result of an authentication process. This draft 40 describes short term requirements for the exchange of Network 41 Asserted Identities within networks of securely interconnected 42 trusted nodes and to User Agents securely connected to such networks. 44 General requirements for transport of Network Asserted Identities on 45 the Internet are out of scope of this draft. 47 Table of Contents 49 1. Introduction 50 SIP [1] allows users to assert their identity in a number of ways 51 e.g. using the From: header. However, there is no requirement for 52 these identities to be anything other than the users desired alias. 54 An authenticated identity of a user can be obtained using SIP 55 Authentication (or by other means). However, it is unlikely that the 56 necessary Public Key Infrastructure to globally facilitate this for 57 users will be available soon. 59 A Network Asserted Identity is an identity obtained by a SIP network 60 intermediary as a result of an authentication process. This may or 61 may not be based on SIP authentication. This draft describes short 62 term requirements for the exchange of Network Asserted Identities 63 within networks of securely interconnected trusted nodes and also to 64 User Agents with secure connections to such networks. 66 Such a network is described in this draft as a Trust Domain. These 67 short-term requirements provide only for the exchange of Network 68 Asserted Identitied within a Trust Domain. 70 General requirements for transport of Network Asserted Identities on 71 the Internet are out of scope of this draft. 73 2. Trust Domains 75 A Trust Domain for the purposes of Network Asserted Identity is a set 76 of SIP nodes (UAC, UAS, proxiesor other network intermediaries) that 77 are known to be compliant to SIP specifications for Network Asserted 78 Identity. 80 This document presents requirements for such specifications. 82 Trust Domains are constructed by human beings who know the properties 83 of the equipment they are using/deploying. In the simplest case, a 84 Trust Domain is a set of devices with a single owner/operator who can 85 accurately know the behaviour of those devices. 87 Such simple Trust Domains may be joined into larger Trust Domains by 88 bi-lateral agreements between the owners/operators of the devices. 90 We say a node is �trusted� (with respect to a given Trust Domain) if 91 it is a member of that domain. 93 We say that one node in the domain is �trusted by� another if: 95 (i) there is a secure connection between the nodes, AND 96 (ii) they have configuration information to indicate that they are 97 members of the same Trust Domain. 99 This most often applies to network intermediaries such as proxies in 100 the Trust Domain. 102 A �secure connection� in this context means that messages cannot be 103 read by third parties and cannot be modified or inserted by third 104 parties without detection (e.g. IPSEC, TLS etc.). 106 We say that a node, A, in the domain is �trusted by� a node, B, 107 outside the domain if: 109 (i) there is a secure connection between the nodes, AND 110 (ii) B has configuration information indicating that A is a member of 111 the Trust Domain. 113 This most often applies to a UA which trusts a given network 114 intermediary (e.g. its home proxy). 116 The term �trusted� (with respect to a given Trust Domain) can be 117 applied to a given node in an absolute sense � it is just equivalent 118 to saying the node is a member of the Trust Domain. However, the node 119 itself does not know whether another arbitrary node is �trusted�, 120 even within the Trust Domain. It does know about certain nodes with 121 which it has secure connections as described above. 123 With the definition above, statements such as �A trusted node SHALL 124 ...� are just shorthand for �A node compliant to this specification 125 SHALL...�. 127 Statements such as �When a node receives information from a trusted 128 node...� are NOT valid, because one node does not have complete 129 knowledge about all the other nodes in the trust domain. 131 Statements such as �When a node receives information from another 132 node that it trusts...� ARE valid, and should be interpreted 133 according to the criteria (i) and (ii) above. 135 Within this context, SIP signaling information received by one node 136 from a node that it trusts is known to have been generated and passed 137 through the network according to the procedures of the particular 138 specification set, and therefore can be known to be valid, or at 139 least as valid as specified in the specifications. 141 3. Transport of Network Asserted Identity 143 3.1 Passing of Network Asserted Identity within a Trust Domain 145 It shall be possible for one node within a Trust Domain to securely 146 pass a Network Asserted Identity to another node that it trusts. 148 3.2 Passing of Network Asserted Identity to entities outside a Trust 149 Domain 151 It shall be possible for a node within the Trust Domain to securely 152 pass a Network Asserted Identity to a node outside the trust domain. 154 This is most often used to pass a Network Asserted Identity directly 155 to a UA. 157 A node SHOULD disregard Network Asserted Identity received from a 158 node it does not trust. 159 Note that a node outside the Trust Domain receiving this information 160 MAY pass it on to other nodes. However, such information SHOULD NOT 161 be treated as valid, since nodes outside the Trust Domain are not 162 guaranteed to operate according to the Network Asserted Identity 163 specification, and so may have modified the Network Asserted 164 Identity. 166 4. Parties with Network Asserted Identities 168 4.1 Calling user 170 A Network Asserted Identity of the calling user shall be supported. 172 4.2 Called user 174 A Network Asserted Identity of the called user shall be supported. 176 4.3 Extensibility 178 It shall be possible to define further parties to whom Network 179 Asserted Identities may relate in future. 181 5. Types of Network Asserted Identity 183 Each party shall have at most one Network Asserted Identity. 185 It shall be possible for the capability to transport multiple 186 identities associated with a single party to be introduced in future. 188 6. Privacy of Network Asserted Identity 190 The means by which any privacy requirements in respect of the Network 191 Asserted Identity are determined are outside the scope of this draft. 193 It shall be possible to indicate that a Network Asserted Identity is 194 subject to a privacy requirement which prevents it being passed to 195 other users. 197 In this case, the Network Asserted Identity specification shall 198 require that the mechanism of 3.2 SHALL NOT be used i.e. a trusted 199 node shall not pass the identity to a node it does not trust. 200 However, the mechanism of 3.1 MAY be used to transfer the identity 201 within the trusted network. 203 It shall be possible to indicate whether the Network Asserted 204 Identity is private due to a request from the user/subscriber or for 205 another reason. 207 Note that �anonymity� requests from users or subscribers may well 208 require functionality in addition to the above handling of Network 209 Asserted Identities. Such additional functionality is out of the 210 scope of this document. 212 7. Next steps 214 It is proposed to rapidly specify a mechanism to meet the 215 requirements of this draft. 217 It should be noted that the mechanisms of [2] meet all the above 218 requirements (and some others). 220 8. Security considerations 222 The requirements in this draft are NOT intended to result in a 223 mechanism with general applicability between arbitrary hosts on the 224 Internet. 226 Rather, the intention is to state requirements for a mechanism to be 227 used within a community of devices which are known to obey the 228 specification of the mechanism and between which there are secure 229 connections. Such a community is known as a Trust Domain. 231 Such devices may be hosts on the Internet. 233 The requirements also support the transfer of information from a node 234 within the Trust Domain, via a secure connection to a node outside 235 the Trust Domain. 237 Use of this mechanism in any other context has serious security 238 shortcomings, namely that there is absolutely no guarantee that the 239 information has not been modified, or was even correct in the first 240 place. 242 9. IANA Considerations 244 This document does not have any implications for IANA. 246 10. References 248 [1] J. Rosenberg et al, �SIP: Session initiation protocol," draft- 249 ietf-sip-rfc2543bis-09.txt, February 27th, 2002. 251 [2] W. Marshall et al, "SIP Extensions for Caller Identity and th Privacy", draft-ietf-sip-privacy-04.txt, February 27 , 2002. 253 11. Acknowledgments 255 12. Authors� Addresses 257 Mark Watson 258 Nortel Networks (UK) 259 Maidenhead Office Park (Bray House) 260 Westacott Way 261 Maidenhead, 262 Berkshire Tel: +44 (0)1628-434456 263 England Email: mwatson@nortelnetworks.com 265 13. Full Copyright Statement 267 Copyright (C) The Internet Society (2002). All Rights Reserved. 269 This document and translations of it may be copied and furnished to 270 others, and derivative works that comment on or otherwise explain it 271 or assist in its implementation may be prepared, copied, published 272 and distributed, in whole or in part, without restriction of any 273 kind, provided that the above copyright notice and this paragraph are 274 included on all such copies and derivative works. However, this 275 document itself may not be modified in any way, such as by removing 276 the copyright notice or references to the Internet Society or other 277 Internet organizations, except as needed for the purpose of 278 developing Internet standards in which case the procedures for 279 copyrights defined in the Internet Standards process must be 280 followed, or as required to translate it into languages other than 281 English. The limited permissions granted above are perpetual and 282 will not be revoked by the Internet Society or its successors or 283 assigns. This document and the information contained 284 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 285 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 286 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 287 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 288 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 289 PARTICULAR PURPOSE."