idnits 2.17.1 draft-ietf-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 -(71): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(151): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(154): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(164): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(169): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(179): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(180): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(182): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(186): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(187): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(190): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(191): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(194): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(195): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(308): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(350): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(353): 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 21 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: ' 9. 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: ' 10. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 192 instances of too long lines in the document, the longest one being 15 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 107: '...ay Name. The URI MUST be meaningful to...' RFC 2119 keyword, line 111: '... in the URI, the URI MAY identify some...' RFC 2119 keyword, line 116: '... number MAY identify some spe...' RFC 2119 keyword, line 186: '...ements such as �A trusted node SHALL...' RFC 2119 keyword, line 188: '... SHALL...�....' (5 more instances...) 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 8011 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 350 looks like a reference -- Missing reference section? '2' on line 353 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-ietf-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 Digest 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 initially derived by a SIP 39 network intermediary as a result of an authentication process. This 40 draft 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...................................................2 50 2. Definitions....................................................3 51 2.1 Identity...................................................3 52 2.2 Network Asserted Identity..................................3 53 2.3 Trust Domains..............................................3 54 3. Generation of Network Asserted Identity........................5 55 4. Transport of Network Asserted Identity.........................5 56 4.1 Sending of Network Asserted Identity within a Trust Domain.5 57 4.2 Receiving of Network Asserted Identity withing a Trust Domain 58 ...............................................................5 59 4.3 Sending of Network Asserted Identity to entities outside a 60 Trust Domain...................................................5 61 4.4 Receiving of Network Asserted Identity by a node outside the 62 Trust Domain...................................................6 63 5. Parties with Network Asserted Identities.......................6 64 6. Types of Network Asserted Identity.............................6 65 7. Privacy of Network Asserted Identity...........................6 66 8. Next steps.....................................................7 67 9. Security considerations........................................7 68 10. IANA Considerations...........................................8 69 11. References....................................................8 70 12. Acknowledgments...............................................8 71 13. Authors� Addresses............................................8 72 14. Full Copyright Statement......................................8 74 1. Introduction 76 SIP [1] allows users to assert their identity in a number of ways 77 e.g. using the From: header. However, there is no requirement for 78 these identities to be anything other than the users desired alias. 80 An authenticated identity of a user can be obtained using SIP Digest 81 Authentication (or by other means). However, it is unlikely that the 82 necessary Public Key Infrastructure to globally facilitate this for 83 users will be available soon. 85 A Network Asserted Identity is an identity initially derived by a SIP 86 network intermediary as a result of an authentication process. This 87 may or may not be based on SIP Digest authentication. This draft 88 describes short term requirements for the exchange of Network 89 Asserted Identities within networks of securely interconnected 90 trusted nodes and also to User Agents with secure connections to such 91 networks. 93 Such a network is described in this draft as a Trust Domain and we 94 present a strict definition of trust and Trust Domain for the 95 purposes of this draft. These short-term requirements provide only 96 for the exchange of Network Asserted Identitied within a Trust 97 Domain. 99 General requirements for transport of Network Asserted Identities on 100 the Internet are out of scope of this draft. 102 2. Definitions 104 2.1 Identity 106 An Identity, for the purposes of this draft, is a URI, and optionally 107 a Display Name. The URI MUST be meaningful to the domain identified 108 in the URI when used as a SIP Request-URI. 110 If the URI is a sip: or sips: URI, then depending on the local policy 111 of the domain identified in the URI, the URI MAY identify some 112 specific entity, such as a person. 114 If the URI is a tel: URI, then depending on the local policy of the 115 owner of the number range within which the telephone number lies, the 116 number MAY identify some specific entity, such as a telephone line. 117 However, it should be noted that identifying the owner of the number 118 range is a less straightforward process than identifying the domain 119 which owns a sip: or sips: URI. 121 2.2 Network Asserted Identity 123 A Network Asserted Identity is an identity derived by a SIP network 124 entity as a result of an authentication process. 126 The authentication process used, or at least it�s 127 reliability/strength, is a known feature of the Trust Domain using 128 the Network Asserted Identity mechanism i.e. in the language of 2.3 129 below, it is defined in Spec(T). 131 2.3 Trust Domains 133 A Trust Domain for the purposes of Network Asserted Identity is a set 134 of SIP nodes (UAC, UAS, proxies or other network intermediaries) that 135 are trusted to exchange Network Asserted Identity information in the 136 sense described below. 138 A node can be a member of a Trust Domain, T, only if the node is know 139 to be compliant to a certain set of specifications, Spec(T), which 140 characterize the handling of Network Asserted Identity within the 141 Trust Domain, T. 143 Trust Domains are constructed by human beings who know the properties 144 of the equipment they are using/deploying. In the simplest case, a 145 Trust Domain is a set of devices with a single owner/operator who can 146 accurately know the behaviour of those devices. 148 Such simple Trust Domains may be joined into larger Trust Domains by 149 bi-lateral agreements between the owners/operators of the devices. 151 We say a node is �trusted� (with respect to a given Trust Domain) if 152 and only if it is a member of that domain. 154 We say that one node in the domain is �trusted by� another if and 155 only if: 157 (i) there is a secure connection between the nodes, AND 158 (ii) they have configuration information to indicate that they are 159 members of the same Trust Domain. 161 This most often applies to network intermediaries such as proxies in 162 the Trust Domain. 164 A �secure connection� in this context means that messages cannot be 165 read by third parties and cannot be modified or inserted by third 166 parties without detection. The level of security required is a 167 feature of the Trust Domain i.e. it is defined in Spec(T). 169 We say that a node, A, in the domain is �trusted by� a node, B, 170 outside the domain if and only if: 172 (i) there is a secure connection between the nodes, AND 173 (ii) B has configuration information indicating that A is a member of 174 the Trust Domain. 176 This most often applies to a UA which trusts a given network 177 intermediary (e.g. its home proxy). 179 The term �trusted� (with respect to a given Trust Domain) can be 180 applied to a given node in an absolute sense � it is just equivalent 181 to saying the node is a member of the Trust Domain. However, the node 182 itself does not know whether another arbitrary node is �trusted�, 183 even within the Trust Domain. It does know about certain nodes with 184 which it has secure connections as described above. 186 With the definition above, statements such as �A trusted node SHALL 187 ...� are just shorthand for �A node compliant to this specification 188 SHALL...�. 190 Statements such as �When a node receives information from a trusted 191 node...� are NOT valid, because one node does not have complete 192 knowledge about all the other nodes in the trust domain. 194 Statements such as �When a node receives information from another 195 node that it trusts...� ARE valid, and should be interpreted 196 according to the criteria (i) and (ii) above. 198 Within this context, SIP signaling information received by one node 199 FROM a node that it trusts is known to have been generated and passed 200 through the network according to the procedures of the particular 201 specification set Spec(T), and therefore can be known to be valid, or 202 at least as valid as specified in the specifications Spec(T). 204 Equally, a node can be sure that signaling information passed TO a 205 node that it trusts will be handled according to the procedures of 206 Spec(T). 208 For these capabilities to be useful, Spec(T) must contain 209 requirements as to how the Network Asserted Identity is generated, 210 how its privacy is protected and how its integrity is maintained as 211 it is passed around the network. A reader of Spec(T) can then make an 212 informed judgement about the authenticity and reliability of Network 213 Asserted Information received from the Trust Domain T. 215 3. Generation of Network Asserted Identity 217 A Network Asserted Identity is generated by a network intermediary 218 following an Authentication process which authenticates the entity 219 (UA) to be identified. 221 The Authentication process(es) used are a characteristic feature of 222 the Trust Domain, and MUST be specified in Spec(T). 224 It shall be possible for a UA to provide a prefered identity to the 225 network intermediary, which MAY be used to inform the generation of 226 the Network Asserted Identity according to the policies of the Trust 227 Domain. 229 4. Transport of Network Asserted Identity 231 4.1 Sending of Network Asserted Identity within a Trust Domain 233 It shall be possible for one node within a Trust Domain to securely 234 send a Network Asserted Identity to another node that it trusts. 236 4.2 Receiving of Network Asserted Identity withing a Trust Domain 238 It shall be possible for one node within a Trust Domain to receive a 239 Network Asserted identity from another node that it trusts. 241 4.3 Sending of Network Asserted Identity to entities outside a Trust 242 Domain 244 It shall be possible for a node within the Trust Domain to securely 245 send a Network Asserted Identity to a node outside the trust domain. 247 This is most often used to pass a Network Asserted Identity directly 248 to a UA. 250 4.4 Receiving of Network Asserted Identity by a node outside the Trust 251 Domain 253 It shall be possible for a node outside the Trust Domain to receive a 254 Network Asserted Identity from a node that it trusts. 256 Network Asserted Identity received in this way may be considered 257 valid, and used for display to the user, input data for services etc. 259 Network Asserted Identity information received by one node from a 260 node which it does not trust carries no guarantee of authenticity or 261 integrity because it is not known that the procedures of Spec(T) were 262 followed to generate and transport the information. Such information 263 MUST NOT be used. i.e. it shall not be displayed to the user, passed 264 to other nodes, used as input data for services etc. 266 5. Parties with Network Asserted Identities 268 A Network Asserted Identity identifies the originator of the message 269 in which it was received. 271 For example, 273 o a Network Asserted Identity received in an initial INVITE 274 (outside the context of any existing dialog) identifies the 275 calling party. 277 o a Network Asserted Identity received in a 180 Ringing response 278 to such an INVITE identifies the party who is ringing. 280 o a Network Asserted Identity received in a 200 response to such 281 an INVITE identifies the party who has answered. 283 6. Types of Network Asserted Identity 285 Each party shall have at most one Network Asserted Identity. 287 It shall be possible for the capability to transport multiple 288 identities associated with a single party to be introduced in future. 290 7. Privacy of Network Asserted Identity 291 The means by which any privacy requirements in respect of the Network 292 Asserted Identity are determined are outside the scope of this draft. 294 It shall be possible to indicate that a Network Asserted Identity is 295 subject to a privacy requirement which prevents it being passed to 296 other users. 298 In this case, the Network Asserted Identity specification shall 299 require that the mechanism of 3.2 SHALL NOT be used i.e. a trusted 300 node shall not pass the identity to a node it does not trust. 301 However, the mechanism of 3.1 MAY be used to transfer the identity 302 within the trusted network. 304 It shall be possible to indicate whether the Network Asserted 305 Identity is private due to a request from the user/subscriber or for 306 another reason. 308 Note that �anonymity� requests from users or subscribers may well 309 require functionality in addition to the above handling of Network 310 Asserted Identities. Such additional functionality is out of the 311 scope of this document. 313 8. Next steps 315 It is proposed to use draft-jennings-sipping-nai-00 [2] to implement 316 the requirements of this draft. 318 9. Security considerations 320 The requirements in this draft are NOT intended to result in a 321 mechanism with general applicability between arbitrary hosts on the 322 Internet. 324 Rather, the intention is to state requirements for a mechanism to be 325 used within a community of devices which are known to obey the 326 specification of the mechanism (Spec(T)) and between which there are 327 secure connections. Such a community is known here as a Trust Domain. 329 The requirements on the mechanisms used for security and to initially 330 derive the Network Asserted Identity must be part of the 331 specification Spec(T). 333 Such devices may be hosts on the Internet. 335 The requirements also support the transfer of information from a node 336 within the Trust Domain, via a secure connection to a node outside 337 the Trust Domain. 339 Use of this mechanism in any other context has serious security 340 shortcomings, namely that there is absolutely no guarantee that the 341 information has not been modified, or was even correct in the first 342 place. 344 10. IANA Considerations 346 This document does not have any implications for IANA. 348 11. References 350 [1] J. Rosenberg et al, �SIP: Session initiation protocol," draft- 351 ietf-sip-rfc2543bis-09.txt, February 27th, 2002. 353 [2] C.Jennings, �Network Asserted Identity header�, draft-jennings- 354 sipping-nai-00, May 2002, work in progress. 356 12. Acknowledgments 358 Thanks are due to Jon Peterson, Cullen Jennings and Allison Mankin 359 for comments on this draft. 361 13. Authors� Addresses 363 Mark Watson 364 Nortel Networks (UK) 365 Maidenhead Office Park (Bray House) 366 Westacott Way 367 Maidenhead, 368 Berkshire Tel: +44 (0)1628-434456 369 England Email: mwatson@nortelnetworks.com 371 14. Full Copyright Statement 373 Copyright (C) The Internet Society (2002). All Rights Reserved. 375 This document and translations of it may be copied and furnished to 376 others, and derivative works that comment on or otherwise explain it 377 or assist in its implementation may be prepared, copied, published 378 and distributed, in whole or in part, without restriction of any 379 kind, provided that the above copyright notice and this paragraph are 380 included on all such copies and derivative works. However, this 381 document itself may not be modified in any way, such as by removing 382 the copyright notice or references to the Internet Society or other 383 Internet organizations, except as needed for the purpose of 384 developing Internet standards in which case the procedures for 385 copyrights defined in the Internet Standards process must be 386 followed, or as required to translate it into languages other than 387 English. The limited permissions granted above are perpetual and 388 will not be revoked by the Internet Society or its successors or 389 assigns. This document and the information contained 390 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 391 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 392 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 393 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 394 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 395 PARTICULAR PURPOSE."