idnits 2.17.1 draft-ietf-sipping-nai-reqs-01.txt: -(62): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(140): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(143): 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 -(177): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(178): 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 -(184): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(185): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(188): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(189): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(192): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(193): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(294): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(336): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(339): 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 19 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 190 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 96: '...ay Name. The URI MUST be meaningful to...' RFC 2119 keyword, line 100: '... in the URI, the URI MAY identify some...' RFC 2119 keyword, line 105: '... number MAY identify some spe...' RFC 2119 keyword, line 184: '...ements such as �A trusted node SHALL...' RFC 2119 keyword, line 186: '... 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 8017 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 336 looks like a reference -- Missing reference section? '2' on line 339 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-01.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 A Network Asserted Identity is an identity initially derived by a SIP 33 network intermediary as a result of an authentication process. This 34 draft describes short term requirements for the exchange of Network 35 Asserted Identities within networks of securely interconnected 36 trusted nodes and to User Agents securely connected to such networks. 38 Table of Contents 40 1. Introduction...................................................2 41 2. Definitions....................................................2 42 2.1 Identity...................................................2 43 2.2 Network Asserted Identity..................................3 44 2.3 Trust Domains..............................................3 45 3. Generation of Network Asserted Identity........................5 46 4. Transport of Network Asserted Identity.........................5 47 4.1 Sending of Network Asserted Identity within a Trust Domain.5 48 4.2 Receiving of Network Asserted Identity withing a Trust Domain 49 ...............................................................5 50 4.3 Sending of Network Asserted Identity to entities outside a 51 Trust Domain...................................................5 52 4.4 Receiving of Network Asserted Identity by a node outside the 53 Trust Domain...................................................5 54 5. Parties with Network Asserted Identities.......................6 55 6. Types of Network Asserted Identity.............................6 56 7. Privacy of Network Asserted Identity...........................6 57 8. Next steps.....................................................7 58 9. Security considerations........................................7 59 10. IANA Considerations...........................................7 60 11. References....................................................8 61 12. Acknowledgments...............................................8 62 13. Authors� Addresses............................................8 63 14. Full Copyright Statement......................................8 65 1. Introduction 67 SIP [1] allows users to assert their identity in a number of ways 68 e.g. using the From: header. However, there is no requirement for 69 these identities to be anything other than the users desired alias. 71 An authenticated identity of a user can be obtained using SIP Digest 72 Authentication (or by other means). However, UAs do not always have 73 the necessary key information to authenticate another UA. . 75 A Network Asserted Identity is an identity initially derived by a SIP 76 network intermediary as a result of an authentication process. This 77 may or may not be based on SIP Digest authentication. This draft 78 describes short term requirements for the exchange of Network 79 Asserted Identities within networks of securely interconnected 80 trusted nodes and also to User Agents with secure connections to such 81 networks. 83 Such a network is described in this draft as a Trust Domain and we 84 present a strict definition of trust and Trust Domain for the 85 purposes of this draft. These short-term requirements provide only 86 for the exchange of Network Asserted Identitied within a Trust Domain 87 and to an entity directly connected to the trust domain. 89 General requirements for transport of Network Asserted Identities on 90 the Internet are out of scope of this draft. 92 2. Definitions 94 2.1 Identity 95 An Identity, for the purposes of this draft, is a URI, and optionally 96 a Display Name. The URI MUST be meaningful to the domain identified 97 in the URI when used as a SIP Request-URI. 99 If the URI is a sip: or sips: URI, then depending on the local policy 100 of the domain identified in the URI, the URI MAY identify some 101 specific entity, such as a person. 103 If the URI is a tel: URI, then depending on the local policy of the 104 owner of the number range within which the telephone number lies, the 105 number MAY identify some specific entity, such as a telephone line. 106 However, it should be noted that identifying the owner of the number 107 range is a less straightforward process than identifying the domain 108 which owns a sip: or sips: URI. 110 2.2 Network Asserted Identity 112 A Network Asserted Identity is an identity derived by a SIP network 113 entity as a result of an authentication process. 115 The authentication process used, or at least it's 116 reliability/strength, is a known feature of the Trust Domain using 117 the Network Asserted Identity mechanism i.e. in the language of 2.3 118 below, it is defined in Spec(T). 120 2.3 Trust Domains 122 A Trust Domain for the purposes of Network Asserted Identity is a set 123 of SIP nodes (UAC, UAS, proxies or other network intermediaries) that 124 are trusted to exchange Network Asserted Identity information in the 125 sense described below. 127 A node can be a member of a Trust Domain, T, only if the node is know 128 to be compliant to a certain set of specifications, Spec(T), which 129 characterize the handling of Network Asserted Identity within the 130 Trust Domain, T. 132 Trust Domains are constructed by human beings who know the properties 133 of the equipment they are using/deploying. In the simplest case, a 134 Trust Domain is a set of devices with a single owner/operator who can 135 accurately know the behaviour of those devices. 137 Such simple Trust Domains may be joined into larger Trust Domains by 138 bi-lateral agreements between the owners/operators of the devices. 140 We say a node is �trusted� (with respect to a given Trust Domain) if 141 and only if it is a member of that domain. 143 We say that a node, A, in the domain is �trusted by� a node, B, (or 144 �B trusts A�) if and only if: 146 (i) there is a secure connection between the nodes, AND 147 (ii) B has configuration information indicating that A is a member of 148 the Trust Domain. 150 Note that B may or may not be a member of the Trust Domain. For 151 example, B may be a UA which trusts a given network intermediary, A 152 (e.g. its home proxy). 154 A �secure connection� in this context means that messages cannot be 155 read by third parties, cannot be modified by third parties without 156 detection and that B can be sure that the message really did come 157 from A. The level of security required is a feature of the Trust 158 Domain i.e. it is defined in Spec(T). 160 Within this context, SIP signaling information received by one node 161 FROM a node that it trusts is known to have been generated and passed 162 through the network according to the procedures of the particular 163 specification set Spec(T), and therefore can be known to be valid, or 164 at least as valid as specified in the specifications Spec(T). 166 Equally, a node can be sure that signaling information passed TO a 167 node that it trusts will be handled according to the procedures of 168 Spec(T). 170 For these capabilities to be useful, Spec(T) must contain 171 requirements as to how the Network Asserted Identity is generated, 172 how its privacy is protected and how its integrity is maintained as 173 it is passed around the network. A reader of Spec(T) can then make an 174 informed judgement about the authenticity and reliability of Network 175 Asserted Information received from the Trust Domain T. 177 The term �trusted� (with respect to a given Trust Domain) can be 178 applied to a given node in an absolute sense � it is just equivalent 179 to saying the node is a member of the Trust Domain. However, the node 180 itself does not know whether another arbitrary node is �trusted�, 181 even within the Trust Domain. It does know about certain nodes with 182 which it has secure connections as described above. 184 With the definition above, statements such as �A trusted node SHALL 185 ...� are just shorthand for �A node compliant to this specification 186 SHALL...�. 188 Statements such as �When a node receives information from a trusted 189 node...� are NOT valid, because one node does not have complete 190 knowledge about all the other nodes in the trust domain. 192 Statements such as �When a node receives information from another 193 node that it trusts...� ARE valid, and should be interpreted 194 according to the criteria (i) and (ii) above. 196 3. Generation of Network Asserted Identity 198 A Network Asserted Identity is generated by a network intermediary 199 following an Authentication process which authenticates the entity 200 (UA) to be identified. 202 The Authentication process(es) used are a characteristic feature of 203 the Trust Domain, and MUST be specified in Spec(T). 205 It shall be possible for a UA to provide a preferred identity to the 206 network intermediary, which MAY be used to inform the generation of 207 the Network Asserted Identity according to the policies of the Trust 208 Domain. 210 4. Transport of Network Asserted Identity 212 4.1 Sending of Network Asserted Identity within a Trust Domain 214 It shall be possible for one node within a Trust Domain to securely 215 send a Network Asserted Identity to another node that it trusts. 217 4.2 Receiving of Network Asserted Identity withing a Trust Domain 219 It shall be possible for one node within a Trust Domain to receive a 220 Network Asserted identity from another node that it trusts. 222 4.3 Sending of Network Asserted Identity to entities outside a Trust 223 Domain 225 If a node, A, within the Trust Domain, is trusted by a node, B, 226 outside the Trust Domain, then it shall be possible for A to securely 227 send a Network Asserted Identity to B. 229 This is most often used to pass a Network Asserted Identity directly 230 to a UA. 232 4.4 Receiving of Network Asserted Identity by a node outside the Trust 233 Domain 235 It shall be possible for a node outside the Trust Domain to receive a 236 Network Asserted Identity from a node that it trusts. 238 Network Asserted Identity received in this way may be considered 239 valid, and used for display to the user, input data for services etc. 241 Network Asserted Identity information received by one node from a 242 node which it does not trust carries no guarantee of authenticity or 243 integrity because it is not known that the procedures of Spec(T) were 244 followed to generate and transport the information. Such information 245 MUST NOT be used. i.e. it shall not be displayed to the user, passed 246 to other nodes, used as input data for services etc. 248 5. Parties with Network Asserted Identities 250 A Network Asserted Identity identifies the originator of the message 251 in which it was received. 253 For example, 255 o a Network Asserted Identity received in an initial INVITE 256 (outside the context of any existing dialog) identifies the 257 calling party. 259 o a Network Asserted Identity received in a 180 Ringing response 260 to such an INVITE identifies the party who is ringing. 262 o a Network Asserted Identity received in a 200 response to such 263 an INVITE identifies the party who has answered. 265 6. Types of Network Asserted Identity 267 Each party shall have at most one Network Asserted Identity. 269 It shall be possible for the capability to transport multiple 270 identities associated with a single party to be introduced in future. 272 7. Privacy of Network Asserted Identity 274 The means by which any privacy requirements in respect of the Network 275 Asserted Identity are determined are outside the scope of this draft. 277 It shall be possible to indicate that a Network Asserted Identity is 278 subject to a privacy requirement which prevents it being passed to 279 other users. 281 It shall be possible to indicate that the user has requested that the 282 Network Asserted Identity be not passed to other users. 284 The mechanism shall support Trust Domain policies where the above two 285 indications are equivalent, and policies where they are not. 287 The Network Asserted Identity specification shall require that in the 288 case that the Network Asserted Identity cannot be passed to other 289 users, the mechanism of 3.2 SHALL NOT be used i.e. a trusted node 290 shall not pass the identity to a node it does not trust. However, the 291 mechanism of 3.1 MAY be used to transfer the identity within the 292 trusted network. 294 Note that �anonymity� requests from users or subscribers may well 295 require functionality in addition to the above handling of Network 296 Asserted Identities. Such additional functionality is out of the 297 scope of this document. 299 8. Next steps 301 It is has been agreed to adopt draft-jennings-sipping-nai-00 [2] as a 302 working group item to implement the requirements of this draft. 304 9. Security considerations 306 The requirements in this draft are NOT intended to result in a 307 mechanism with general applicability between arbitrary hosts on the 308 Internet. 310 Rather, the intention is to state requirements for a mechanism to be 311 used within a community of devices which are known to obey the 312 specification of the mechanism (Spec(T)) and between which there are 313 secure connections. Such a community is known here as a Trust Domain. 315 The requirements on the mechanisms used for security and to initially 316 derive the Network Asserted Identity must be part of the 317 specification Spec(T). 319 Such devices may be hosts on the Internet. 321 The requirements also support the transfer of information from a node 322 within the Trust Domain, via a secure connection to a node outside 323 the Trust Domain. 325 Use of this mechanism in any other context has serious security 326 shortcomings, namely that there is absolutely no guarantee that the 327 information has not been modified, or was even correct in the first 328 place. 330 10. IANA Considerations 332 This document does not have any implications for IANA. 334 11. References 336 [1] J. Rosenberg et al, �SIP: Session initiation protocol," draft- 337 ietf-sip-rfc2543bis-09.txt, February 27th, 2002. 339 [2] C.Jennings, �Network Asserted Identity header�, draft-jennings- 340 sipping-nai-00, May 2002, work in progress. 342 12. Acknowledgments 344 Thanks are due to Jon Peterson, Cullen Jennings and Allison Mankin 345 for comments on this draft. 347 13. Authors� Addresses 349 Mark Watson 350 Nortel Networks (UK) 351 Maidenhead Office Park (Bray House) 352 Westacott Way 353 Maidenhead, 354 Berkshire Tel: +44 (0)1628-434456 355 England Email: mwatson@nortelnetworks.com 357 14. Full Copyright Statement 359 Copyright (C) The Internet Society (2002). All Rights Reserved. 361 This document and translations of it may be copied and furnished to 362 others, and derivative works that comment on or otherwise explain it 363 or assist in its implementation may be prepared, copied, published 364 and distributed, in whole or in part, without restriction of any 365 kind, provided that the above copyright notice and this paragraph are 366 included on all such copies and derivative works. However, this 367 document itself may not be modified in any way, such as by removing 368 the copyright notice or references to the Internet Society or other 369 Internet organizations, except as needed for the purpose of 370 developing Internet standards in which case the procedures for 371 copyrights defined in the Internet Standards process must be 372 followed, or as required to translate it into languages other than 373 English. The limited permissions granted above are perpetual and 374 will not be revoked by the Internet Society or its successors or 375 assigns. This document and the information contained 376 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 377 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 378 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 379 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 380 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 381 PARTICULAR PURPOSE."