idnits 2.17.1 draft-jennings-sipping-nai-00.txt: 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 32 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 66 has weird spacing: '...cy type for S...' == Line 278 has weird spacing: '... where prox...' == Line 514 has weird spacing: '...cy type for S...' -- 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 2, 2002) is 8030 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 2234 (ref. '4') (Obsoleted by RFC 4234) == Outdated reference: A later version (-01) exists of draft-peterson-sip-identity-00 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING WG C. Jennings 3 Internet-Draft Cisco Systems, Inc. 4 Expires: October 31, 2002 May 2, 2002 6 Extensions to the Session Initiation Protocol (SIP) for Network 7 Asserted Identity within Trusted Networks 8 draft-jennings-sipping-nai-00.txt 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 http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 31, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 Abstract 39 This document describes extensions to SIP that enable a network of 40 trusted SIP servers to assert the identity of end users or end 41 systems, and to convey indications of end-user requested privacy. 42 The use of these extensions are only applicable inside an 43 administrative domain, or among federations of administrative domains 44 with previously agreed-upon policies for usage of such information. 45 This document does NOT offer a general privacy or identity model 46 suitable for inter-domain use or use in the Internet at large. 48 Table of Contents 50 1. Applicability Statement . . . . . . . . . . . . . . . . . . 3 51 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 55 6. User Agent Behavior . . . . . . . . . . . . . . . . . . . . 6 56 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 6 57 7.1 The Network-Asserted-ID Header . . . . . . . . . . . . . . . 6 58 7.2 The "nai" Privacy Type . . . . . . . . . . . . . . . . . . . 7 59 7.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 7.3.1 Network Asserted Identity passed to trusted gateway . . . . 7 61 7.3.2 Network Asserted Identity withheld . . . . . . . . . . . . . 9 62 8. Comparison to Requirements . . . . . . . . . . . . . . . . . 11 63 9. Security Considerations . . . . . . . . . . . . . . . . . . 11 64 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 65 10.1 Registration of "Network-Asserted-ID" SIP header . . . . . . 12 66 10.2 Registration of "nai" privacy type for SIP Privacy header . 12 67 11. Open Issues: . . . . . . . . . . . . . . . . . . . . . . . . 12 68 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 69 Normative References . . . . . . . . . . . . . . . . . . . . 13 70 Informational References . . . . . . . . . . . . . . . . . . 13 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 72 Full Copyright Statement . . . . . . . . . . . . . . . . . . 14 74 1. Applicability Statement 76 This document describes extensions to SIP [1] that enable a network 77 of trusted SIP servers to assert the identity of end users or end 78 systems, and to convey indications of end-user requested privacy. 79 The use of these extensions are only applicable inside an 80 administrative domain, or among federations of administrative domains 81 with previously agreed-upon policies for usage of such information. 82 Such a "network" is explicitly trusted by its users and end-systems 83 to either publicly assert the identity of each party, or be 84 responsible for withholding that identity outside of the trusted 85 domain or federation of domains if privacy is requested. The means 86 by which the network determines the identity to assert is outside the 87 scope of this document. 89 This document does NOT offer a general privacy or identity model 90 suitable for inter-domain use or use in the Internet at large. Its 91 assumptions about the trust relationship between the user and the 92 network may not apply in many applications. For example, these 93 extensions do not accommodate a model whereby end users can 94 independently assert their identity by use of the extensions defined 95 here. Furthermore, since the asserted identities are not 96 cryptographically certified, they are subject to forgery, replay, and 97 falsification in any architecture that does not provide full 98 transitive trust. The asserted identities also lack an indication of 99 who is asserting the identity, and therefore the assertions are not 100 useful outside of the federation of domains, where such information 101 would be crucial in order to determine the validity or value of the 102 assertion. 104 Despite these limitations, there are sufficiently useful specialized 105 deployments that meet the assumptions described above, and can accept 106 the limitations that result, to warrant publication of this 107 mechanism. An example deployment would be a closed network which 108 emulates a traditional circuit switched telephone network. 110 It should be noted, that the mechanisms described in this draft are 111 not intended to be used for user-asserted identity. As described 112 above, the mechanisms are merely intended to enable trusted 113 intermediaries to assert an identity for users. 115 2. Conventions 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC-2119 [3]. 121 For the purpose of definitions within this document, trust is a 122 transitive property. If A trusts B and B trusts C, then A,B, and C 123 are all in the same trust domain. 125 For one node to consider another node trusted, it means that the node 126 is willing to delegate to all the nodes in that trust domain the 127 requirements and responsibilities that this draft specifies. It also 128 means the node is willing to share the private network identity 129 information with all the nodes in the trust domain. For one node to 130 trust another node, it must be sure that it is communicating with the 131 correct node, that this node has been administratively added to the 132 trust domain, and that this communication can not be intercepted, 133 modified, or replayed by any node that is not part of the trust 134 domain. 136 Throughout this document requirements for or references to proxy 137 servers or proxy behavior apply similarly to other intermediaries 138 (ex: B2BUAs). 140 3. Introduction 142 Various providers which attempt to offer a telephony service over IP 143 networks have selected SIP as a base protocol. These environments 144 require a way for trusted network elements (for example SIP proxy 145 servers) to communicate the identity of users using such a service, 146 yet also need to withhold this information from untrusted entities 147 under certain circumstances. Such networks typically assume some 148 level of transitive trust. 150 These networks need to interoperate with some basic telephony 151 services and meet basic regulatory and public safety requirements. 152 These include Calling Identity Delivery services, Calling Identity 153 Delivery Blocking, and the ability to trace the originator of a call. 154 While baseline SIP can support each of these services independently, 155 certain combinations cannot be supported. For example, a caller that 156 wants to maintain privacy and consequently provides unintelligible 157 information in the SIP From header field will not be identifiable to 158 SIP entities that do not directly perform SIP authentication. 159 However, this will prevent certain services, e.g., call trace, from 160 working in the PSTN or being performed at intermediaries not privy to 161 the authenticated identity of the user. 163 This document attempts to address this requirement using a very 164 limited, simple mechanism, based on requirements in [5]. A previous 165 attempt to solve this problem ([6]), from which this work was 166 derived, has not generated working group consensus. A more 167 comprehensive mechanism ([7]) which uses cryptography to address this 168 problem is the subject of future analysis by the SIP working group. 170 Providing privacy in an IP network is more complicated than in the 171 PSTN. In IP networks the participants in a session will normally 172 exchange IP traffic directly. The IP addresses used for these 173 sessions may themselves reveal some privacy. A general purpose 174 mechanism for providing privacy in a SIP environment is discussed in 175 [2]. This document extends these mechanism to compensate for the 176 information it adds. 178 4. Overview 180 The mechanism proposed in this draft results in a header that looks 181 like: 183 Network-Asserted-ID: "Cullen Jennings" 185 An authenticating proxy which receives a message can authenticate the 186 user associated with the UAC using an appropriate mechanism (for 187 example: Digest authentication, or TLS mutual authentication). The 188 proxy then inserts a Network-Asserted-ID header in the message and 189 forwards it on to other trusted proxies. A proxy that is about to 190 forward a message to an untrusted proxy or UA, removes the Network- 191 Asserted-ID header if the user requested that this information be 192 kept private. Users can request this type of privacy by including a 193 Privacy header with the "nai" privacy type in their request. 195 5. Proxy Behavior 197 When a proxy receives a message it may be from a trusted or untrusted 198 SIP entity. When a proxy receives a request from a untrusted 199 element, the proxy SHOULD authenticate the user, and using the 200 identity which results from this authentication it MAY insert a 201 Network-Asserted ID header. If a Network-Asserted-ID header is 202 already present in the message, the proxy MAY use this information as 203 a hint suggesting which of multiple valid identities for the 204 authenticated user should be asserted. If such a hint does not 205 correspond to any valid identity known to the proxy for that user, 206 the proxy MUST discard the user-provided Network-Asserted-ID header. 207 In this case, the proxy MAY add a Network-Asserted-ID header of its 208 own construction, or it MAY refuse to forward the request and return 209 a 403 Forbidden response instead. If no Network-Asserted-ID header 210 is present in the request, and the user has multiple valid identities 211 known to the proxy server, the proxy MAY use the From header as a 212 similar hint. 214 If the proxy receives a message (request or response) from a trusted 215 element, it MAY use the information in the Network-Asserted-ID header 216 as if it had authenticated the user itself. For the received message 217 to be trusted, the receiving proxy MUST be sure it came from a 218 trusted SIP element, and that the message was not tampered with in 219 transit. 221 When a proxy forwards a message to another element, it must first 222 determine if that element is trusted or untrusted. If the element is 223 trusted, the proxy MAY include the Network-Asserted-ID header. If 224 the element is not trusted, then the proxy MUST examine the Privacy 225 header (if present) to determine if the user requested that this 226 information be kept private by specifying the "nai" privacy type. If 227 so, the proxy MUST remove the Network-Asserted-ID header. In 228 addition, for backward compatibility, the proxy SHOULD examine the 229 From field for an anonymous value and similarly use this as an 230 indication that the user would like this information to remain 231 private. Otherwise the proxy is encouraged to remove the Network- 232 Asserted-ID header but MAY choose not to. 234 6. User Agent Behavior 236 In general, a User Agent Client does not need to insert a Network- 237 Asserted-ID header. If a UAC is confident that it is sending a 238 request to a trusted outbound proxy, and it has multiple possible 239 network asserted identities, it MAY place the identity that it wishes 240 the proxy to assert for it as a hint in a Network-Asserted-ID header. 241 TLS server authentication provides one possible mechanism by which 242 the UAC can determine that the message is going to the correct proxy. 244 If a User Agent Server receives a message from an untrusted previous 245 hop, it SHOULD ignore any Network-Asserted-ID header, but it MAY 246 present the information to the user in the same manner as an 247 unverified From address, with a warning that this information is not 248 verified in any way. If a UAS receives a Network-Asserted-ID from a 249 trusted entity, then it MAY use the information but it MUST ensure 250 that it does not forward the information to any untrusted element. 251 For example, in the case of an anonymous call going to a PSTN 252 gateway, the gateway MAY pass the Network-Asserted-ID information to 253 the PSTN but it must make sure the call is appropriately signaled so 254 that this information will not be leaked outside of an appropriate 255 trust boundary. 257 7. Formal Syntax 259 The following syntax specification uses the augmented Backus-Naur 260 Form (BNF) as described in RFC-2234 [4]. 262 7.1 The Network-Asserted-ID Header 264 The Network-Asserted-ID header is used among trusted SIP entities 265 (typically intermediaries) to carry the identity of the user sending 266 a SIP message as it was verified by authentication with a trusted 267 entity. 269 NetworkAssertedID = "Network-Asserted-ID" HCOLON ( name-addr / addr-spec ) 271 A Network-Asserted-ID header MUST contain exactly one name-addr or 272 addr-spec. Only a single Network-Asserted-ID header can be present 273 in a SIP message. It is worth noting that Proxies can (and will) add 274 and remove this header. 276 This document adds the following entry to Table 2 of [1]: 278 Header field where proxy ACK BYE CAN INV OPT REG 279 ------------ ----- ----- --- --- --- --- --- --- 280 Network-Asserted-ID adr - o - o o - 282 SUB NOT REF INF UPD PRA 283 --- --- --- --- --- --- 284 o o o - - - 286 7.2 The "nai" Privacy Type 288 This specification adds a new privacy type ("priv-value") to the 289 Privacy header, defined in [2]. The presence of this privacy type in 290 a SIP Privacy header indicates that the user would like the Network 291 Asserted Identity to be kept private with respect to SIP entities 292 outside the trust domain or trust federation with which the user 293 authenticated. Note that a user requesting multiple types of privacy 294 MUST include all of the requested privacy types in its Privacy 295 header. 297 priv-value = "header" / "session" / "nai" / token 299 Example: 301 Privacy: nai 303 7.3 Examples 305 7.3.1 Network Asserted Identity passed to trusted gateway 307 In this example, proxy.cisco.com creates a Network-Asserted-ID header 308 from an identity it discovered from SIP Digest authentication. It 309 forwards this information to a trusted proxy which forwards it to a 310 trusted gateway. 312 * F1 useragent.cisco.com -> proxy.cisco.com 314 INVITE sip:+14085551212@cisco.com SIP/2.0 315 Via: SIP/2.0/TCP useragent.cisco.com 316 To: 317 From: "Anonymous" ;tag=9802748 318 Call-ID: 245780247857024504 319 CSeq: 1 INVITE 320 Max-Forwards: 70 321 Privacy: nai 323 * F2 proxy.cisco.com -> useragent.cisco.com 325 SIP/2.0 407 Proxy Authorization 326 Via: SIP/2.0/TCP useragent.cisco.com 327 To: 328 From: "Anonymous" ;tag=9802748 329 Call-ID: 245780247857024504 330 CSeq: 1 INVITE 331 Proxy-Authenticate: .... realm="cisco.com" 333 * F3 useragent.cisco.com -> proxy.cisco.com 335 INVITE sip:+14085551212@cisco.com SIP/2.0 336 Via: SIP/2.0/TCP useragent.cisco.com 337 To: 338 From: "Anonymous" ;tag=9802748 339 Call-ID: 245780247857024504 340 CSeq: 2 INVITE 341 Max-Forwards: 70 342 Privacy: nai 343 Proxy-Authorization: .... realm="cisco.com" user="fluffy" 345 * F4 proxy.cisco.com -> proxy.pstn.net (trusted) 347 INVITE sip:+14085551212@proxy.pstn.net SIP/2.0 348 Via: SIP/2.0/TCP useragent.cisco.com 349 Via: SIP/2.0/TCP proxy.cisco.com 350 To: 351 From: "Anonymous" ;tag=9802748 352 Call-ID: 245780247857024504 353 CSeq: 2 INVITE 354 Max-Forwards: 69 355 Network-Asserted-ID: "14085264000" 356 Privacy: nai 358 * F5 proxy.pstn.net -> gw.pstn.net (trusted) 360 INVITE sip:+14085551212@gw.pstn.net SIP/2.0 361 Via: SIP/2.0/TCP useragent.cisco.com 362 Via: SIP/2.0/TCP proxy.cisco.com 363 Via: SIP/2.0/TCP proxy.pstn.net 364 To: 365 From: "Anonymous" ;tag=9802748 366 Call-ID: 245780247857024504 367 CSeq: 2 INVITE 368 Max-Forwards: 68 369 Network-Asserted-ID: "14085264000" 370 Privacy: nai 372 7.3.2 Network Asserted Identity withheld 374 In this example, the User Agent provides a hint to its first hop 375 proxy, which it uses after verifying this identity with SIP Digest 376 authentication. The first proxy creates a Network-Asserted-ID header 377 and forwards it to a trusted proxy (outbound.cisco.com). The next 378 proxy removes the Network-Asserted-ID header, and the request for 379 Privacy before forwarding this request onward to the untrusted 380 biloxi.com proxy server. 382 * F1 useragent.cisco.com -> proxy.cisco.com 384 INVITE sip:bob@biloxi.com SIP/2.0 385 Via: SIP/2.0/TCP useragent.cisco.com 386 To: 387 From: "Anonymous" ;tag=9802748 388 Call-ID: 245780247857024504 389 CSeq: 1 INVITE 390 Max-Forwards: 70 391 Network-Asserted-ID: "Cullen Jennings" 392 Privacy: nai 394 * F2 proxy.cisco.com -> useragent.cisco.com 395 SIP/2.0 407 Proxy Authorization 396 Via: SIP/2.0/TCP useragent.cisco.com 397 To: 398 From: "Anonymous" ;tag=9802748 399 Call-ID: 245780247857024504 400 CSeq: 1 INVITE 401 Proxy-Authenticate: .... realm="cisco.com" 403 * F3 useragent.cisco.com -> proxy.cisco.com 405 INVITE sip:bob@biloxi.com SIP/2.0 406 Via: SIP/2.0/TCP useragent.cisco.com 407 To: 408 From: "Anonymous" ;tag=9802748 409 Call-ID: 245780247857024504 410 CSeq: 2 INVITE 411 Max-Forwards: 70 412 Network-Asserted-ID: "Cullen Jennings" 413 Privacy: nai 414 Proxy-Authorization: .... realm="cisco.com" user="fluffy" 416 * F4 proxy.cisco.com -> outbound.cisco.com (trusted) 418 INVITE sip:bob@biloxi SIP/2.0 419 Via: SIP/2.0/TCP useragent.cisco.com 420 Via: SIP/2.0/TCP proxy.cisco.com 421 To: 422 From: "Anonymous" ;tag=9802748 423 Call-ID: 245780247857024504 424 CSeq: 2 INVITE 425 Max-Forwards: 69 426 Network-Asserted-ID: "Cullen Jennings" 427 Privacy: nai 429 * F5 outbound.cisco.com -> proxy.biloxi.com (untrusted) 431 INVITE sip:bob@biloxi SIP/2.0 432 Via: SIP/2.0/TCP useragent.cisco.com 433 Via: SIP/2.0/TCP proxy.cisco.com 434 Via: SIP/2.0/TCP outbound.cisco.com 435 To: 436 From: "Anonymous" ;tag=9802748 437 Call-ID: 245780247857024504 438 CSeq: 2 INVITE 439 Max-Forwards: 68 441 * F6 proxy.biloxi.com -> bobster.biloxi.com 443 INVITE sip:bob@bobster.biloxi.com SIP/2.0 444 Via: SIP/2.0/TCP useragent.cisco.com 445 Via: SIP/2.0/TCP proxy.cisco.com 446 Via: SIP/2.0/TCP outbound.cisco.com 447 Via: SIP/2.0/TCP proxy.biloxi.com 448 To: 449 From: "Anonymous" ;tag=9802748 450 Call-ID: 245780247857024504 451 CSeq: 2 INVITE 452 Max-Forwards: 67 454 8. Comparison to Requirements 456 Some other approaches have suggested that the header should also 457 include information about who asserted it. Inside the trust domain, 458 this is well known, the trust domain asserted it. Outside the trust 459 domain, this information can not be trusted and therefore should not 460 be used. Since there was no use for it in either case, it was not 461 included. 463 The requirements request that the identity of the calling and the 464 called users are supported. This is determined from the context of 465 the messages. If the message is going from the UAC to the UAS, then 466 the network-ID header asserts the identity of the UAC while for 467 messages going the other direction it asserts the identity of the 468 UAS. 470 The requirements only require the ability to assert a single identity 471 though they mention it may be possible to extend to more later. This 472 was explicitly not done in this document because it is unnecessarily 473 complicated. 475 9. Security Considerations 477 The mechanism provided in this document is a partial consideration of 478 the problem of identity and privacy in SIP. For example, these 479 mechanisms provide no means by which end users can conceal their 480 identities from the network. Information which the user designates 481 as 'private' can be inspected by any intermediaries participating in 482 the trusted network. This information is passed by transitive 483 trust, which is only as reliable as the weakest link in the chain of 484 trust. 486 When a trusted entity has determined the identity information for a 487 user that wishes to remain private, and the trusted entity then sends 488 a message to any destination with that party's identity in a Network- 489 Asserted-ID header, the entity MUST take precautions to protect the 490 identity information from eavesdropping and interception to protect 491 the confidentiality and integrity of that identity information. The 492 use of transport or network layer hop-by-hop security mechanisms, 493 such as TLS or IPSec, can satisfy this requirement. 495 Finally, a user agent or proxy can only assume that a privacy request 496 will be honored if it is sent to a trusted entity. Thus, if a user 497 agent or proxy does not know if its SIP message (request or response) 498 is sent to a trusted entity (proxy or UA), it should assume that a 499 privacy request for that message will not be honored. 501 10. IANA Considerations 503 10.1 Registration of "Network-Asserted-ID" SIP header 505 Name of Header: Network-Asserted-ID 507 Short form: none 509 Registrant: Cullen Jennings 510 fluffy@cisco.com 512 Normative description: section 7.1 of this document 514 10.2 Registration of "nai" privacy type for SIP Privacy header 516 Name of privacy type: nai 518 Short Description: Privacy requested for the Network-Asserted-ID header 520 Registrant: Cullen Jennings 521 fluffy@cisco.com 523 Normative description: section 7.2 of this document 525 11. Open Issues: 527 Should an options tag be required so that the UA knows the proxy will 528 support this? It seemed like if you know you could trust the proxy 529 you would already know this so it did not seem valuable. 531 Should a proxy sending a message to a untrusted element be REQUIRED 532 to remove the Network-ID header? 534 Would "Proxy-From" be a better name for this header? 536 12. Acknowledgments 538 Thanks to Bill Marshall and Flemming Andreason [6], Mark Watson [5], 539 and Jon Peterson [7] for authoring drafts which represent the bulk of 540 the text making up this document. 542 Normative References 544 [1] Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation 545 Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress), 546 February 2002. 548 [2] Peterson, J., "A Privacy Mechanism for the Session Initiation 549 Protocol (SIP)", draft-peterson-sip-privacy-longterm-00 (work in 550 progress), April 2002. 552 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 553 Levels", BCP 14, RFC 2119, March 1997. 555 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 556 Specifications: ABNF", RFC 2234, November 1997. 558 Informational References 560 [5] Watson, M., "Short Term Requirements for Network Asserted 561 Identity", draft-watson-sipping-nai-reqs-00.txt (work in 562 progress), May 2002. 564 [6] Marshall, W., "SIP Extensions for Network-Asserted Caller 565 Identity and Privacy within Trusted Networks", draft-ietf-sip- 566 privacy-04 (work in progress), March 2002. 568 [7] Peterson, J., "Enhancements for Authenticated Identity 569 Management in the Session Initiation Protocol (SIP)", draft- 570 peterson-sip-identity-00 (work in progress), April 2002. 572 Author's Address 574 Cullen Jennings 575 Cisco Systems, Inc. 576 170 West Tasman Drive 577 San Jose, CA 95134 578 USA 580 EMail: fluffy@cisco.com 582 Full Copyright Statement 584 Copyright (C) The Internet Society (2002). All Rights Reserved. 586 This document and translations of it may be copied and furnished to 587 others, and derivative works that comment on or otherwise explain it 588 or assist in its implementation may be prepared, copied, published 589 and distributed, in whole or in part, without restriction of any 590 kind, provided that the above copyright notice and this paragraph are 591 included on all such copies and derivative works. However, this 592 document itself may not be modified in any way, such as by removing 593 the copyright notice or references to the Internet Society or other 594 Internet organizations, except as needed for the purpose of 595 developing Internet standards in which case the procedures for 596 copyrights defined in the Internet Standards process must be 597 followed, or as required to translate it into languages other than 598 English. 600 The limited permissions granted above are perpetual and will not be 601 revoked by the Internet Society or its successors or assigns. 603 This document and the information contained herein is provided on an 604 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 605 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 606 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 607 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 608 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 610 Acknowledgement 612 Funding for the RFC Editor function is currently provided by the 613 Internet Society.