idnits 2.17.1 draft-rosenberg-sip-rfc4474-concerns-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 558. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 582. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 16 instances of too long lines in the document, the longest one being 5 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 149: '...tication service SHOULD put telephone ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (February 17, 2008) is 5906 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '13' on line 134 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: A later version (-06) exists of draft-ietf-sip-hitchhikers-guide-04 == Outdated reference: A later version (-07) exists of draft-ietf-avt-dtls-srtp-01 == Outdated reference: A later version (-07) exists of draft-ietf-sip-dtls-srtp-framework-00 Summary: 3 errors (**), 0 flaws (~~), 4 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 4 Intended status: Informational February 17, 2008 5 Expires: August 20, 2008 7 Concerns around the Applicability of RFC 4474 8 draft-rosenberg-sip-rfc4474-concerns-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 20, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 RFC 4474 defines a mechanism for secure identification of callers in 42 the Session Initiation Protocol (SIP). This mechanism has been used 43 as the foundation for some recent additional work, including 44 connected party identification, anti-spam, and secure media. 45 However, concerns have been raised about the applicability of RFC 46 4474 in real deployments and the actual level of security services it 47 provides. This document describes those concerns. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. The Problem with Numbers . . . . . . . . . . . . . . . . . . . 3 53 3. Attacks Introduced by Usage of Numbers . . . . . . . . . . . . 5 54 3.1. The Re-Sign Attack . . . . . . . . . . . . . . . . . . . . 5 55 3.2. The False Number Attack . . . . . . . . . . . . . . . . . 7 56 4. Consequences . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 4.1. Unsecure Caller ID for Phone Numbers . . . . . . . . . . . 8 58 4.2. Comparison with RFC3325 . . . . . . . . . . . . . . . . . 9 59 4.3. Interactions with DTLS-SRTP . . . . . . . . . . . . . . . 10 60 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 63 8. Informative References . . . . . . . . . . . . . . . . . . . . 12 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 Intellectual Property and Copyright Statements . . . . . . . . . . 14 67 1. Introduction 69 The Session Initiation Protocol (SIP) [RFC3261] defined a simple 70 mechanism for conveying the identity of the caller - a basic From 71 field which was inserted by the calling UA. This mechanism has all 72 of the security pitfalls of the From header field in email. 74 A short term solution was standardized in [RFC3325], which provides a 75 network asserted identity. This mechanism is better than a basic 76 From field, but works only in closed user groups and communities that 77 have mutual trust. A longer term solution was developed, generally 78 called SIP Identity, and published in [RFC4474]. SIP Identity makes 79 use of domain-based signatures to provide security. An originating 80 proxy authenticates the user, verifies that it matches their identity 81 in the From header field, and if so, includes an Identity header 82 field. This header field contains a cryptographic signature over the 83 From header field along with other parts of the message, and is then 84 signed by the originating domain. A recipient that receives the 85 request can verify the signature, and compare the domain name in the 86 signers certificate with the domain name in the From header field. 87 If they match, the recipient knows that the originating domain has 88 vouched for the identity of the caller. 90 The SIP Identity mechanism improves upon RFC 3325 by allowing it to 91 work across several transit networks. There is no requirement of 92 mutual trust along every hop; the terminating domain or user directly 93 verifies the assertion made by the calling domain. 95 SIP Identity has been identified as a core SIP protocol 96 [I-D.ietf-sip-hitchhikers-guide]. It has been used as the basis for 97 connected identity, which delivers the identity of the called party 98 [RFC4916]. More recently, SIP Identity is used to provide the 99 integrity services needed to secure DTLS-SRTP 100 [I-D.ietf-avt-dtls-srtp]. In essence, it is becoming a core part of 101 the SIP security story. 103 However, recently concerns have been raised about the applicability 104 of SIP Identity, especially in the presence of phone numbers. This 105 document explores those concerns. 107 2. The Problem with Numbers 109 The mechanism in RFC 4474 is intimately intertwined with the domain 110 part of the From URI. On the receiving side, the identity is 111 considered verified when two conditions exist: 113 o The signature placed in the Identity header field matches the 114 signature computed by the verifier, and 116 o the domain owner, as identified in the signing certificate, 117 matches the domain part of the From header field 119 Both of these properties are needed to provide the security that SIP 120 Identity provides. Unfortunately, in reality, most SIP deployments 121 at the time of writing make use of phone numbers, and not traditional 122 email-style user@domain identifiers. Of course, a phone number does 123 not have a domain part. How, then, can RFC 4474 be used? The 124 specification itself has this to say on the subject: 126 11. Identity and the TEL URI Scheme 128 Since many SIP applications provide a Voice over IP (VoIP) service, 129 telephone numbers are commonly used as identities in SIP deployments. 130 In the majority of cases, this is not problematic for the identity 131 mechanism described in this document. Telephone numbers commonly 132 appear in the username portion of a SIP URI (e.g., 133 'sip:+17005551008@chicago.example.com;user=phone'). That username 134 conforms to the syntax of the TEL URI scheme (RFC 3966 [13]). For 135 this sort of SIP address-of-record, chicago.example.com is the 136 appropriate signatory. 138 It is also possible for a TEL URI to appear in the SIP To or From 139 header field outside the context of a SIP or SIPS URI (e.g., 140 'tel:+17005551008'). In this case, it is much less clear which 141 signatory is appropriate for the identity. Fortunately for the 142 identity mechanism, this form of the TEL URI is more common for the 143 To header field and Request-URI in SIP than in the From header field, 144 since the UAC has no option but to provide a TEL URI alone when the 145 remote domain to which a request is sent is unknown. The local 146 domain, however, is usually known by the UAC, and accordingly it can 147 form a proper From header field containing a SIP URI with a username 148 in TEL URI form. Implementations that intend to send their requests 149 through an authentication service SHOULD put telephone numbers in the 150 From header field into SIP or SIPS URIs whenever possible. 152 This text makes it sound like there really isn't much of a problem; 153 that the originator merely needs to use the SIP version of his SIP 154 URI, and then there will be no problem. However, the usage of phone 155 numbers in this way is problematic. The presence of the domain part 156 in the URI is artificial; as an identifier for a user, the domain 157 part is not relevant. 159 When phone numbers are used, users only know the association between 160 the phone number itself and a user. That is, Bob knows that "+1 161 (973) 865-4321" corresponds to Alice. The domain part is not 162 relevant to him. Bob doesn't use the domain part to reach Alice; he 163 just dials the number. Bob might look up Alice in his phone book, 164 but he'll only see the number there. Bob will use that number when 165 dialing Alice from his cell phone or non-VoIP equipment, and not even 166 have the opportunity to provide a domain name. Alice, in turn, gives 167 out only her number, without the trailing domain part. Almost all 168 user equipment today that provides a form of caller ID, will NOT 169 render the domain part of the URI if the user part is a phone number. 170 Indeed, its very likely that Bob doesn't even know that Alice gets 171 service from a.com. Most users don't know the providers of the other 172 people they interact with. Local number portability has made that 173 association even more ephemeral. Users move between providers 174 relatively easily now, keeping the same number, even though the 175 domain part effectively changes. 177 Consequently, the domain part of the SIP URI, when used in 178 conjunction with phone numbers, is not relevant to users in 179 establishing the identity associated with that number. For email- 180 style identifiers, this is not true - the domain part is highly 181 relevant. 183 Unfortunately, this problem is a FUNDAMENTAL PROPERTY OF PHONE 184 NUMBERS. No specifications or efforts on the part of IETF can fix 185 this problem. Phone numbers are fundamentally NOT scoped to a 186 domain, and attempts to represent them in any other form are 187 ultimately futile from an identification perspective. 189 3. Attacks Introduced by Usage of Numbers 191 The fact that the domain part is irrelevant for SIP URI containing 192 phone numbers introduces two attacks into RFC 4474. 194 3.1. The Re-Sign Attack 196 Consider the network topology of Figure 2. 198 +---------+ +---------+ +---------+ 199 +-------+ | | | | | | +-------+ 200 | | | | | | | | | | 201 | Alice |--| a.com |---| b.com |---| c.com |--| Bob | 202 | | | | | | | | | | 203 +-------+ | | | | | | +-------+ 204 +---------+ +---------+ +---------+ 206 Figure 2: Transit Configuration 208 Alice, who gets VoIP service from a.com, has a phone number of +1 209 (973) 865-4321, and sends an INVITE to Bob. Alice has no user@domain 210 form of AoR; a.com is providing strictly voice services. Per the 211 instructions in RFC 4474, Alice populates the From header field of 212 her INVITE as sip:+19738654321@a.com;user=phone. The a.com proxy as 213 as the authentication service as defined in RFC 4474, and adds an 214 Identity header field. It uses a certificate, signed by a root CA, 215 asserting that it is a.com. This INVITE passes to b.com. The proxy 216 at b.com, for purposes of malice or otherwise, does the following: 218 o Removes the Identity and Identity-Info header fields 220 o Modifies the From header field to 221 sip:+19738654321@b.com;user=phone. In other words, it replaces 222 the domain part with its own domain name. 224 o Adds a new Identity and Identity-Info header field, containing its 225 own signature, performed using a certificate it holds for the 226 b.com domain. 228 o Forwards the request to the target in c.com. 230 This request arrives at c.com, and the request is passed to Bob. 231 Bob's agent runs the verification process described in RFC 4474. The 232 signature on the request is valid, and the domain in the From header 233 field matches the domain in the certificate of the signer. Bob's UA 234 shows the identity of the caller as "+1 (973) 865-4321" and indicates 235 that the identity has been verified. This number does in fact match 236 the number of the caller, Alice. And so, as far as Bob is concerned, 237 everything seems fine. However, b.com has been able to insert 238 itself, and do whatever it wants. 240 What happened here? It is illustrative to look at this attack in the 241 case where Alice had used a user@domain identifier, for example, 242 alice@a.com. In this case, if the b.com transit domain had done the 243 same processing described above, the request would have arrived to 244 Bob's user agent. The signature would be valid, and the domain of 245 the signer would match the domain in the From field. However, the 246 identity shown to Bob would be "alice@b.com", which doesn't match 247 Alice's AOR as far as Bob knows. Consequently, Bob will be alerted 248 to the fact that something is going on. 250 Its important to note that, even with email-style identifiers, the 251 re-sign attack might not be noticed by Bob. If Bob doesn't know 252 Alice; he has no way to know that the caller isn't actually 253 alice@b.com. Consequently, the attack would succeed in that case as 254 well. Indeed, this weakness is outlined in RFC 4474 itself. From 255 Section 13.1: 257 In the end analysis, the Identity and Identity-Info headers cannot 258 protect themselves. Any attacker could remove these headers from a 259 SIP request, and modify the request arbitrarily afterwards. However, 260 this mechanism is not intended to protect requests from men-in-the- 261 middle who interfere with SIP messages; it is intended only to 262 provide a way that SIP users can prove definitively that they are who 263 they claim to be. 265 However, these man-in-the-middle attacks (when an email-style From 266 URI is being used) will be detectable for cases where the called 267 party knows the caller. Even when the called party doesn't know the 268 caller, attemptes to return their calls would fail, and future 269 discussions and communications with the caller would probably quickly 270 reveal that the wrong identifier had been delivered. 272 Our conclusion is that, when email-style identifiers are used, RFC 273 4474 provides a reasonable degree of protection against re-signing 274 and, in fact, provides a reasonable degree of message integrity over 275 the parts of the message covered by the Identity signature. However, 276 when phone numbers are used, RFC 4474 provides no protection against 277 re-signing, and its message integrity is easily subject to MITM 278 attacks. 280 3.2. The False Number Attack 282 Consider once more the topology of Figure 2. However, in this 283 discussion, Alice is a malicious user, and their provider a.com is 284 also malicious. Alice wishes to make a call to Bob, but wishes to 285 lie about her phone number in an attempt to mislead Bob as to the 286 identity of the caller. Consequently, even though Alice's actual 287 phone number is +1 (973) 865-4321, she would like to initiate a call 288 and claim to have the number +1 (202) 456-1414, which is the United 289 States White House switchboard number. 291 Alice sends her INVITE with a From header field of 292 sip:+12024561414@a.com;user=phone. Her proxy at a.com, which is an 293 accomplice in this fabrication, signs the request anyway and includes 294 a pointer to its perfectly valid certificate into the Identity-Info 295 header field. The b.com domain is a large provider and doesn't have 296 the resources to check up on the behavior of its transit partners. 298 So, it passes the INVITE on to Bob's domain, c.com. 300 This call is then passed to Bob. Since this is a perfectly valid From 301 header field value, and the Identity signatures and certificates are 302 all valid, Bob accepts the request. His user agent, noticing that 303 this is a phone number, renders just the phone number, which Bob 304 recognizes as the White House switchboard number. He then answers 305 the call. 307 The reason this attack is possible is that, for phone numbers, only 308 the user part, and NOT the domain part, are relevant for 309 identification. Furthermore, there is nothing within the scope of 310 RFC 4474 which allows a recipient of a request to determine that a 311 particular domain is, in fact, a legitimate owner of a particular 312 phone number. Indeed, the very notion of ownership is a complex one. 313 Thus, it is possible for a domain to claim a particular phone number 314 in its user part, even if that phone number is not in fact 'owned' by 315 that domain. The only protection offered against this attack is the 316 trustworthiness of the domain itself. A domain cannot lie about who 317 they are, but they can lie about what numbers they own. Thus, if a 318 user trusts that a particular domain won't lie, they can determine 319 that a call is from that domain, and therefore trust the phone number 320 only due to their belief in the truthfulness of that domain. 322 4. Consequences 324 There are several important consequences of these attacks. 326 4.1. Unsecure Caller ID for Phone Numbers 328 The false number attack described in Section 3.2 means that RFC 4474 329 does not readily provide 'secure caller ID' for phone numbers. The 330 definition of secure in this context is that the phone number present 331 in the From header field URI does in fact represent the number of the 332 party that originated the call. 334 The term 'readily' above is important. As noted in Section 3.2, the 335 asserted calling number can be considered valid if the signing domain 336 is trusted by the called UA. As a general rule, a UA will not have 337 an easy way to ascertain the trustworthiness of any particular 338 domain. A UA might, perhaps, be configured with the domains of 339 providers it does trust. For example, a UA might trust the large 340 service providers in its country (generally a small and enumerable 341 set), and so it could have 'secure' caller ID only for calls from 342 those providers. 344 If a UA is only willing to trust its own provider, this would likely 345 result in a model whereby each provider determines the 346 trustworthiness of the previous provider, and for those it trusts, it 347 modifies the From header field URI and resigns the request. Such an 348 approach would introduce a transitive trust model to possibly 349 alleviate this problem. 351 4.2. Comparison with RFC3325 353 A critical question to be answered, then, is whether RFC 4474 354 provides any additional security properties above RFC 3325. 356 Firstly, it is clearly the case that for email-style identifiers, RFC 357 4474 is far superior to RFC 3325. RFC 3325 allows the false number 358 attack even for those identifiers. A malicious originating domain 359 could assert a caller identity of sip:george@whitehouse.gov, and this 360 would be the identity rendered to a called party. RFC 3325 provides 361 an overall level of secure caller ID equal to the trustworthiness of 362 the LEAST trustworthy domain in the network. As the size of a 363 network grows, this level of trustworthiness approaches zero. This 364 is not true in RFC 4474; an attacker could not assert identity within 365 whitehouse.gov. 367 Considering phone numbers, two cases must be considered. In one 368 model, each domain in a chain of domains resigns the request and 369 changes the domain name to point to itself. This is possible because 370 the re-sign attack. In this case, it is not because a domain is 371 being malicious; but rather, because it will only choose to re-sign 372 if it trusts its upstream domain. This allows a UA to be configured 373 with a single domain to trust - its own provider - and obtain 374 transitive trust overall. This model is, for all intents and 375 purposes, identical to the trust model outlined for RFC 3325. 376 Consequently, RFC 4474 is no better than RFC 3325 here. 378 However, in the second model, intermediate domains do not resign 379 requests. Furthermore, UA's utilize white lists and black lists of 380 domains that are known to be trustworthy (or not). Today, such lists 381 do exist and are provided for email spam. One can imagine a UA 382 contacting such a service periodically, or upon an incoming call, to 383 verify the signing domain against the list. 385 In this model, RFC 4474 is still superior to RFC3325. In RFC3325, 386 the trustworthiness of the caller ID is as trustable as the least 387 trustworthy domain. As noted above, this approaches zero - for all 388 calls - once the network reaches a reasonable size. However, in RFC 389 4474, the trustworthiness of the caller ID is as trustable as the 390 domain from which the call came. Of course, calls may still arrive 391 from untrusted domains, but in the case of RFC 4474, a UA will know 392 that. As such, it is possible for a UA to separate out caller ID 393 from domains it does trust from those it doesn't, and if it can 394 obtain sufficient coverage from its whitelists so that many incoming 395 caller IDs are trusted, the system works better. That, however, is 396 the key. If the whitelists accessible by a UA cover only 3% of the 397 total number of allocated numbers, most incoming calls will not have 398 a trustable caller ID, and the system will be just as bad as RFC 399 3325. 401 If history is any guide, it is my belief that domains are likely to 402 follow the first model, and not the second. 404 Consequently, the conclusion is that RFC 4474 may provide somewhat 405 more trustable caller ID for phone numbers than RFC 3325, but in 406 practice they are likely to be identical. However, for email-style 407 identifiers, RFC 4474 is superior. 409 4.3. Interactions with DTLS-SRTP 411 When used with email identifiers, RFC 4474 provides a limited form of 412 message integrity protection against MITM attacks. As discussed 413 above, this is because modified domains in From fields are likely to 414 be readily detected by end users, either right away or in the future. 415 However, with phone numbers, RFC 4474 provides no message integrity 416 against MITM attacks. 418 This weakness interacts with DTLS-SRTP [I-D.ietf-avt-dtls-srtp]. In 419 particular, [I-D.ietf-sip-dtls-srtp-framework] describes how the DTLS 420 handshakes are correlated with the signaling exchange by means of the 421 message integrity mechanisms provided by RFC 4474. However, when the 422 calling party has a phone number, that message integrity is lost. 424 A consequence of this is that any intermediate signaling entity could 425 modify the DTLS fingerprints, insert itself as a media intermediary, 426 and then decrypt and re-encrypt media on each side. Such an attack 427 would not be detectable if the caller has a phone number. Indeed, it 428 won't be detectable even if they have an email-style identifier, if 429 the called party doesn't recognize that the caller's identity doesn't 430 match what their UA is showing to them. 432 This, in turn, raises an important question - does, in fact, DTLS- 433 SRTP provide "more secure" media than Sdescriptions [RFC4568]? One 434 of the key weaknesses of Sdescriptions is that, assuming each hop is 435 TLS, the keying material is still exposed to each and every 436 intermediate proxy. This means that any intermediary could intercept 437 and process the media. When used with phone numbers, DTLS-SRTP has 438 this same weakness. 440 That said, DTLS-SRTP does provide some advantages even when used with 441 phone numbers: 443 o To protect against eavesdropping attacks from off-path attackers, 444 Sdescriptions requires that each and every hop has properly 445 encrypted the link with TLS (this is ignoring the possibility of 446 end-to-end SMIME encryption). Thus, simple misconfiguration of an 447 intermediary can expose Sdescriptions to attacks by offpath 448 attackers. DTLS-SRTP does not rely on confidentiality services 449 from intermediaries; indeed it relies on nothing special from 450 them, except that they aren't being malicious. Thus, DTLS-SRTP 451 provides better protection against offpath attacks. 453 o With Sdescriptions, because the keying material is in the 454 signaling, intermediaries will see it directly even when each 455 signaling hop is encrypted. Consequently, it is possible that 456 this material could 'leak' out unsecured channels, such as logs an 457 application interfaces. This would allow other entities access to 458 the keying material and thus allow them to manipulate the media 459 stream. With DTLS-SRTP, this is possible only by active attack by 460 such applications. Thus, DTLS-SRTP provides mildly better 461 protection here. 463 Thus, DTLS-SRTP still provides better security than Sdescriptions. 464 However, when used with phone numbers, it is by no means ideal. Most 465 importantly, it does NOT provide guarantees that intermediaries have 466 not been able to intercept and decrypt the media. 468 5. Conclusions 470 Unfortunately, there is no simple remedy to this problem. The 471 problems with RFC4474 cannot just be fixed by an alternate security 472 technique. They are deeply rooted in the domain independence of 473 phone numbers. 475 Consequently, our recommendation at this point is to more clearly 476 document the limitations of RFC4474 when used with phone numbers. We 477 recommend that RFC4474 be revised, and that the updated document 478 include a more detailed discussion of the weaknesses it has when used 479 with phone numbers. Similarly, we recommend that 480 [I-D.ietf-sip-dtls-srtp-framework] be revised to include a more 481 thorough description of the limitations of DTLS-SRTP when used with 482 phone numbers. 484 6. Security Considerations 486 This document is concerned entirely with security. 488 7. IANA Considerations 490 None. 492 8. Informative References 494 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 495 A., Peterson, J., Sparks, R., Handley, M., and E. 496 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 497 June 2002. 499 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 500 Extensions to the Session Initiation Protocol (SIP) for 501 Asserted Identity within Trusted Networks", RFC 3325, 502 November 2002. 504 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 505 Authenticated Identity Management in the Session 506 Initiation Protocol (SIP)", RFC 4474, August 2006. 508 [I-D.ietf-sip-hitchhikers-guide] 509 Rosenberg, J., "A Hitchhiker's Guide to the Session 510 Initiation Protocol (SIP)", 511 draft-ietf-sip-hitchhikers-guide-04 (work in progress), 512 November 2007. 514 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 515 Protocol (SIP)", RFC 4916, June 2007. 517 [I-D.ietf-avt-dtls-srtp] 518 McGrew, D. and E. Rescorla, "Datagram Transport Layer 519 Security (DTLS) Extension to Establish Keys for Secure 520 Real-time Transport Protocol (SRTP)", 521 draft-ietf-avt-dtls-srtp-01 (work in progress), 522 November 2007. 524 [I-D.ietf-sip-dtls-srtp-framework] 525 Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 526 for Establishing an SRTP Security Context using DTLS", 527 draft-ietf-sip-dtls-srtp-framework-00 (work in progress), 528 November 2007. 530 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 531 Description Protocol (SDP) Security Descriptions for Media 532 Streams", RFC 4568, July 2006. 534 Author's Address 536 Jonathan Rosenberg 537 Cisco 538 Edison, NJ 539 US 541 Email: jdrosen@cisco.com 542 URI: http://www.jdrosen.net 544 Full Copyright Statement 546 Copyright (C) The IETF Trust (2008). 548 This document is subject to the rights, licenses and restrictions 549 contained in BCP 78, and except as set forth therein, the authors 550 retain all their rights. 552 This document and the information contained herein are provided on an 553 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 554 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 555 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 556 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 557 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 558 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 560 Intellectual Property 562 The IETF takes no position regarding the validity or scope of any 563 Intellectual Property Rights or other rights that might be claimed to 564 pertain to the implementation or use of the technology described in 565 this document or the extent to which any license under such rights 566 might or might not be available; nor does it represent that it has 567 made any independent effort to identify any such rights. Information 568 on the procedures with respect to rights in RFC documents can be 569 found in BCP 78 and BCP 79. 571 Copies of IPR disclosures made to the IETF Secretariat and any 572 assurances of licenses to be made available, or the result of an 573 attempt made to obtain a general license or permission for the use of 574 such proprietary rights by implementers or users of this 575 specification can be obtained from the IETF on-line IPR repository at 576 http://www.ietf.org/ipr. 578 The IETF invites any interested party to bring to its attention any 579 copyrights, patents or patent applications, or other proprietary 580 rights that may cover technology that may be required to implement 581 this standard. Please address the information to the IETF at 582 ietf-ipr@ietf.org. 584 Acknowledgment 586 Funding for the RFC Editor function is provided by the IETF 587 Administrative Support Activity (IASA).