idnits 2.17.1 draft-wing-sip-identity-media-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 891. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 902. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 909. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 915. 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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 23, 2008) is 5906 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) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: A later version (-07) exists of draft-ietf-sip-dtls-srtp-framework-00 ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) == Outdated reference: A later version (-06) exists of draft-tschofenig-hiprg-host-identities-05 -- Possible downref: Normative reference to a draft: ref. 'I-D.tschofenig-hiprg-host-identities' == Outdated reference: A later version (-22) exists of draft-zimmermann-avt-zrtp-05 ** Downref: Normative reference to an Informational draft: draft-zimmermann-avt-zrtp (ref. 'I-D.zimmermann-avt-zrtp') == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-sdp-capability-negotiation-08 -- No information found for draft-wing-sip-identity-analysis - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Wing 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track H. Kaplan 5 Expires: August 26, 2008 Acme Packet 6 February 23, 2008 8 SIP Identity using Media Path 9 draft-wing-sip-identity-media-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 26, 2008. 36 Abstract 38 This document defines a new SIP identity mechanism which operates 39 through SBCs and B2BUAs. This new identity mechanism creates a 40 signature over certain SIP headers and certain SDP lines. When the 41 SIP body contains SDP, both the SIP signaling path and the media path 42 are used to perform the identity function; when the SIP body contains 43 non-SDP body parts, they are signed in their entirety. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 49 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3.1. Identity Media Signature . . . . . . . . . . . . . . . . . 6 51 3.2. Authentication Service . . . . . . . . . . . . . . . . . . 7 52 3.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 7 53 4. Proof of Identity Techniques . . . . . . . . . . . . . . . . . 7 54 4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 4.2.1. SRTP after DTLS optional . . . . . . . . . . . . . . . 8 57 4.3. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 4.3.1. ICE Public Key SDP Attribute . . . . . . . . . . . . . 9 59 4.3.2. New STUN attributes . . . . . . . . . . . . . . . . . 9 60 4.4. HIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 4.5. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 5. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 6.1. Device Disclosure . . . . . . . . . . . . . . . . . . . . 11 65 6.2. Modification of SDP . . . . . . . . . . . . . . . . . . . 12 66 7. Operational Differences from RFC4474 . . . . . . . . . . . . . 12 67 8. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 9.1. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 9.2. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 9.3. Request without SDP . . . . . . . . . . . . . . . . . . . 17 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 76 12.2. Informational References . . . . . . . . . . . . . . . . . 19 77 Appendix A. ToDo List . . . . . . . . . . . . . . . . . . . . . . 19 78 Appendix B. Changes From Previous Versions . . . . . . . . . . . 19 79 B.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . . 19 80 B.2. Changes from 01 to 02 . . . . . . . . . . . . . . . . . . 20 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 82 Intellectual Property and Copyright Statements . . . . . . . . . . 21 84 1. Introduction 86 SIP Identity [RFC4474] provides cryptographic identity for SIP 87 requests. It provides this protection by signing certain SIP header 88 fields (Contact, Date, Call-ID, CSeq, To, and From) and the SIP 89 message body. The SIP message body typically contains the SDP. 90 However, as discussed in [I-D.wing-sip-identity-analysis], RFC4474 91 does not work well if intermediate domains have B2BUAs or SBCs. As 92 of this writing, most service providers utilize SBCs at network 93 ingress and at network egress. 95 The mechanism described in this document provides cryptographic 96 assurance of the endpoint's identity, and works through most B2BUAs 97 and through most SBCs. 99 The mechanism described in this document signs only certain SDP 100 attributes, and not all the same SIP headers. The remote endpoint is 101 expected to validate the signature over the SIP headers and specified 102 SDP attributes, to initiate a proof of possession test over the media 103 path, which proves the session has been established with the "From:" 104 party in the SIP header. Mechanisms to perform this proof of 105 possession are shown using DTLS and using a small extension to ICE 106 [I-D.ietf-mmusic-ice]. This mechanism is also extensible, in order 107 to be usable by future mechanisms which need signed SDP attributes 109 Readers of this document are expected to be familiar with RFC4474, 110 "Enhancements for Authenticated Identity Management in the Session 111 Initiation Protocol (SIP)", which defines the Identity and Identity- 112 Info header fields. A future version of this document will have less 113 reliance on RFC4474. 115 2. Notational 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 [RFC2119]. 121 3. Operation 123 The operation of SIP-Identity-Media is similar to RFC4474 and uses 124 authentication service proxies much like RFC4474. The basic steps 125 are: 127 o A new header, Identity-Media, is created containing the names of 128 certain SDP attributes from SDP bodyparts, and containing a hash 129 of non-SDP bodyparts. 131 o Several SIP headers and the Identity-Media header are all signed 132 (as detailed in Section 3.1), and the result is placed in 133 Identity-Media-Signature. 135 o The receiving domain validates the signature, and if the request 136 is an invitation to establish a media channel, performs a proof of 137 identity validation using DTLS, TLS, ICE, HIP, or ZRTP over the 138 media path. 140 The following figure shows how the Authentication Service and the 141 media validation is performed. The figure assumes the endpoints 142 themselves perform the media validation. 144 : Service : 145 Enterprise-A : Provider-1 : Enterprise-B 146 : : 147 Auth. : B2BUA or : Auth. 148 Endpoint-A Service : SBC : Service Endpoint-B 149 | | : | : | | 150 1. |--INVITE->| : | : | | 151 2. | sign : | : | | 152 3. | |-INVITE-->|-INVITE-->| | 153 4. | | : | : validate | 154 5. | | : | : |-------->| 155 6. |<=====TLS, DTLS, ICE, HIP, or ZRTP=======>| 156 7. | | : | : | validated 157 8. | | : | : | ring phone 158 | | : | : | | 159 : : 161 Figure 1: Message Flow 163 Step 1: Originating endpoint prepares to send an INVITE and chooses 164 the identity-challenge technique it supports, and indicates 165 that in the SDP it generates. Described in this document 166 are identity challenges for TLS, DTLS, ICE, HIP, and ZRTP. 167 It then sends the INVITE to its local SIP proxy. 169 Step 2: Originating endpoint's authentication service creates a new 170 header, Identity-Media, containing certain attribute names 171 from the SDP (e.g., "a=fingerprint", "a=ice-pub-key"). The 172 authentication service then creates a signature over certain 173 SIP headers (e.g., From, To) and this new Identity-Media 174 header. The resulting signature is inserted into the new 175 Identity-Media-Signature header. An Identity-Info header is 176 added, pointing to this domain's certificate. The INVITE, 177 with these additional headers, is forwarded to the next 178 administrative domain. 180 [NOTE: alternatively, we could allow the UAC to create the 181 Identity- Media header with the attributes it wants signed, 182 then have the auth server sign them and insert the signature 183 header - this would be more flexible] 185 Step 3: The next administrative domain has an SBC (or B2BUA). The 186 SBC modifies or rewrites certain SDP fields. Most typically 187 an SBC will modify the "m" and "c" lines. These 188 modifications do not break the signature, so long as the SBC 189 doesn't remove the headers Identity-Media, Identity-Media- 190 Signature, or Identity-Info, and do not remove or alter the 191 signed attributes from the SDP. 193 Step 4: The terminating endpoint's authentication service receives 194 the INVITE. It validates that the signature contained in 195 the Identity-Media-Signature header, and validates that the 196 signing certificate is owned by the originating domain from 197 step 2. This validation is done by using the certificate 198 pointed to in the Identity-Info header, which MUST match the 199 domain in the From: address. 201 Step 5: If the validation was successful, the terminating endpoint's 202 authentication service forwards the INVITE to the endpoint. 204 Step 6: The terminating endpoint chooses a compatible identity- 205 challenge technique from the INVITE (TLS, DTLS, ICE, HIP, or 206 ZRTP), and performs that challenge. Described in this 207 document are identity challenges for TLS, DTLS, ICE, HIP, 208 and ZRTP. 210 Step 7: All of the identity challenges (TLS, DTLS, ICE, HIP, and 211 ZRTP) cause the exchange of either a certificate or a public 212 key in the media path. The terminating endpoint compares 213 the certificate or public key with the fingerprint in the 214 (signed) Identity-Media header (originally created in step 215 2). If they match, the terminating endpoint completes the 216 identity challenge exchange. After completion, the 217 originating endpoint has proven (to the terminating 218 endpoint) that the originating endpoint knows the private 219 key associated with the certificate (or public key) signed 220 in step 2. The terminating endpoint has now validated the 221 identity of the originating endpoint. 223 Step 8: The terminating endpoint can reliably and honestly indicate 224 calling party information ("caller-id") and ring the phone. 226 3.1. Identity Media Signature 228 In RFC4474, a signature is formed over some SIP headers and over the 229 entire body (which most typically contains SDP). In this 230 specification, some SIP headers are signed but only specific SDP 231 attributes that provide cryptographic identity are signed (e.g., 232 "a=fingerprint" and its value). The specific SDP attributes that are 233 signed depends on which cryptographic identity technique(s) is used; 234 see section Section 4. 236 The SIP headers that are signed, for the signature placed into the 237 Identity-Media-Signature header are: 239 o The AoR of the UA sending the message, or addr-spec of the From 240 header field (referred to occasionally here as the 'identity 241 field'). 243 o The addr-spec component of the To header field, which is the AoR 244 to which the request is being sent. 246 o The SIP method. 248 o [NOTE: Contact, CSeq and Call-Id not included] 250 o The Date header field, with exactly one space each for each SP and 251 the weekday and month items case set as shown in the BNF in 252 RFC3261. RFC3261 specifies that the BNF for weekday and month is 253 a choice amongst a set of tokens. The RFC2234 rules for the BNF 254 specify that tokens are case sensitive. However, when used to 255 construct the canonical string defined here, the first letter of 256 each week and month MUST be capitalized, and the remaining two 257 letters must be lowercase. This matches the capitalization 258 provided in the definition of each token. All requests that use 259 the Identity-Media mechanism MUST contain a Date header. 261 o The Identity-Media header field value. 263 The hash is formed of these elements: 265 digest-string = addr-spec "|" addr-spec "|" 266 Method "|" SIP-date "|" 267 attrib-bodyhash-list 269 The first addr-spec MUST be taken from the From header field value, 270 the second addr-spec MUST be taken from the To header field value. 272 The Identity-Info header points to where the authentication service's 273 certificate can be retrieved from. 275 3.2. Authentication Service 277 The authentication service examines the SIP message body to build the 278 Identity-Media header. For each message body found, in the order 279 found: 281 o if the body part is application/sdp, the authentication service 282 retrieves only the cryptographic attributes from the SDP (as 283 described in Section 4), and appends that information to the 284 Identity-Media header. 286 o otherwise, for all other body parts, the body part is hashed using 287 SHA-1, and the first 96 bytes are appended to the Identity-Media 288 header using "BPH=". 290 For example, A SIP request with three bodyparts: text/plain, 291 application/sdp, and image/jpg, the Identity-Media attribute would 292 contain a bodypart hash of the text/plain part, certain SDP attribute 293 lines from the application/sdp bodypart (a=fingerprint in this 294 example), and a bodypart hash of the image/jpg bodypart: 296 Identity-Media: BPH="e32je3j23cjek3dz","a=fingerprint", 297 BPH="8fj289r3i892381c" 299 This Identity-Media header, along with the headers and portions of 300 headers described in Section 3.1 are all signed by the authentication 301 service. The resulting signature is placed on the new Identity- 302 Media-Signature header. 304 3.3. Validation 306 The validation service can be performed by the remote endpoint itself 307 or by a device acting on behalf of the endpoint. The validation 308 service first checks the signature in the Identity-Media-Signature 309 field. If this is valid, the endpoint (or its validation service 310 operating on its behalf) then initiates a DTLS, TLS, ICE, HIP, or 311 ZRTP identity proof (Section 4). This causes the originating 312 endpoint to prove possession of its private key that corresponds to 313 the certificate (or public key) that was signed by the remote 314 domain's authentication service. 316 4. Proof of Identity Techniques 318 Five techniques are described below, TLS, DTLS, ICE, HIP, and ZRTP. 319 Each provides a means to cryptographically prove the identity signed 320 by the authentication service in SIP is the same as the identity on 321 the media path. 323 Each of these techniques work similarly -- each technique causes 324 unique information to appear in the SDP -- a certificate fingerprint 325 (DTLS, TLS), public key (ICE), or hash (ZRTP). The authentication 326 service creates a new Identity-Media header and places into that 327 header those SDP attribute names associated with that technique. The 328 authentication service then creates a signature over specific SIP 329 headers (see Section 3.1), and places that signature into the new 330 Identity-Media-Signature header. The SIP request is then sent 331 outside of the originating domain. 333 The receiving domain validates the Identity-Media-Signature. If 334 successful, the SIP request is forwarded to the end system. The end 335 system initiates a TLS, DTLS, ICE, HIP, or ZRTP session and validates 336 that the (signed) certificate fingerprint presented in the SIP 337 signaling matches the certificate presented in the TLS, DTLS, ICE, 338 HIP, or ZRTP exchange. If they match, and the TLS, DTLS, ICE, HIP, 339 or ZRTP exchange completes successfully, the local endpoint has 340 validated the identity of the remote endpoint. 342 Note: Due to SIP forking, the calling party may receive many 343 identity challenges, each incurring a public key operation to prove 344 identity. Mechanisms to deal with this are for future study. 346 Discussion point: It is anticipated that, during the course of 347 standardization, a subset of these five techniques will be chosen 348 as mandatory to implement for the purpose of establishing 349 identity. 351 4.1. TLS 353 TLS uses the "fingerprint" attribute to provide a hash of the 354 certificate in the SDP. The fingerprint attribute is defined by 355 [RFC4572] for TLS. 357 4.2. DTLS 359 DTLS uses the same "fingerprint" attribute originally described for 360 TLS. The syntax is described in [I-D.ietf-sip-dtls-srtp-framework]. 362 4.2.1. SRTP after DTLS optional 364 [[Discussion Point: Is there interest in having identity without 365 SRTP??]] 366 DTLS is only necessary to prove identity with DTLS; SRTP [RFC3711] 367 does not need to be used afterwards. Obviously, using SRTP provides 368 significant benefits over continuing to use RTP, because an attacker 369 can inject bogus RTP after a successful validation of identity which 370 is quite undesirable. The SDP for doing RTP after a DTLS exchange 371 might be signaled in SDP by using "RTP/AVP" rather than "RTP/SAVP" 372 (lines folded for readability): 374 v=0 375 o=- 25678 753849 IN IP4 192.0.2.1 376 s= 377 c=IN IP4 192.0.2.1 378 t=0 0 379 m=audio 3456 RTP/AVP 0 18 380 a=fingerprint:SHA-1 381 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 383 Of course, it would be desirable to more clearly indicate this 384 somehow in SDP. The example above collides with non-standard, but 385 deployed, "best-effort" media encryption mechanisms. SDP Capability 386 Negotiation [I-D.ietf-mmusic-sdp-capability-negotiation] might be a 387 useful consideration for this functionality. 389 4.3. ICE 391 ICE doesn't have inherent support for public/private keys. If public 392 keys were sent with other ICE attributes, there can be a real risk of 393 an ICE connectivity check exceeding the MTU. ICE lacks a mechanism 394 to fragment such large messages. It is also bandwidth inefficient to 395 send multiple ICE connectivity checks containing public keys, either 396 as retransmissions or with multiple candidates. Thus, for ICE, the 397 public key is sent in SDP and the public key's fingerprint is 398 exchanged on the media path -- opposite of TLS, DTLS, HIP, and ZRTP. 400 4.3.1. ICE Public Key SDP Attribute 402 The offerer includes its public key, which it will use for the 403 subsequent PK-CHALLENGE and PK-RESPONSE, in its SDP. The syntax is a 404 BASE64-encoded version of the endpoint's public key. 406 The new attribute is called "ice-pub-key", which may appear on the 407 session level, media level, or both. 409 4.3.2. New STUN attributes 411 Two new STUN attributes are defined to carry the plaintext challenge 412 and the encrypted response. 414 4.3.2.1. PK-CHALLENGE 416 This is sent in a STUN Binding Request, and contains two fields: the 417 fingerprint of the public key exchanged in the SDP, and the public 418 key challange. The fingerprint is included so that the remote peer 419 can choose the correct key, in the event it used different public 420 keys. The public key challange field are the bits to be encrypted by 421 the remote peer's private key. Up to 256 bits can be included in the 422 challenge. 424 The PK-CHALLENGE MUST be the same for each candidate address that is 425 being tested for connectivity. If this requirement is not followed, 426 the peer will incur a public key operation for every ICE connectivity 427 check, which is not reasonable or necessary. 429 When the remote peer receives a STUN Binding Request containing this 430 attribute, the contents of the PK-CHALLENGE are encrypted using the 431 private key associated with the public key's fingerprint, and the 432 result is sent in the PK-RESPONSE attribute of the Binding Response. 434 4.3.2.2. PK-RESPONSE 436 This is sent in a STUN Binding Response from the offerer to the 437 answerer, and contains the encrypted result of the PK-CHALLENGE. 439 4.4. HIP 441 In [I-D.tschofenig-hiprg-host-identities], a new attribute "key- 442 mgmt:host-identity-tag" is defined which contains the hash of the 443 public key used in the subsequent HIP exchange. This can be utilized 444 and signed exactly like the "fingerprint" attribute for TLS or DTLS. 446 4.5. ZRTP 448 In [I-D.zimmermann-avt-zrtp], a new attribute "zrtp-hello-hash" is 449 defined which contains a hashed value of the ZRTP Hello packet. The 450 entire ZRTP exchange is protected as described in Section 10 of 451 [I-D.zimmermann-avt-zrtp]. After the ZRTP exchange has completed, 452 the remote party's identity is proven to match the identity signed 453 via SIP-Identity-Media. 455 5. ABNF 457 The following figure shows the syntax of the new SIP header fields 458 using ABNF [RFC5234] 460 identity-media = "Identity-Media" HCOLON 461 attrib-bodyhash-list 462 attrib-bodyhash-list = attrib-bodyhash *(COMMA attrib-bodyhash) 463 attrib-bodyhash = quoted-attrib | quoted-bodyparthash 464 quoted-attribute = DQUOTE attribute DQUOTE ; SDP "a=" line 465 quoted-bodyhash = "BPH" EQUAL DQUOTE bodyparthash DQUOTE 466 bodyparthash = 32HEXDIG 468 identity-media-sig = "Identity-Media-Signature" HCOLON 469 signature 470 signature = DQUOT 32HEXDIG DQUOT 472 Identity-Info = "Identity-Info" HCOLON ident-info 473 *( SEMI ident-info-params ) 474 ident-info = LAQUOT absoluteURI RAQUOT 475 ident-info-params = ident-info-alg / ident-info-extension 476 ident-info-alg = "alg" EQUAL token 477 ident-info-extension = generic-param 479 Figure 2: ABNF for new SIP headers 481 The following figure shows the syntax of the new SDP attribute 482 containing the ICE public key. This is used only by endpoints 483 implementing the ICE proof of identity technique (Section 4.3). 485 ice-pub-key = token ; BASE64 encoded public key 487 Figure 3: ABNF for new SDP attribute 489 6. Security Considerations 491 [[some of RFC4474's security considerations also apply.]] 493 6.1. Device Disclosure 495 Although the mechanism described in this paper allows SBCs to be used 496 with a cryptographic identity scheme, it does expose the identity of 497 the user's certificate. If a unique certificate is installed on each 498 user's device, the remote party will be able to discern which device 499 is terminating the call. This problem is more pronounced when SIP 500 retargeting occurs in conjunction with Connected Identity [RFC4916]. 502 If this isn't desired, there are two solutions: 504 o All devices under the control of the user will need to have the 505 same certificate (and associated private key) installed on them. 507 o The device needs to manufacture a new self-signed certificate (or 508 public key) for each call, and populate the appropriate SDP 509 attributes with that certificate (or public key). This is 510 possible because the identity service described in this paper does 511 not require the same certificate or public key to be used on every 512 call. 514 6.2. Modification of SDP 516 One issue with only signing specific SDP attributes is that a man in 517 the middle can modify the un-signed SDP for nefarious purposes, 518 beyond simply changing m=/c= lines. In particular, an attacker could 519 set the c= connection line used for DTLS-SRTP fingerprint to 0.0.0.0 520 and the m= media line to port 0, essentially disabling that offered 521 media session. The attacker could also add a set of c=/m= lines for 522 non-SRTP media, and thus make a non-SRTP offer with a perfectly valid 523 identity signature. Or an attacker could insert SDP capability 524 negotiation attributes to create a best-effort type SRTP offer, with 525 SRTP (rather than RTP) being the lowest preference. 527 This draft prevents such downgrade attacks by requiring the called UA 528 use DTLS-SRTP, HIP, ICE, or TLS on the media path to establish 529 identity. Thus, an attacker performing the attacks described above 530 will not successfully fool the called UA because the (intended) 531 victim will use DTLS-SRTP (or HIP, ICE, or TLS) on the media path, 532 and the attacker does not possess the private key of the legitimate 533 caller. 535 7. Operational Differences from RFC4474 537 RFC4474 imposes one public key operation for the authentication 538 service and one for validation. If Connected Identity [RFC4916] is 539 used, only one additional public key operation is necessary for the 540 header signature validation; the expense of the DTLS, TLS, or ICE 541 public key operation has already been incurred by both parties and is 542 not repeated. 544 RFC4474 includes the Contact URI in the signed headers. That is not 545 required by this mechanism because it adds no security property, and 546 will fail validation when crossing SBCs and B2BUA's. It is of 547 dubious security value because Via/Record-Route can be inserted for 548 response interception regardless, and some requests don't contain a 549 Contact anyway (e.g., MESSAGE). It does not provide any replay/ 550 copy-paste protection either, for the same reasons. 552 RFC4474 includes the CSeq in the signed headers. That is not 553 required by this mechanism because it adds little security, and will 554 fail validation when crossing SBCs and B2BUA's in some cases. It is 555 of little security value because it provides no protection from cut- 556 paste attack for different targets, and although it would prevent 557 replay attack within the same session, since the media key-related 558 SDP portions are signed anyway, replaying the request will not do 559 anything useful. 561 RFC4474 includes the Call-Id in the signed headers. That is not 562 required by this mechanism because it adds little security, and will 563 fail validation when crossing SBCs and B2BUA's in some cases. It is 564 of little security value because it provides no protection from cut- 565 paste attack for different targets, and although it would prevent 566 replay attack for the same target, since the media key-related SDP 567 portions are signed anyway, replaying the request will not do 568 anything useful. 570 The mechanism described in this document has the following advantages 571 over RFC4474: 573 o Only the edge network needs to create signatures on SIP requests 574 -- not every intervening SBC, 576 o The original cryptographically-provable identity is preserved 577 across any number of SBCs, B2BUA's, etc. 579 o SBCs, B2BUA's, and other "middle-boxes" in intermediate domains do 580 not need to be upgraded or changed in order for the originating 581 and terminating domains to use this new mechanism. 583 8. Limitations 585 For the identity procedure described in this document to function, 586 every device -- including Session Border Controllers -- on the path 587 MUST permit DTLS, TLS, ICE, HIP, or ZRTP messages to be exchanged in 588 the media path. Further, those devices MUST NOT interfere with the 589 signed SDP attributes or the new SIP headers necessary for Identity 590 Media to operate. 592 For the technique described in this document to function, all on-path 593 SIP elements -- SBCs, B2BUAs, and SIP proxies -- MUST NOT interfere 594 with the signed headers. The identity mechanism described in this 595 document is not harmed if on-path SIP elements alter the SDP (e.g., 596 by deleting non-signed attributes, connection addresses, etc.). 598 9. Examples 600 9.1. DTLS 602 This example shows how two a=fingerprint lines in SDP would populate 603 the Identity-Media SIP header field. The following is an example of 604 an INVITE created by the endpoint. 606 (lines folded for readability) 608 INVITE sip:bob@biloxi.example.org SIP/2.0 609 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 610 To: Bob 611 From: Alice ;tag=1928301774 612 Call-ID: a84b4c76e66710 613 CSeq: 314159 INVITE 614 Max-Forwards: 70 615 Date: Thu, 21 Feb 2002 13:02:03 GMT 616 Contact: 617 Content-Type: application/sdp 618 Content-Length: 147 620 v=0 621 o=- 6418913922105372816 2105372818 IN IP4 192.0.2.1 622 s=example2 623 c=IN IP4 192.0.2.1 624 t=0 0 625 m=audio 54113 RTP/SAVP 0 626 a=fingerprint:SHA-1 627 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 628 m=video 54115 RTP/SAVP 0 629 a=fingerprint:SHA-1 630 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 632 Figure 4: Example with DTLS 634 The SIP proxy performing the Media Identity authentication service 635 would then insert the following three SIP headers into the message. 636 The Identity-Media header contains all of the SDP attribute lines 637 that are signed and the Identity-Media header contains the signature 638 of all of the relevant SIP headers and of the Identity-Media header. 639 Lines are folded for readability: 641 Identity-Info: 642 ;alg=rsa-sha1 643 Identity-Media: "a=fingerprint","a=fingerprint" 644 Identity-Media-Signature: 645 "ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa 646 ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn 647 FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=" 649 Figure 5: SIP Headers Inserted by Authentication Service 651 9.2. ICE 653 With ICE, the public key is exchanged in the signaling path (in SDP) 654 rather than in the media path (as is done with TLS, DTLS, HIP, and 655 ZRTP). 657 This is the INVITE as it left the SIP user agent (lines folded for 658 readability): 660 INVITE sip:bob@biloxi.example.org SIP/2.0 661 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 662 To: Bob 663 From: Alice ;tag=1928301774 664 Call-ID: a84b4c76e66710 665 CSeq: 314159 INVITE 666 Max-Forwards: 70 667 Date: Thu, 21 Feb 2002 13:02:03 GMT 668 Contact: 669 Content-Type: application/sdp 670 Content-Length: 147 672 v=0 673 o=- 6418913922105372816 2105372818 IN IP4 192.0.2.1 674 s=example2 675 c=IN IP4 192.0.2.1 676 t=0 0 677 a=ice-pwd:asd88fgpdd777uzjYhagZg 678 a=ice-ufrag:8hhY 679 a=pub-key:ejfiwj289ceucuezeceEJFjefkcjeiquiefekureickejfeefe 680 uirujejfecejejejkfeJJCEIUQQIEFJCQUCJCEQUURIE09dnjkeefjek 681 m=audio 54113 RTP/AVP 0 682 a=candidate:1 1 UDP 2130706431 192.0.2.1 54113 typ host 684 Figure 6: Example with ICE 686 The SIP proxy performing the Media Identity authentication service 687 would then insert the following three SIP headers into the message. 688 The Identity-Media header contains the ICE public key attribute and 689 the Identity-Media header contains the signature of all of the 690 relevant SIP headers and of the Identity-Media header (lines are 691 folded for readability): 693 Identity-Info: 694 ;alg=rsa-sha1 695 Identity-Media: "a=pub-key" 696 Identity-Media-Signature: 697 "jjsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI+p6q5TOQXHMmz6uEo3svJsSH49th8qc 698 efQBbHC00VMZr2k+t6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0Ssjcd 699 VcunyaZucyRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Jcqe=" 701 Figure 7: Headers Inserted by Authentication Service 703 9.3. Request without SDP 705 This example shows how a SIP request without SDP is signed. 707 Message as sent by the UAC (lines folded for readability) 709 MESSAGE sip:user2@example.com SIP/2.0 710 Via: SIP/2.0/TCP user1pc.example.com;branch=z9hG4bK776sgdkse 711 Max-Forwards: 70 712 From: sip:user1@example.com;tag=49583 713 To: sip:user2@example.com 714 Call-ID: asd88asd77a@1.2.3.4 715 CSeq: 1 MESSAGE 716 Content-Type: text/plain 717 Content-Length: 18 719 Watson, come here. 721 Figure 8: Example with no SDP 723 The authentication service would add the following headers to the 724 above message: 726 Identity-Info: 727 ;alg=rsa-sha1 728 Identity-Media: 729 BPH="MZr2k+t6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxA" 730 Identity-Media-Signature: 731 "diOPoQZYOy2wrVghuhcsMbHWUSFxI+p6q5TOQXHMmz6uEo3svJsSH49th8qcjjsR 732 bHC00VMZr2k+t6efQBVmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB09JcVc 733 unyaZucyRlBYYQTLqWzJ+KVhPKbfU/pryhVnqeSsjcd=" 735 Figure 9: added headers 737 10. Acknowledgements 739 The mechanism described in this paper is derived from Jon Peterson 740 and Cullen Jennings' [RFC4474], which was formerly a document of the 741 SIP working group. 743 Thanks to Hans Persson for his suggestions which improved this 744 document. 746 11. IANA Considerations 748 This document will add new IANA registrations for its new STUN 749 attributes. 751 [[This section will be completed in a later version of this 752 document.]] 754 12. References 756 12.1. Normative References 758 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 759 Requirement Levels", BCP 14, RFC 2119, March 1997. 761 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 762 Authenticated Identity Management in the Session 763 Initiation Protocol (SIP)", RFC 4474, August 2006. 765 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 766 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 767 RFC 3711, March 2004. 769 [I-D.ietf-sip-dtls-srtp-framework] 770 Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 771 for Establishing an SRTP Security Context using DTLS", 772 draft-ietf-sip-dtls-srtp-framework-00 (work in progress), 773 November 2007. 775 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 776 Transport Layer Security (TLS) Protocol in the Session 777 Description Protocol (SDP)", RFC 4572, July 2006. 779 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 780 Specifications: ABNF", STD 68, RFC 5234, January 2008. 782 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 783 Protocol (SIP)", RFC 4916, June 2007. 785 [I-D.tschofenig-hiprg-host-identities] 786 Tschofenig, H., "Interaction between SIP and HIP", 787 draft-tschofenig-hiprg-host-identities-05 (work in 788 progress), June 2007. 790 [I-D.zimmermann-avt-zrtp] 791 Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 792 Path Key Agreement for Secure RTP", 793 draft-zimmermann-avt-zrtp-05 (work in progress), 794 February 2008. 796 [I-D.ietf-mmusic-ice] 797 Rosenberg, J., "Interactive Connectivity Establishment 798 (ICE): A Protocol for Network Address Translator (NAT) 799 Traversal for Offer/Answer Protocols", 800 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 802 12.2. Informational References 804 [I-D.ietf-mmusic-sdp-capability-negotiation] 805 Andreasen, F., "SDP Capability Negotiation", 806 draft-ietf-mmusic-sdp-capability-negotiation-08 (work in 807 progress), December 2007. 809 [I-D.wing-sip-identity-analysis] 810 Wing, D. and H. Kaplan, "An Analysis of SIP Identity with 811 SIP Back-to-Back User Agents and Session Border 812 Controllers", draft-wing-sip-identity-analysis-00 (work in 813 progress), January 2008. 815 Appendix A. ToDo List 817 o Add Table-2 of RFC3261 819 o re-use RFC4474 response code for failures, or invent new ones? 821 o describe what occurs if both SIP-Identity-Media and SIP-Identity 822 are both used? 824 Appendix B. Changes From Previous Versions 826 B.1. Changes from 00 to 01 828 o Removed "Contact" header from signature. SBCs need to change it. 830 o Removed "Call ID" header from signature. This header often 831 contains an IP address, so many SBCs change it. 833 o Removed "CSeq" header from signature. This header is sometimes 834 changed by SBCs and B2BUA's. 836 o include SDP attribute names in Identity-Media signature. This 837 allows any attribute to be signed. 839 o Old "Identity-Fingerprints" header renamed to "Identity-Media", 840 and only attribute names are listed in it, not attribute values. 842 o Old "Identity-Media" header renamed to "Identity-Media-Signature". 844 o Described how to sign SIP requests without an SDP body part, and 845 with a mix of SDP and non-SDP bodyparts. 847 B.2. Changes from 01 to 02 849 o Describe how modification of SDP is prevented (section 7.2). 851 o Moved B2BUA and SBC analysis to separate document, 852 [I-D.wing-sip-identity-analysis]. 854 o Added ZRTP as another authentication technique. 856 Authors' Addresses 858 Dan Wing 859 Cisco Systems, Inc. 860 170 West Tasman Drive 861 San Jose, CA 95134 862 USA 864 Email: dwing@cisco.com 866 Hadriel Kaplan 867 Acme Packet 868 71 Third Ave. 869 Burlington, MA 01803 870 USA 872 Phone: 873 Fax: 874 Email: hkaplan@acmepacket.com 875 URI: 877 Full Copyright Statement 879 Copyright (C) The IETF Trust (2008). 881 This document is subject to the rights, licenses and restrictions 882 contained in BCP 78, and except as set forth therein, the authors 883 retain all their rights. 885 This document and the information contained herein are provided on an 886 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 887 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 888 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 889 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 890 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 891 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 893 Intellectual Property 895 The IETF takes no position regarding the validity or scope of any 896 Intellectual Property Rights or other rights that might be claimed to 897 pertain to the implementation or use of the technology described in 898 this document or the extent to which any license under such rights 899 might or might not be available; nor does it represent that it has 900 made any independent effort to identify any such rights. Information 901 on the procedures with respect to rights in RFC documents can be 902 found in BCP 78 and BCP 79. 904 Copies of IPR disclosures made to the IETF Secretariat and any 905 assurances of licenses to be made available, or the result of an 906 attempt made to obtain a general license or permission for the use of 907 such proprietary rights by implementers or users of this 908 specification can be obtained from the IETF on-line IPR repository at 909 http://www.ietf.org/ipr. 911 The IETF invites any interested party to bring to its attention any 912 copyrights, patents or patent applications, or other proprietary 913 rights that may cover technology that may be required to implement 914 this standard. Please address the information to the IETF at 915 ietf-ipr@ietf.org.