idnits 2.17.1 draft-rosenberg-sip-identity-coexistence-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 552. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 17 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 224: '... request, it SHOULD include a Suppor...' RFC 2119 keyword, line 259: '... SHOULD be considered suspect. This...' RFC 2119 keyword, line 267: '...r of the request SHOULD be considered ...' RFC 2119 keyword, line 276: '.... An edge proxy SHOULD follow the pro...' RFC 2119 keyword, line 278: '... the request, it SHOULD use the From h...' (10 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 (June 19, 2006) is 6519 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. '5' -- Obsolete informational reference (is this intentional?): RFC 3427 (ref. '7') (Obsoleted by RFC 5727) == Outdated reference: A later version (-05) exists of draft-ietf-sipping-spam-02 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: December 21, 2006 June 19, 2006 6 Coexistence of P-Asserted-ID and SIP Identity 7 draft-rosenberg-sip-identity-coexistence-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 21, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 Two mechanisms have been defined to support forms of authenticated 41 caller identity in the Session Initiation Protocol (SIP). The first, 42 specified in RFC 3325, is the P-Asserted-ID header field. The 43 second, termed "SIP Identity", defines the Identity and Identity-Info 44 header fields and provides cryptographically verifiable identities. 45 This document discusses how to use these mechanisms together. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 51 3. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 6 52 3.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 6 53 3.2. Generating a Request . . . . . . . . . . . . . . . . . . . 6 54 3.3. Receiving a Request . . . . . . . . . . . . . . . . . . . 6 55 4. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 56 4.1. Edge Proxy . . . . . . . . . . . . . . . . . . . . . . . . 7 57 4.2. Egress Proxy . . . . . . . . . . . . . . . . . . . . . . . 7 58 4.3. Ingress Proxy . . . . . . . . . . . . . . . . . . . . . . 7 59 5. Interactions with B2BUAs . . . . . . . . . . . . . . . . . . . 8 60 6. Interactions with Privacy . . . . . . . . . . . . . . . . . . 8 61 7. P-header or not? . . . . . . . . . . . . . . . . . . . . . . . 9 62 8. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 10.1. Option Tag . . . . . . . . . . . . . . . . . . . . . . . . 11 66 10.2. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 11 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 69 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 Intellectual Property and Copyright Statements . . . . . . . . . . 14 73 1. Introduction 75 One of the most important security features in the Session Initiation 76 Protocol (SIP) [1] is the ability to convey the identity of the 77 initiating party of a request. This feature, sometimes known as 78 "secure caller ID", has been the discussion of much discussion, and 79 is supported by numerous specifications. 81 The first work in secure caller ID is within RFC 3261 itself. SIP 82 provides support for S/MIME. This allows for the initiator of a SIP 83 request to sign the request with their private key, which can then be 84 verified by the recipient using their public key. This mechanism, 85 while very secure, has seen little implementation and no deployment. 86 It requires an easy to use certificate enrollment system by which end 87 users can obtain, store, and manage certificates. To date, systems 88 for providing certificates for end users have proven difficult if not 89 impossible to deploy. 91 Consequently, implementations relied on the From header field in the 92 SIP request, unsigned, to obtain the identity of the sender. This is 93 easily spoofable and a clear risk. To combat it, the P-Asserted-ID 94 header field was developed [6]. With this mechanism, the originating 95 domain of the requestor authenticates them, typically using 96 traditional SIP digest mechanisms. Once authenticated, the SIP proxy 97 inserts a header field - the P-Asserted-ID header field - containing 98 the authenticated identity of the request originator. This header 99 field is not signed in any way. Instead, the header field is only 100 conveyed between domains that have a specific trust relationship. 101 Domains receiving requests with this header field from domains they 102 don't trust remove the header field. Furthermore, the link between 103 proxies in different domains is secured with SIP over TLS, allowing 104 domains to mutually authenticate each other. 106 Due to its requirement for bilateral trust agreements between 107 domains, RFC 3325 is only applicable to closed-knit communities of a 108 small number of relatively large providers. For this reason, the 109 P-Asserted-ID header field was granted "P-header" status [7], and was 110 subsequently adopted by the 3gpp for use in the Internet Multimedia 111 Subsystem (IMS). 113 However, it was recognized by IETF that this mechanism was a short- 114 term solution, and a longer term one was required. It consequently 115 developed the "SIP identity" mechanism [4]. The SIP identity 116 mechanism defines the Identity and Identity-Info header field. As in 117 RFC 3325, an originating proxy in the domain of the requestor 118 authenticates the user, typically using SIP digest. Once 119 authenticated, the originating proxy checks if the From header field 120 value matches the authenticated identity. If it does, it signs 121 certain header fields, including the From header field, and places 122 the result into the Identity header field. The proxy then populates 123 the Identity-Info header field with a URI that can be used to obtain 124 the certificate for the domain. 126 The SIP identity mechanism provides a far superior technical solution 127 to secure caller ID than RFC 3325. Its cryptographically verifiable 128 identies are the cornerstone of anti-spam mechanisms [8], which will 129 not work properly with RFC 3325. 131 Unfortunately, deployment of SIP identity appears problematic due to 132 several practical considerations. Firstly, RFC 3325 has enjoyed 133 widespread deployment. It is build into numerous proxy and 134 application server products, and is also widely used in end user 135 devices. Many IP phones or adaptors will look for the P-Asserted-ID 136 header field as the source for secure caller ID. To bring the SIP 137 identity mechanism into the mix, the caller, proxy, and 138 unfortunately, called party must all be upgraded to support it. 139 Neither the originating proxy or the calling party have any way to 140 know whether the called party supports RFC 3325 or SIP identity, 141 making it difficult to know which to use. To maximize 142 interoperability, it is more cost effective to use the mechanism that 143 is most likely to work - RFC 3325. This produces a chicken-and-egg 144 problem that will substantially hamper the deployment of SIP 145 identity. 147 Secondly, the SIP identity mechanism provides a signature over the 148 request which covers key parts of it, including the body. This means 149 that any elements on the request path between the originating proxy 150 and the terminating user agent which modify the body in any way will 151 invalidate the signature. Though proxies are not supposed to modify 152 the body, the industry has seen widespread usage of back-to-back user 153 agents with media (B2BUA). These components, to facilitate NAT 154 traversal, call admission control, and other functions, modify the 155 body of SIP requests. SIP identity will not function with such 156 elements on the request path. This adds further to the difficulties 157 in deploying SIP identity. 159 To combat this problem, this document defines a mechanism for co- 160 existence of SIP identity and P-Asserted-ID which greatly reduces the 161 barriers to deployment for SIP identity. 163 2. Overview of Operation 165 The essential idea is to use the SIP identity mechanism between 166 proxies, rather than P-Asserted-ID, but to retain the use of 167 P-Asserted-ID as the mechanism for transfer of asserted identity 168 within a domain. The overall architecture is shown in Figure 1. 170 Originating Domain Terminating Domain 171 ............................... ................................. 172 . . . . 173 . +------+ +------+ . . +------+ +------+ . 174 . | |--|Egress|---------|Ingres|--| | . 175 . /| | |Proxy | . . |Proxy | | |\ . 176 . / +------+ +------+ . . +------+ +------+ \ . 177 . / . . \ . 178 . +------+ . . +------+ . 179 . | Edge | . . | | . 180 . |Proxy | . . | | . 181 . +------+ . . +------+ . 182 . / . . \ . 183 ...../......................... ........................\........ 184 / \ 185 +------+ +------+ 186 | | | | 187 | UAC | | UAS | 188 +------+ +------+ 190 Figure 1 192 When a UA initiates a request, it is authenticated by the originating 193 edge proxy. Once the originator has been authenticated, the edge 194 proxy inserts the P-Asserted-ID header field, per RFC 3325. This 195 header field remains in the request as long as it stays within the 196 domain of the originator. Once the request reaches the last proxy in 197 the originating domain (the egress proxy), the egress proxy checks 198 the P-Asserted-ID header field against the From header field. If 199 they match, the egress proxy removes the P-Asserted-ID header field, 200 and adds an Identity and Identity-Info header field per [4]. This is 201 sent to the proxy at the edge of the terminating domain (the ingress 202 proxy). The ingress proxy will verify the signature, and if it 203 validates, insert the P-Asserted-ID header field containing the 204 identity in the From header field. However, the Identity and 205 Identity-Info header fields remain in the request. 207 When the request arrives at the terminating UA, it first checks for 208 the Identity and Identity-Info header fields. If present, the 209 identity in the From header field is used as the caller ID. If not 210 present, but P-Asserted-ID is present, the UA uses the P-Asserted-ID 211 header field as the caller ID. 213 In order for a UA to determine if its domain supports the mechanisms 214 in this specification, a UA will include a Supported header field in 215 its REGISTER request with the option tag "id-coexist". If the domain 216 also supports the mechanism, it will include the same option tag in 217 the REGISTER response. 219 3. User Agent Behavior 221 3.1. Registration 223 When a UA compliant to this specification generates a REGISTER 224 request, it SHOULD include a Supported header field in the request 225 with the option tag "id-coexist". When it receives a successful 226 response to its registration, it checks for the Supported header 227 field and the presence of this option tag. If present, the UA knows 228 that its domain supports the mechanisms of this specification. This 229 information is used in subsequent processing. 231 OPEN ISSUE: this is a little hoakey. We're using the option tag 232 returned from a registrar to infer the behavior of a different 233 element - the ingress proxy. Is that OK? 235 3.2. Generating a Request 237 When originating a request besides a REGISTER, there is no special 238 processing required. 240 3.3. Receiving a Request 242 When receiving an incoming request, the UA first checks for the 243 presence of the Identity and Identity-Info header fields. If 244 present, the UA verifies the signature per [4]. If it verifies, the 245 identity in the From header field is used as the identity of the 246 sender. If it does not verify, but its domain supports the 247 coexistence mechanism (based on presence of the id-coexist option tag 248 in the REGISTER response) and the request contained a P-Asserted-ID 249 header field, the UA interprets this as the presence of a B2BUA with 250 media in the terminating domain. It uses the identity in the 251 P-Asserted-ID header field as the identity of the sender. 253 If the request did not contain either the Identity or Identity-Info 254 header fields, but did contain the P-Asserted-ID header field, that 255 identity is used as the identity of the sender if the clients domain 256 supports the coexistence mechanism. If the domain of the client 257 doesn't support the co-existence mechanism, but the P-Asserted-ID 258 header field is present, the identity of the sender of the request 259 SHOULD be considered suspect. This specification makes no normative 260 recommendations on how to treat the request. However, 261 implementations should consider that, in this case, the identity 262 cannot be trusted unless all of the conditions in the limited scope 263 of applicability of RFC 3325 apply. 265 If the request did not contain the Identity or Identity-Info header 266 fields, and did not contain a P-Asserted-ID header field, the 267 identity of the sender of the request SHOULD be considered suspect. 268 The From header field, without a verified Identity header field, is 269 extremely susceptible to spoofing. 271 4. Proxy Behavior 273 4.1. Edge Proxy 275 An edge proxy is one that authenticates the originating party and 276 asserts their identity. An edge proxy SHOULD follow the procedures 277 of RFC 3325, with one addition. If there is no P-Preferred-ID header 278 field in the request, it SHOULD use the From header field as the 279 preferred ID. 281 4.2. Egress Proxy 283 An egress proxy is one that meets the following conditions: 285 o The next hop proxy is in a different administrative domain. 287 o The domain of the proxy matches the domain in the From header 288 field of the request. 290 If a request contains a P-Asserted-ID header field, and is received 291 from a proxy inside of its domain, an egress proxy SHOULD act as an 292 authentication service per [4]. It SHOULD use the P-Asserted-ID 293 header field as the identity of the sender, rather than attempting to 294 authenticate the request using SIP digest or some other mechanism. 295 The ingress proxy SHOULD remove the P-Asserted-ID header field before 296 forwarding the request. 298 4.3. Ingress Proxy 300 An ingress proxy is one whose previous hop was not in the same 301 administrative domain. When an ingress proxy receives a request, it 302 MUST remove the P-Asserted-ID header field if present. This is done 303 regardless of the trust relationship with the originating domain, and 304 is different from the procedures in RFC 3325, where the P-Asserted-ID 305 is retained if it comes from a trusted peer. Once removed, the 306 ingress proxy checks for the presence of the Identity and Identity- 307 Info header fields. If present, the ingress proxy SHOULD verify the 308 identity of the sender using the procedures in [4]. If the identity 309 is verified, the ingress proxy SHOULD insert a P-Asserted-ID header 310 field containing the identity contained in the From header field of 311 the request. The proxy SHOULD NOT remove the Identity and Identity- 312 Info header fields. This allows for SIP networks where there are 313 more than two administrative domains in a request path, and also 314 allows for a UA to verify the signature on its own if it should 315 desire. 317 5. Interactions with B2BUAs 319 By using the SIP identity mechanism between domains, it will continue 320 to work in the presence of Contact or body-modifying B2BUAs in the 321 request path. In particular, any B2BUA on the request path prior to 322 the egress proxy, and any B2BUA on the request path subsequent to the 323 ingress proxy in the domain of the UAS, will not cause the mechanism 324 described here to fail. Note that, in cases where a proxy serves as 325 both a B2BUA and an egress proxy, it MUST perform the B2BUA function 326 prior to the egress functions described here. Similarly, in cases 327 where a proxy serves as a B2BUA and an ingress proxy, it MUST perform 328 the B2BUA function after the ingress functions described here. 330 It is important to note that the mechanism described here will not 331 work properly in transit networks that contain a B2BUA. A transit 332 network is defined as a SIP domain that is between the domain of the 333 originator and the domain of the terminating UA. If a B2BUA in a 334 transmit network touches the fields covered by the signature, 335 verification will fail at the ingress proxy in the termindating case. 337 6. Interactions with Privacy 339 Privacy has always been a complicated issue with the various identity 340 mechanisms. The privacy specification, RFC 3323 [2] is used by RFC 341 3325. However, it has a significant problem in that a UAS cannot 342 differentiate between a private caller (where the P-Asserted-ID has 343 been removed from the request) and identity unavailable (where the 344 domain of the originator didn't support P-Asserted-ID, or where the 345 originating network was the PSTN and no identity could be obtained). 346 The interactions with SIP identity and privacy are even more 347 complicated. RFC 3323 does not work with SIP identity; this is 348 documented in detail in [5]. 350 Combining together RFC 3325 and SIP identity requires privacy 351 mechanisms to be combined as well. 353 A UA wishing to be anonymous would include an anonymous URI in the 354 From header field. This specification proposes that an anonymous 355 identity be indicated with the "user=anonymous" URI parameter, 356 extending the existing "user" URI parameter with this value. A UA 357 can either obtain an anonymous URI from its domain with mechanisms 358 TBD, or merely make up a random value for the user part of the URI, 359 using a domain of "anonymous.invalid". 361 The edge proxy would authenticate the request, and insert 362 P-Asserted-ID as normal. This would be stripped by the egress proxy. 363 If the From header field contained an anonyous URI that matched the 364 P-Asserted-ID header field (possible only if the anonymous URI had 365 been obtained from its domain), the egress proxy would sign the 366 request using SIP identity. Otherwise, it would not. 368 At the ingress proxy, the signature is verified if present. If not 369 present, no P-Asserted-ID is inserted. At the receiving UAS, if a 370 P-Asserted-ID was present, the "user=anonymous" URI parameter tells 371 the UAS that the requestor is anonymous and verified. If a 372 P-Asserted-ID is not present, the presence of the "user=anonymous" 373 URI parameter tells the UAS that the requestor is anonymous, and that 374 its identity is unverified. It can then render "Anonymous" or 375 whatever is appropriate for the user interface. 377 TODO: fold in the normative recommendations here into the UA and 378 proxy behaviors described above. 380 7. P-header or not? 382 With the recommendations in this document, we believe that the 383 applicability of P-Asserted-ID is now no longer limited. It becomes 384 applicable within the intra-domain signaling of any SIP domain. This 385 begs the question of whether the header field name should now be 386 changed to "Asserted-ID". The answer is an emphatic no! One of the 387 benefits of the coexist mechanism is that it is backwards compatible 388 with RFC 3325, which uses the P-Asserted-ID header field. This 389 exposes a weakness in the concepts in RFC 3427, since we will now 390 have a header with the P prefix which is not actually a P-header. 392 Procedurally, we'd recommend that, if this document moves forward, it 393 be done as an update to both SIP identity and RFC 3325, and be at 394 proposed standard status. Indeed, it should probably be done as an 395 actual revision to RFC 3325. 397 8. Benefits 399 This mechanism brings many benefits: 401 o Does not require the originating domain to know whether the 402 terminating domain supports the mechanism. 404 o Works in the presence of B2BUAs in the originating and terminating 405 domains. 407 o Makes P-Asserted-ID applicable only in intra-domain environments, 408 eliminating its primary security weakness 410 o Provides the cryptographic strengths of SIP identity to the 411 terminating domain, so that mechanisms such as spam detection can 412 be effective. 414 o The proposed privacy solution clearly defines a URI as anonymous 415 independent of the locale and language of the terminating domain 417 o The proposed privacy solution clearly differentiates an anonymous 418 request (one whose From header field contains the user=anonymous 419 parameter) from one where identity could not be provided 421 9. Security Considerations 423 The combination of RFC 3325 with SIP identity provides a mechanism 424 that is, overall, less secure than just SIP identity alone. With SIP 425 identity, the signature is inserted by the first hop proxy (edge 426 proxy) which performs the authentication. This allows all other 427 proxies in the originating domain to determine the identity of the 428 originator by verifying the signature. With the mechanism proposed 429 here, proxies within the domain of the originator would use the 430 P-Asserted-ID header field, which lacks any cryptographic signature. 431 This requires a greater degree of trust within the proxies of the 432 domain. A rogue proxy in the domain of the originator could insert a 433 fake P-Asserted-ID header field, and it would not be caught by the 434 coexist mechanism. 436 In addition, the mechanism here relies on a UAS to trust its 437 terminating domain to follow the procedures defined here and verify 438 the signature in the Identity header field. If a rogue proxy in the 439 terminating domain should insert a fake P-Asserted-ID header field, 440 this would not be caught by the coexist mechanism. 442 Though its overall security is weaker than SIP identity, we fear that 443 the perfect is the enemy of the good. Without changes, SIP identity 444 will be undeployable, and the industry will instead stick with the 445 much-worse P-Asserted-ID solution. The coexist mechanism trades some 446 security in exchange for a mechanism that is far more deployable. 448 As with RFC 3325, the links over which P-Asserted-ID is transmitted 449 SHOULD be secured with SIP over TLS. This prevents against MITM 450 attacks. 452 10. IANA Considerations 454 This specification defines a new SIP option tag and a new SIP URI 455 parameter. 457 10.1. Option Tag 459 This specification registers a new SIP option tag, as per the 460 guidelines in Section 27.1 of RFC 3261. 462 Name: id-coexist 464 Description: This option tag is used to identify the ID coexist 465 mechanism. It is primarily used to tell a UA that its domain 466 supports mechanisms which allow for the coexistence of 467 P-Asserted-ID and SIP identity. 469 10.2. URI Parameter 471 This specification extends the value of the user URI parameter, as 472 per the registry created by [3]. 474 Name of the Parameter: user 476 Predefined Values: anonymous 478 RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 479 RFC number of this specification.]] 481 11. References 483 11.1. Normative References 485 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 486 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 487 Session Initiation Protocol", RFC 3261, June 2002. 489 [2] Peterson, J., "A Privacy Mechanism for the Session Initiation 490 Protocol (SIP)", RFC 3323, November 2002. 492 [3] Camarillo, G., "The Internet Assigned Number Authority (IANA) 493 Uniform Resource Identifier (URI) Parameter Registry for the 494 Session Initiation Protocol (SIP)", BCP 99, RFC 3969, 495 December 2004. 497 [4] Peterson, J. and C. Jennings, "Enhancements for Authenticated 498 Identity Management in the Session Initiation Protocol (SIP)", 499 draft-ietf-sip-identity-06 (work in progress), October 2005. 501 [5] Rosenberg, J., "Identity Privacy in the Session Initiation 502 Protocol (SIP)", draft-rosenberg-sip-identity-privacy-00 (work 503 in progress), July 2005. 505 11.2. Informative References 507 [6] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 508 to the Session Initiation Protocol (SIP) for Asserted Identity 509 within Trusted Networks", RFC 3325, November 2002. 511 [7] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. 512 Rosen, "Change Process for the Session Initiation Protocol 513 (SIP)", BCP 67, RFC 3427, December 2002. 515 [8] Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam", 516 draft-ietf-sipping-spam-02 (work in progress), March 2006. 518 Author's Address 520 Jonathan Rosenberg 521 Cisco Systems 522 600 Lanidex Plaza 523 Parsippany, NJ 07054 524 US 526 Phone: +1 973 952-5000 527 Email: jdrosen@cisco.com 528 URI: http://www.jdrosen.net 530 Intellectual Property Statement 532 The IETF takes no position regarding the validity or scope of any 533 Intellectual Property Rights or other rights that might be claimed to 534 pertain to the implementation or use of the technology described in 535 this document or the extent to which any license under such rights 536 might or might not be available; nor does it represent that it has 537 made any independent effort to identify any such rights. Information 538 on the procedures with respect to rights in RFC documents can be 539 found in BCP 78 and BCP 79. 541 Copies of IPR disclosures made to the IETF Secretariat and any 542 assurances of licenses to be made available, or the result of an 543 attempt made to obtain a general license or permission for the use of 544 such proprietary rights by implementers or users of this 545 specification can be obtained from the IETF on-line IPR repository at 546 http://www.ietf.org/ipr. 548 The IETF invites any interested party to bring to its attention any 549 copyrights, patents or patent applications, or other proprietary 550 rights that may cover technology that may be required to implement 551 this standard. Please address the information to the IETF at 552 ietf-ipr@ietf.org. 554 Disclaimer of Validity 556 This document and the information contained herein are provided on an 557 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 558 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 559 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 560 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 561 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 562 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 564 Copyright Statement 566 Copyright (C) The Internet Society (2006). This document is subject 567 to the rights, licenses and restrictions contained in BCP 78, and 568 except as set forth therein, the authors retain all their rights. 570 Acknowledgment 572 Funding for the RFC Editor function is currently provided by the 573 Internet Society.