idnits 2.17.1 draft-wing-rtpsec-keying-eval-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 1557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1581. 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 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 659: '...sent the offer, it MUST be prepared to...' RFC 2119 keyword, line 661: '... It MUST be prepared to send and ...' RFC 2119 keyword, line 669: '...violating the above MUST requirement.s...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 1401 has weird spacing: '...RFP) in the S...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 30, 2007) is 6289 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: A later version (-04) exists of draft-ietf-mmusic-securityprecondition-03 == Outdated reference: A later version (-03) exists of draft-ietf-msec-mikey-ecc-01 == Outdated reference: A later version (-15) exists of draft-ietf-sip-certs-02 -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) -- Obsolete informational reference (is this intentional?): RFC 3388 (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) == Outdated reference: A later version (-03) exists of draft-fischl-sipping-media-dtls-01 == Outdated reference: A later version (-09) exists of draft-ietf-msec-mikey-applicability-03 == Outdated reference: A later version (-22) exists of draft-zimmermann-avt-zrtp-02 == Outdated reference: A later version (-06) exists of draft-mcgrew-srtp-ekt-01 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-13 == Outdated reference: A later version (-05) exists of draft-ietf-sip-connected-identity-04 == Outdated reference: A later version (-02) exists of draft-mcgrew-tls-srtp-00 == Outdated reference: A later version (-01) exists of draft-dondeti-msec-rtpsec-mikeyv2-00 == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-sdp-capability-negotiation-01 Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Audet 3 Internet-Draft Nortel 4 Intended status: Informational D. Wing 5 Expires: August 3, 2007 Cisco Systems 6 January 30, 2007 8 Evaluation of SRTP Keying with SIP 9 draft-wing-rtpsec-keying-eval-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 3, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Over a dozen incompatible mechanisms have been defined to key an 43 Secure RTP (SRTP) media stream. This document evaluates the keying 44 mechanisms, concentrating on their interaction with SIP features and 45 their security properties. 47 This document is discussed on the rtpsec mailing list, 48 . 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Overview of Keying Mechanisms . . . . . . . . . . . . . . . . 4 55 3.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 5 56 3.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 6 58 3.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 6 60 3.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 6 61 3.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 7 62 3.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 7 63 3.1.8. Security Descriptions with SIPS . . . . . . . . . . . 7 64 3.1.9. Security Descriptions with S/MIME . . . . . . . . . . 7 65 3.1.10. SDP-DH . . . . . . . . . . . . . . . . . . . . . . . . 8 66 3.1.11. MIKEYv2 in SDP . . . . . . . . . . . . . . . . . . . . 8 67 3.2. Media Path Keying Technique . . . . . . . . . . . . . . . 8 68 3.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.3. Signaling and Media Path Keying Techniques . . . . . . . . 9 70 3.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 9 72 3.3.3. MIKEYv2 Inband . . . . . . . . . . . . . . . . . . . . 9 73 4. Evaluation Criteria - SIP . . . . . . . . . . . . . . . . . . 10 74 4.1. Secure Retargeting and Secure Forking . . . . . . . . . . 10 75 4.2. Clipping Media Before SDP Answer . . . . . . . . . . . . . 15 76 4.3. Centralized Keying . . . . . . . . . . . . . . . . . . . . 17 77 4.4. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . . . 20 78 5. Evaluation Criteria - Security . . . . . . . . . . . . . . . . 22 79 5.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 22 80 5.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 24 81 5.3. Best Effort Encryption . . . . . . . . . . . . . . . . . . 25 82 5.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . . . 28 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 30 88 9.2. Informational References . . . . . . . . . . . . . . . . . 30 89 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 33 90 A.1. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 33 91 A.2. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 33 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 93 Intellectual Property and Copyright Statements . . . . . . . . . . 35 95 1. Introduction 97 SIP needs to operate across the world-wide public Internet and thus 98 needs a single, mandatory-to-implement mechanism for strongly 99 authenticating an endpoint. It is likely that the mechanism will be 100 based on RSA, Diffie-Hellman, or Digital Signature Standard (DSS) but 101 cannot rely on an X.509 PKI or pre-shared keys. 103 There are currently 13 mechanisms defined or under consideration by 104 the IETF to establish SRTP [RFC3711] keys between endpoints. 105 Although an endpoint can implement several mechanisms, these 13 106 mechanisms are not interoperable with each other. The mechanisms can 107 be broken into three general categories for exchanging SRTP keying: 108 exchanging keys in signaling, media, or both. 110 The goals of an SRTP key exchange mechanism are, in rough order: 112 1. Ability to deploy the mechanism across administrative boundaries, 113 such as on the Internet, 115 2. Cryptographically authenticate the endpoints, 117 3. Securely exchange SRTP keys, 119 4. Support SIP features such as retargeting and forking. 121 Existing key exchange mechanisms fail to meet all of these 122 requirements. 124 Two mechanisms, MIKEY and Security Descriptions, have been 125 standardized for SRTP key exchange. Both of these mechanisms perform 126 key exchange in the signaling path (SIP or RTSP). 128 All MIKEY modes share a common syntax (a=key-mgmt, defined in Key 129 Management Extensions for Session Description Protocol (SDP) and Real 130 Time Streaming Protocol (RTSP) [RFC4567]). The base MIKEY 131 specification [RFC3830] defines four MIKEY modes and additional modes 132 are defined in other specifications. MIKEY modes are not compatible 133 with each other. 135 The other standard mechanism, Security Descriptions, uses a different 136 syntax (a=crypto, defined in Security Descriptions [RFC4568]). 138 Several extensions to MIKEY have been proposed and several techniques 139 which perform some, or all, keying in the media path have been 140 proposed. These new techniques are also discussed in this document. 142 Out of scope of this document is how SIP, RTSP, and SDP messages 143 themselves are encrypted. 145 Call signaling (new call, end of call, call transfer, etc.) is done 146 in SIP, and media is sent in RTP. In the following diagram, Alice is 147 calling Bob. This causes Alice to emit a SIP message to her SIP 148 proxy, which processes the message and routes the message to Bob's 149 proxy which then routes it to Bob. 151 +---------+ SIP Invite +-------| 152 | Alice's +------------------>+ Bob's | 153 | proxy | | proxy | 154 +----+----+ +---+---| 155 ^ | 156 SIP Invite | | SIP Invite 157 | V 158 +---+---+ +-----+ 159 | Alice |<===================>+ Bob | 160 +-------+ SRTP +-----+ 162 Figure 1: Simplified SIP Model 164 2. Terminology 166 AOR (Address-of-Record): A SIP or SIPS URI that points to a domain 167 with a location service that can map the URI to another URI where 168 the user might be available. Typically, the location service is 169 populated through registrations. An AOR is frequently thought of 170 as the "public address" of the user. 172 SSRC: The 32-bit value that defines the synchronization source, 173 used in RTP. These are generally unique, but collisions can 174 occur. 176 two-time pad: The use of the same key and the same key index to 177 encrypt different data. For SRTP, a two-time pad occurs if two 178 senders are using the same key and the same RTP SSRC value. 180 PKI Public Key Infrastructure. Throughout this paper, the term PKI 181 refers to a global PKI. 183 3. Overview of Keying Mechanisms 185 Based on how the SRTP keys are exchanged, each SRTP key exchange 186 mechanism belongs to one general category: 188 signaling path: All the keying is carried in the call signaling 189 (SIP or SDP) path. 191 media path: All the keying is carried in the SRTP/SRTCP media 192 path, and no signaling whatsoever is carried in the call 193 signaling path. 195 signaling and media path: Parts of the keying are carried in the 196 SRTP/SRTCP media path, and parts are carried in the call 197 signaling (SIP or SDP) path. 199 One of the significant benefits of SRTP over other end-to-end 200 encryption mechanisms, such as for example IPsec, is that SRTP is 201 bandwidth efficient and SRTP retains the header of RTP packets. 202 Bandwidth efficiency is vital for VoIP in many scenarios where access 203 bandwidth is limited or expensive, and retaining the RTP header is 204 important for troubleshooting packet loss, delay, and jitter. 206 Related to SRTP's characteristics is a goal that any SRTP keying 207 mechanism to also be efficient and not cause additional call setup 208 delay. Contributors to additional call setup delay include network 209 or database operations: retrieval of certificates and additional SIP 210 or media path messages, and computational overhead of establishing 211 keys or validating certificates. 213 When examining the choice between keying in the signaling path, 214 keying in the media path, or keying in both paths, it is important to 215 realize the media path is generally 'faster' than the SIP signaling 216 path. The SIP signaling path has computational elements involved 217 which parse and route SIP messages. The media path, on the other 218 hand, does not normally have computational elements involved, and 219 even when computational elements such as firewalls are involved, they 220 cause very little additional delay. Thus, the media path can be 221 useful for exchanging several messages to establish SRTP keys. A 222 disadvantage of keying over the media path is that interworking 223 different key exchange requires the interworking function be in the 224 media path, rather than just in the signaling path; in practice this 225 involvement is probably unavoidable anyway. 227 3.1. Signaling Path Keying Techniques 229 3.1.1. MIKEY-NULL 231 MIKEY-NULL [RFC3830] has the offerer indicate the SRTP keys for both 232 directions. The key is sent unencrypted in SDP, which means the SDP 233 must be encrypted hop-by-hop (e.g., by using TLS (SIPS)) or end-to- 234 end (e.g., by using S/MIME). 236 MIKEY-NULL requires one message from offerer to answerer (half a 237 round trip), and does not add additional media path messages. 239 3.1.2. MIKEY-PSK 241 MIKEY-PSK (pre-shared key) [RFC3830] requires that all endpoints 242 share one common key. MIKEY-PSK has the offerer encrypt the SRTP 243 keys for both directions using this pre-shared key. 245 MIKEY-PSK requires one message from offerer to answerer (half a round 246 trip), and does not add additional media path messages. 248 3.1.3. MIKEY-RSA 250 MIKEY-RSA [RFC3830] has the offerer encrypt the keys for both 251 directions using the intended answerer's public key, which is 252 obtained from a PKI. 254 MIKEY-RSA requires one message from offerer to answerer (half a round 255 trip), and does not add additional media path messages. MIKEY-RSA 256 requires the offerer to obtain the intended answerer's certificate. 258 3.1.4. MIKEY-RSA-R 260 MIKEY-RSA-R An additional mode of key distribution in MIKEY: MIKEY- 261 RSA-R [RFC4738] is essentially the same as MIKEY-RSA but reverses the 262 role of the offerer and the answerer with regards to providing the 263 keys. That is, the answerer encrypts the keys for both directions 264 using the offerer's public key. Both the offerer and answerer 265 validate each other's public keys using a PKI. MIKEY-RSA-R also 266 enables sending certificates in the MIKEY message. 268 MIKEY-RSA-R requires one message from offerer to answer, and one 269 message from answerer to offerer (full round trip), and does not add 270 additional media path messages. MIKEY-RSA-R requires the offerer 271 validate the answerer's certificate. 273 3.1.5. MIKEY-DHSIGN 275 In MIKEY-DHSIGN [RFC3830] the offerer and answerer derive the key 276 from a Diffie-Hellman exchange. In order to prevent an active man- 277 in-the-middle the DH exchange itself is signed using each endpoint's 278 private key and the associated public keys are validated using a PKI. 280 MIKEY-DHSIGN requires one message from offerer to answerer, and one 281 message from answerer to offerer (full round trip), and does not add 282 additional media path messages. MIKEY-DHSIGN requires the offerer 283 and answerer to validate each other's certificates. MIKEY-DHSIGN 284 also enables sending the answerer's certificate in the MIKEY message. 286 3.1.6. MIKEY-DHHMAC 288 MIKEY-DHHMAC [RFC4650] uses a pre-shared secret to HMAC the Diffie- 289 Hellman exchange, essentially combining aspects of MIKEY-PSK with 290 MIKEY-DHSIGN, but without MIKEY-DHSIGN's need for a PKI to 291 authenticate the Diffie-Hellman exchange. 293 MIKEY-DHHMAC requires one message from offerer to answerer, and one 294 message from answerer to offerer (full round trip), and does not add 295 additional media path messages. 297 3.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) 299 ECC Algorithms For MIKEY [I-D.ietf-msec-mikey-ecc] describes how ECC 300 can be used with MIKEY-RSA (using ECDSA signature) and with MIKEY- 301 DHSIGN (using a new DH-Group code), and also defines two new ECC- 302 based algorithms, Elliptic Curve Integrated Encryption Scheme (ECIES) 303 and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) . 305 For the purposes of this paper, the ECDSA signature, MIKEY-ECIES, and 306 MIKEY-ECMQV function exactly like MIKEY-RSA, and the new DH-Group 307 code function exactly like MIKEY-DHSIGN. Therefore these ECC 308 mechanisms aren't discussed separately in this paper. 310 3.1.8. Security Descriptions with SIPS 312 Security Descriptions [RFC4568] has each side indicate the key it 313 will use for transmitting SRTP media, and the keys are sent in the 314 clear in SDP. Security Descriptions relies on hop-by-hop (TLS via 315 "SIPS:") encryption to protect the keys exchanged in signaling. 317 Security Descriptions requires one message from offerer to answerer, 318 and one message from answerer to offerer (full round trip), and does 319 not add additional media path messages. 321 3.1.9. Security Descriptions with S/MIME 323 This keying mechanism is identical to Section 3.1.8, except that 324 rather than protecting the signaling with TLS, the entire SDP is 325 encrypted with S/MIME. 327 3.1.10. SDP-DH 329 SDP Diffie-Hellman [I-D.baugher-mmusic-sdp-dh] exchanges Diffie- 330 Hellman messages in the signaling path to establish session keys. To 331 protect against active man-in-the-middle attacks, the Diffie-Hellman 332 exchange needs to be protected with S/MIME, SIPS, or SIP-Identity 333 [RFC4474] and [I-D.ietf-sip-connected-identity]. 335 SDP-DH requires one message from offerer to answerer, and one message 336 from answerer to offerer (full round trip), and does not add 337 additional media path messages. 339 3.1.11. MIKEYv2 in SDP 341 MIKEYv2 [I-D.dondeti-msec-rtpsec-mikeyv2] adds mode negotiation to 342 MIKEYv1 and removes the time synchronization requirement. It 343 therefore now takes 2 round-trips to complete. In the first round 344 trip, the communicating parties learn each other's identities, agree 345 on a MIKEY mode, crypto algorithm, SRTP policy, and exchanges nonces 346 for replay protection. In the second round trip, they negotiate 347 unicast and/or group SRTP context for SRTP and/or SRTCP. 349 Furthemore, MIKEYv2 also defines an in-band negotiation mode as an 350 alternative to SDP (see Section 3.3.3). 352 3.2. Media Path Keying Technique 354 3.2.1. ZRTP 356 ZRTP [I-D.zimmermann-avt-zrtp] does not exchange information in the 357 signaling path (although it's possible for endpoints to indicate 358 support for ZRTP with "a=zrtp" in the initial Offer). In ZRTP the 359 keys are exchanged entirely in the media path using a Diffie-Hellman 360 exchange. The advantage to this mechanism is that the signaling 361 channel is used only for call setup and the media channel is used to 362 establish an encrypted channel -- much like encryption devices on the 363 PSTN. ZRTP uses voice authentication of its Diffie-Hellman exchange 364 by having each person read digits to the other person. Subsequent 365 sessions with the same ZRTP endpoint can be authenticated using the 366 stored hash of the previously negotiated key rather than voice 367 authentication. 369 ZRTP uses 4 media path messages (Hello, Commit, DHPart1, and DHPart2) 370 to establish the SRTP key, and 3 media path confirmation messages. 371 The first 4 are sent as RTP packets (using RTP header extensions), 372 and the last 3 are sent in conjunction with SRTP media packets (again 373 as SRTP header extensions). Note that unencrypted RTP is being 374 exchanged until the SRTP keys are established. 376 3.3. Signaling and Media Path Keying Techniques 378 3.3.1. EKT 380 EKT [I-D.mcgrew-srtp-ekt] relies on another SRTP key exchange 381 protocol, such as Security Descriptions or MIKEY, for bootstrapping. 382 In the initial phase, each member of a conference uses an SRTP key 383 exchange protocol to establish a common key encryption key (KEK). 384 Each member may use the KEK to securely transport its SRTP master key 385 and current SRTP rollover counter (ROC), via RTCP, to the other 386 participants in the session. 388 EKT requires the offerer to send some parameters (EKT_Cipher, KEK, 389 and security parameter index (SPI)) via the bootstrapping protocol 390 such as Security Descriptions or MIKEY. Each answerer sends an SRTCP 391 message which contains the answerer's SRTP Master Key, rollover 392 counter, and the SRTP sequence number. Rekeying is done by sending a 393 new SRTCP message. For reliable transport, multiple RTCP messages 394 need to be sent. 396 3.3.2. DTLS-SRTP 398 DTLS-SRTP [I-D.mcgrew-tls-srtp] exchanges public key fingerprints in 399 SDP [I-D.fischl-sipping-media-dtls] and then establishes a DTLS 400 session over the media channel. The endpoints use the DTLS handshake 401 to agree on crypto suites and establish SRTP session keys. SRTP 402 packets are then exchanged between the endpoints. 404 DTLS-SRTP requires one message from offerer to answerer (half round 405 trip), and, if the offerer wishes to correlate the SDP answer with 406 the endpoint, requires one message from answer to offerer (full round 407 trip). DTLS-SRTP uses 4 media path messages to establish the SRTP 408 key. 410 This paper assumes DTLS will use TLS_RSA_WITH_3DES_EDE_CBC_SHA as its 411 cipher suite, which is the mandatory-to-implement cipher suite in TLS 412 [RFC4346]. 414 3.3.3. MIKEYv2 Inband 416 As defined in Section 3.1.11, MIKEYv2 also defines an in-band 417 negotiation mode as an alternative to SDP (see Section 3.3.3). The 418 details are not sorted out in the draft yet on what in-band actually 419 means (i.e., UDP, RTP, RTCP, etc.). 421 4. Evaluation Criteria - SIP 423 This section considers how each keying mechanism interacts with SIP 424 features. 426 4.1. Secure Retargeting and Secure Forking 428 In SIP, a request sent to a specific AOR but delivered to a different 429 AOR is called a "retarget". A typical scenario is a "call 430 forwarding" feature. In the figure below, Alice sends an Invite in 431 step 1 which is sent to Bob in step 2. Bob responds with a redirect 432 (SIP response code 3xx) pointing to Carol in step 3. This redirect 433 typically does not propagate back to Alice but only goes to a proxy 434 (i.e., the retargeting proxy) which sends the original Invite to 435 Carol in step 4. 437 +-----+ 438 |Alice| 439 +--+--+ 440 | 441 | Invite (1) 442 V 443 +----+----+ 444 | proxy | 445 ++-+-----++ 446 | ^ | 447 Invite (2) | | | Invite (4) 448 & redirect (3) | | | 449 V | V 450 ++-++ ++----+ 451 |Bob| |Carol| 452 +---+ +-----+ 454 Figure 2: Retargeting 456 Successful use of SRTP requires strongly identifying both calling 457 party and the called party. The mechanism used by SIP for 458 identifying the calling party is SIP Identity [RFC4474]. However, 459 due to SIP retargeting issues [I-D.peterson-sipping-retarget], SIP 460 Identity can only identify the calling party (that is, the party that 461 initiated the SIP request). Some key exchange mechanisms predate SIP 462 Identity and include their own identity mechanism. However, those 463 built-in identity mechanism suffer from the same SIP retargeting 464 problem described in the above draft. Going forward, it is 465 anticipated that Connected Identity [I-D.ietf-sip-connected-identity] 466 may allow identifying the called party. In the list below, this is 467 described as the 'retargeting identity' problem. 469 In SIP, 'forking' is the delivery of a request to multiple locations. 470 This happens when a single AOR is registered more than once. An 471 example of forking is when a user has a desk phone, PC client, and 472 mobile handset all registered with the same AOR. 474 +-----+ 475 |Alice| 476 +--+--+ 477 | 478 | Invite 479 V 480 +-----+-----+ 481 | proxy | 482 ++---------++ 483 | | 484 Invite | | Invite 485 V V 486 +--+--+ +--+--+ 487 |Bob-1| |Bob-2| 488 +-----+ +-----+ 490 Figure 3: Forking 492 With forking, both Bob-1 and Bob-2 might send back SDP answers in SIP 493 responses. Alice will see those intermediate (18x) and final (200) 494 responses. It is useful for Alice to be able to associate the SIP 495 response with the incoming media stream. Although this association 496 can be done with ICE [I-D.ietf-mmusic-ice], and ICE is useful to make 497 this association with RTP, it isn't desirable to require ICE to 498 accomplish this association. The table below analyzes if it is 499 possible for an offerer to associate the media stream with each SDP 500 answer, without using ICE. 502 Forking and retargeting are often used together. For example, a boss 503 and secretary might have both phones ring and rollover to voice mail 504 if neither phone is answered. 506 To maintain media security, only the endpoint that answers the call 507 should know the SRTP keys for the session. For key exchange 508 mechanisms that don't provide secure forking or secure retargeting, 509 one workaround is to rekey immediately after forking or retargeting. 510 However, because the originator may not be aware that the call forked 511 this mechanism requires rekeying immediately after every session is 512 established which causes additional signaling messages. 514 Retargeting securely introduces a more significant problem. With 515 retargeting, the actual recipient of the request is not the original 516 recipient. This means that if the offerer encrypted material (such 517 as the session key or the SDP) using the original recipient's public 518 key, the recipient will not be able to decrypt that material because 519 the actual recipient won't have the original recipient's private key. 520 In some cases, this is the intended behavior, i.e., you wanted to 521 establish a secure connection with a specific individual. In other 522 cases, it is not intended behavior (you want all voice media to be 523 encrypted, regardless of who answers). 525 For some forms of key management the calling party needs to know in 526 advance the certificate or shared secret of the called party, and 527 retargeting can interfere with this. 529 Further compounding this problem is a particularity of SIP that when 530 forking is used, there is always only one final error response 531 delivered to the sender of the request: the forking proxy is 532 responsible for choosing which final response to choose in the event 533 where forking results in multiple final error responses being 534 received by the forking proxy. This means that if a request is 535 rejected, say with information that the keying information was 536 rejected and providing the far end-end's credentials, it is very 537 possible that the rejection will never reach the sender. This 538 problem, called the Heterogeneous Error Response Forking Problem 539 (HERFP) [I-D.mahy-sipping-herfp-fix] is a complicated problem to 540 solve in SIP. 542 The following list compares the behavior of secure forking, answering 543 association, two-time pads, and secure retargeting for each keying 544 mechanism. 546 MIKEY-NULL Secure Forking: No, all AORs see offerer's and 547 answerer's keys. Answer is associated with media by the SSRC 548 in MIKEY. Additionally, a two-time pad occurs if two branches 549 choose the same 32-bit SSRC and transmit SRTP packets. 551 Secure Retargeting: No, all targets see offerer's and 552 answerer's keys. Suffers from retargeting identity problem. 554 MIKEY-PSK 555 Secure Forking: No, all AORs see offerer's and answerer's 556 keys. Answer is associated with media by the SSRC in MIKEY. 557 Note that all AORs must share the same pre-shared key in order 558 for forking to work at all with MIKEY-PSK. Additionally, a 559 two-time pad occurs if two branches choose the same 32-bit SSRC 560 and transmit SRTP packets. 562 Secure Retargeting: Not secure. For retargeting to work, the 563 final target must possess the correct PSK. As this is likely 564 in scenarios were the call is targeted to another device 565 belonging to the same user (forking), it is very unlikely that 566 other users will possess that PSK and be able to successfully 567 answer that call. 569 MIKEY-RSA 570 Secure Forking: No, all AORs see offerer's and answerer's 571 keys. Answer is associated with media by the SSRC in MIKEY. 572 Note that all AORs must share the same private key in order for 573 forking to work at all with MIKEY-RSA. Additionally, a two- 574 time pad occurs if two branches choose the same 32-bit SSRC and 575 transmit SRTP packets. 577 Secure Retargeting: No. 579 MIKEY-RSA-R 580 Secure Forking: Yes. Answer is associated with media by the 581 SSRC in MIKEY. 583 Secure Retargeting: Yes. 585 MIKEY-DHSIGN 586 Secure Forking: Yes, each forked endpoint negotiates unique 587 keys with the offerer for both directions. Answer is 588 associated with media by the SSRC in MIKEY. 590 Secure Retargeting: Yes, each target negotiates unique keys 591 with the offerer for both directions. 593 MIKEYv2 in SDP 594 The behavior will depend on which mode is picked. 596 MIKEY-DHHMAC 597 Secure Forking: Yes, each forked endpoint negotiates unique 598 keys with the offerer for both directions. Answer is 599 associated with media by the SSRC in MIKEY. 601 Secure Retargeting: Yes, each target negotiates unique keys 602 with the offerer for both directions. Note that for the keys 603 to be meaningful, it would require the PSK to be the same for 604 all the potential intermediaries, which would only happen 605 within a single domain. 607 Security Descriptions with SIPS 608 Secure Forking: No. Each forked endpoint sees the offerer's 609 key. Answer is not associated with media. 611 Secure Retargeting: No. Each target sees the offerer's key. 613 Security Descriptions with S/MIME 614 Secure Forking: No. Each forked endpoint sees the offerer's 615 key. Answer is not associated with media. 617 Secure Retargeting: No. Each target sees the offerer's key. 618 Suffers from retargeting identity problem. 620 SDP-DH 621 Secure Forking: Yes. Each forked endpoint calculates a unique 622 SRTP key. Answer is not associated with media. 624 Secure Retargeting: Yes. The final target calculates a unique 625 SRTP key. 627 ZRTP 628 Secure Forking: Yes. Each forked endpoint calculates a unique 629 SRTP key. As ZRTP isn't signaled in SDP, there is no 630 association of the answer with media. 632 Secure Retargeting: Yes. The final target calculates a unique 633 SRTP key. 635 EKT 636 Secure Forking: Inherited from the bootstrapping mechanism 637 (the specific MIKEY mode or Security Descriptions). Answer is 638 associated with media by the SPI in the EKT protocol. Answer 639 is associated with media by the SPI in the EKT protocol. 641 Secure Retargeting: Inherited from the bootstrapping mechanism 642 (the specific MIKEY mode or Security Descriptions). 644 DTLS-SRTP 645 Secure Forking: Yes. Each forked endpoint calculates a unique 646 SRTP key. Answer is associated with media by the certificate 647 fingerprint in signaling and certificate in the media path. 649 Secure Retargeting: Yes. The final target calculates a unique 650 SRTP key. 652 MIKEYv2 Inband 653 The behavior will depend on which mode is picked. 655 4.2. Clipping Media Before SDP Answer 657 Per the SDP Offer/Answer Model [RFC3264], 659 Once the offerer has sent the offer, it MUST be prepared to 660 receive media for any recvonly streams described by that offer. 661 It MUST be prepared to send and receive media for any sendrecv 662 streams in the offer, and send media for any sendonly streams in 663 the offer (of course, it cannot actually send until the peer 664 provides an answer with the needed address and port information). 666 To meet this requirement with SRTP, the offerer needs to know the 667 SRTP key for arriving media. If encrypted SRTP media arrives before 668 the associated SRTP key, the offerer cannot play the media -- causing 669 clipping and violating the above MUST requirement.s 671 For key exchange mechanisms which send the answerer's key in SDP, a 672 SIP provisional response [RFC3261] such as 183 (session progress) is 673 useful. However the 183 messages aren't reliable unless both the 674 calling and called endpoint support PRACK [RFC3262], use TCP across 675 all SIP proxies, implement Security Preconditions 676 [I-D.ietf-mmusic-securityprecondition], or the both ends implement 677 ICE [I-D.ietf-mmusic-ice] and the answerer implements the reliable 678 provisional response mechanism described in ICE. However, there is 679 not wide deployment of any of these techniques and there is industry 680 reluctance to requiring these techniques as solutions to avoid the 681 problem described in this section. 683 Furthermore, the problem gets compounded when forking is used. For 684 example, if using a Diffie-Hellman keying technique with security 685 preconditions that forks to 20 endpoints, the call initiator would 686 get 20 provisional responses containing 20 signed Diffie-Hellman half 687 keys. Calculating 20 DH secrets and validating signatures can be a 688 difficult task depending on the device capabilities. 690 The following list compares the behavior of clipping before SDP 691 answer for each keying mechanism. 693 MIKEY-NULL 694 Not clipped. The offerer provides the answerer's keys. 696 MIKEY-PSK 697 Not clipped. The offerer provides the answerer's keys. 699 MIKEY-RSA 700 Not clipped. The offerer provides the answerer's keys. 702 MIKEY-RSA-R 703 Clipped. The answer contains the answerer's encryption key. 705 MIKEY-DHSIGN 706 Clipped. The answer contains the answerer's Diffie-Hellman 707 response. 709 MIKEY-DHHMAC 710 Clipped. The answer contains the answerer's Diffie-Hellman 711 response. 713 MIKEYv2 in SDP 714 The behavior will depend on which mode is picked. 716 Security Descriptions with SIPS 717 Clipped. The answer contains the answerer's encryption key. 719 Security Descriptions with S/MIME 720 Clipped. The answer contains the answerer's encryption key. 722 SDP-DH 723 Clipped. The answer contains the answerer's Diffie-Hellman 724 response. 726 ZRTP 727 Not clipped because the session intially uses RTP. While RTP 728 is flowing, both ends negotiate SRTP keys in the media path and 729 then switch to using SRTP. 731 EKT 732 Not clipped, as long as the first RTCP packet (containing the 733 answerer's key) is not lost in transit. The answerer sends its 734 encryption key in RTCP, which arrives at the same time (or 735 before) the first SRTP packet encrypted with that key. 737 Note: RTCP needs to work, in the answerer-to-offerer 738 direction, before the offerer can decrypt SRTP media. 740 DTLS-SRTP 741 Not clipped. Keys are exchanged in the media path without 742 relying on the signaling path. 744 MIKEYv2 Inband 745 Not clipped. Keys are exchanged in the media path without 746 relying on the signaling path. 748 4.3. Centralized Keying 750 For efficient scaling, large audio and video conference bridges 751 operate most efficiently by encrypting the current speaker once and 752 distributing that stream to the conference attendees. Typically, 753 inactive participants receive the same streams -- they hear (or see) 754 the active speaker(s), and the active speakers receive distinct 755 streams that don't include themselves. In order to maintain 756 confidentiality of such conferences where listeners share a common 757 key, all listeners must rekeyed when a listener joins or leaves a 758 conference. 760 An important use case for mixers/translators is a conference bridge: 762 +----+ 763 A --- 1 --->| | 764 <-- 2 ----| M | 765 | I | 766 B --- 3 --->| X | 767 <-- 4 ----| E | 768 | R | 769 C --- 5 --->| | 770 <-- 6 ----| | 771 +----+ 773 Figure 4: Centralized Keying 775 In the figure above, 1, 3, and 5 are RTP media contributions from 776 Alice, Bob, and Carol, and 2, 4, and 6 are the RTP flows to those 777 devices carrying the 'mixed' media. 779 Several scenarios are possible: 781 a. Multiple inbound sessions: 1, 3, and 5 are distinct RTP 782 sessions, 784 b. Multiple outbound sessions: 2, 4, and 6 are distinct RTP 785 sessions, 787 c. Single inbound session: 1, 3, and 5 are just different sources 788 within the same RTP session, 790 d. Single outbound session: 2, 4, and 6 are different flows of the 791 same (multi-unicast) RTP session 793 If there are multiple inbound sessions and multiple outbound sessions 794 (scenarios a and b), then every keying mechanism behaves as if the 795 mixer were an endpoint and can set up a point-to-point secure session 796 between the participant and the mixer. This is the simplest 797 situation, but is computationally wasteful, since SRTP processing has 798 to be done independently for each participant. The use of multiple 799 inbound sessions (scenario a) doesn't waste computational resources, 800 though it does consume additional cryptographic context on the mixer 801 for each participant and has the advantage of non-repudiation of the 802 originator of the incoming stream. 804 To support a single outbound session (scenario d), the mixer has to 805 dictate its encryption key to the participants. Some keying 806 mechanisms allow the transmitter to determine its own key, and others 807 allow the offerer to determine the key for the offerer and answerer. 808 Depending on how the call is established, the offerer might be a 809 participant (such as a participant dialing into a conference bridge) 810 or the offerer might be the mixer (such as a conference bridge 811 calling a participant). 813 The use of offerless Invites may help some keying mechanisms 814 reverse the role of offerer/answerer. A difficulty, however, is 815 knowing a priori if the role should be reversed for a particular 816 call. 818 The following list describes how each keying mechanism behaves with 819 centralized keying (scenario d) and rekeying. 821 MIKEY-NULL 822 Keying: Yes, if offerer is the mixer. No, if offerer is the 823 participant (end user). 825 Rekeying: Yes, via re-Invite 827 MIKEY-PSK 828 Keying: Yes, if offerer is the mixer. No, if offerer is the 829 participant (end user). 831 Rekeying: Yes, with a re-Invite 833 MIKEY-RSA 834 Keying: Yes, if offerer is the mixer. No, if offerer is the 835 participant (end user). 837 Rekeying: Yes, with a re-Invite 839 MIKEY-RSA-R 840 Keying: No, if offerer is the mixer. Yes, if offerer is the 841 participant (end user). 843 Rekeying: n/a 845 MIKEY-DHSIGN 846 Keying: No; a group-key Diffie-Hellman protocol is not 847 supported. 849 Rekeying: n/a 851 MIKEY-DHHMAC 852 Keying: No; a group-key Diffie-Hellman protocol is not 853 supported. 855 Rekeying: n/a 857 MIKEYv2 in SDP 858 The behavior will depend on which mode is picked. 860 Security Descriptions with SIPS 861 Keying: Yes, if offerer is the mixer. Yes, if offerer is the 862 participant. 864 Rekeying: Yes, with a Re-Invite. 866 Security Descriptions with S/MIME 867 Keying: Yes, if offerer is the mixer. Yes, if offerer is the 868 participant. 870 Rekeying: Yes, with a Re-Invite. 872 SDP-DH 873 Keying: No; a group-key Diffie-Hellman protocol is not 874 supported. 876 Rekeying: n/a 878 ZRTP 879 Keying: No; a group-key Diffie-Hellman protocol is not 880 supported. 882 Rekeying: n/a 884 EKT 885 Keying: Yes. After bootstrapping a KEK using Security 886 Descriptions or MIKEY, each member originating an SRTP stream 887 can send its SRTP master key, sequence number and ROC via RTCP. 889 Rekeying: Yes. EKT supports each sender to transmit its SRTP 890 master key to the group via RTCP packets. Thus, EKT supports 891 each originator of an SRTP stream to rekey at any time. 893 DTLS-SRTP 894 Keying: Yes, because with the assumed cipher suite, 895 TLS_RSA_WITH_3DES_EDE_CBC_SHA, each end indicates its SRTP key. 897 Rekeying: via DTLS in the media path. 899 MIKEYv2 Inband 900 The behavior will depend on which mode is picked. 902 4.4. SSRC and ROC 904 In SRTP, a cryptographic context is defined as the SSRC, destination 905 network address, and destination transport port number. Whereas RTP, 906 a flow is defined as the destination network address and destination 907 transport port number. This results in a problem -- how to 908 communicate the SSRC so that the SSRC can be used for the 909 cryptographic context. 911 Two approaches have emerged for this communication. One, used by all 912 MIKEY modes, is to communicate the SSRCs to the peer in the MIKEY 913 exchange. Another, used by Security Descriptions, is to use "late 914 bindng" -- that is, any new packet containing a previously-unseen 915 SSRC (which arrives at the same destination network address and 916 destination transport port number) will create a new cryptographic 917 context. Another approach, common amongst techniques with media-path 918 SRTP key establishment, is to require a handshake over that media 919 path before SRTP packets are sent. MIKEY's approach changes RTP's 920 SSRC collision detection behavior by requiring RTP to pre-establish 921 the SSRC values for each session. 923 Another related issue is that SRTP introduces a rollover counter 924 (ROC), which records how many times the SRTP sequence number has 925 rolled over. As the sequence number is used for SRTP's default 926 ciphers, it is important that all endpoints know the value of the 927 ROC. The ROC starts at 0 at the beginning of a session. 929 Some keying mechanisms cause a two-time pad to occur if two endpoints 930 of a forked call have an SSRC collision. 932 Note: A proposal has been made to send the ROC value on every Nth 933 SRTP packet[RFC4771]. This proposal has not yet been incorporated 934 into this document. 936 The following list examines handling of SSRC and ROC: 938 MIKEY-NULL 939 Each endpoint indicates a set of SSRCs and the ROC for SRTP 940 packets it transmits. 942 MIKEY-PSK 943 Each endpoint indicates a set of SSRCs and the ROC for SRTP 944 packets it transmits. 946 MIKEY-RSA 947 Each endpoint indicates a set of SSRCs and the ROC for SRTP 948 packets it transmits. 950 MIKEY-RSA-R 951 Each endpoint indicates a set of SSRCs and the ROC for SRTP 952 packets it transmits. 954 MIKEY-DHSIGN 955 Each endpoint indicates a set of SSRCs and the ROC for SRTP 956 packets it transmits. 958 MIKEY-DHHMAC 959 Each endpoint indicates a set of SSRCs and the ROC for SRTP 960 packets it transmits. 962 MIKEYv2 in SDP 963 Each endpoint indicates a set of SSRCs and the ROC for SRTP 964 packets it transmits. 966 Security Descriptions with SIPS 967 Neither SSRC nor ROC are signaled. SSRC 'late binding' is 968 used. 970 Security Descriptions with S/MIME 971 Neither SSRC nor ROC are signaled. SSRC 'late binding' is 972 used. 974 SDP-DH 975 Neither SSRC nor ROC are signaled. SSRC 'late binding' is 976 used. 978 ZRTP 979 Neither SSRC nor ROC are signaled. SSRC 'late binding' is 980 used. 982 EKT 983 The SSRC of the SRTCP packet containing an EKT update 984 corresponds to the SRTP master key and other parameters within 985 that packet. 987 DTLS-SRTP 988 Neither SSRC nor ROC are signaled. SSRC 'late binding' is 989 used. 991 MIKEYv2 Inband 992 Each endpoint indicates a set of SSRCs and the ROC for SRTP 993 packets it transmits. 995 5. Evaluation Criteria - Security 997 This section evaluates each keying mechanism on the basis of their 998 security properties. 1000 5.1. Public Key Infrastructure 1002 There are two aspects of PKI requirements -- one aspect is if PKI is 1003 necessary in order for the mechanism to function at all, the other is 1004 if PKI is used to authenticate a certificate. With interactive 1005 communications it is desirable to avoid fetching certificates that 1006 delay call setup; rather it is preferable to fetch or validate 1007 certificates in such a way that call setup isn't delayed. For 1008 example, a certificate can be validated while the phone is ringing or 1009 can be validated while ring-back tones are being played or even while 1010 the called party is answering the phone and saying "hello". 1012 SRTP key exchange mechanisms that require a global PKI to operate are 1013 gated on the deployment of a common PKI available to both endpoints. 1014 This means that no media security is achievable until such a PKI 1015 exists. For SIP, something like sip-certs [I-D.ietf-sip-certs] might 1016 be used to obtain the certificate of a peer. 1018 Note: Even if Sip-certs was deployed, the retargeting problem 1019 (Section 4.1) would still prevent successful deployment of keying 1020 techniques which require the offerer to obtain the actual target's 1021 public key. 1023 The following list compares the PKI requirements of each keying 1024 mechanism, both if a PKI is required for the key exchange itself, and 1025 if PKI is only used to authenticate the certificate supplied in 1026 signaling. 1028 MIKEY-NULL 1029 PKI not used. 1031 MIKEY-PSK 1032 PKI not used; rather, all endpoints must have some way to 1033 exchange per-endpoint or per-system pre-shared keys. 1035 MIKEY-RSA 1036 The offerer obtains the intended answerer's public key before 1037 initiating the call. This public key is used to encrypt the 1038 SRTP keys. There is no defined mechanism for the offerer to 1039 obtain the answerer's public key, although [I-D.ietf-sip-certs] 1040 might be viable in the future. 1042 MIKEY-RSA-R 1043 The offer contains the offerer's public key. The answerer uses 1044 that public key to encrypt the SRTP keys that will be used by 1045 the offerer and the answerer. A PKI is necessary to validate 1046 the certificates. 1048 MIKEY-DHSIGN 1049 PKI is used to authenticate the public key that is included in 1050 the MIKEY message, by walking the CA trust chain. 1052 MIKEY-DHHMAC 1053 PKI not used; rather, all endpoints must have some way to 1054 exchange per-endpoint or per-system pre-shared keys. 1056 MIKEYv2 in SDP 1057 The behavior will depend on which mode is picked. 1059 Security Descriptions with SIPS 1060 PKI not used. 1062 Security Descriptions with S/MIME 1063 PKI is needed for S/MIME. The offerer must obtain the intended 1064 target's public key and encrypt their SDP with that key. The 1065 answerer must obtain the offerer's public key and encrypt their 1066 SDP with that key. 1068 SDP-DH 1069 PKI not used. 1071 ZRTP 1072 PKI not used. 1074 EKT 1075 PKI not used by EKT itself, but might be used by the EKT 1076 bootstrapping keying mechanism (such as certain MIKEY modes). 1078 DTLS-SRTP 1079 Remote party's certificate is sent in media path, and a 1080 fingerprint of the same certificate is sent in the signaling 1081 path. 1083 MIKEYv2 Inband 1084 The behavior will depend on which mode is picked. 1086 5.2. Perfect Forward Secrecy 1088 In the context of SRTP, Perfect Forward Secrecy is the property that 1089 SRTP session keys that protected a previous session are not 1090 compromised if the static keys belonging to the endpoints are 1091 compromised. That is, if someone were to record your encrypted 1092 session content and later acquires either party's private key, that 1093 encrypted session content would be safe from decryption if your key 1094 exchange mechanism had perfect forward secrecy. 1096 The following list describes how each key exchange mechanism provides 1097 PFS. 1099 MIKEY-NULL 1100 No PFS. 1102 MIKEY-PSK 1103 No PFS. 1105 MIKEY-RSA 1106 No PFS. 1108 MIKEY-RSA-R 1109 No PFS. 1111 MIKEY-DHSIGN 1112 PFS is provided with the Diffie-Hellman exchange. 1114 MIKEY-DHHMAC 1115 PFS is provided with the Diffie-Hellman exchange. 1117 MIKEYv2 in SDP 1118 The behavior will depend on which mode is picked. 1120 Security Descriptions with SIPS 1121 No PFS. 1123 Security Descriptions with S/MIME 1124 No PFS. 1126 SDP-DH 1127 PFS is provided with the Diffie-Hellman exchange. 1129 ZRTP 1130 PFS is provided with the Diffie-Hellman exchange. 1132 EKT 1133 No PFS. 1135 DTLS-SRTP 1136 PFS is achieved if the negotiated cipher suite includes an 1137 exponential or discrete-logarithmic key exchange (such as 1138 Diffie-Hellman or Elliptic Curve Diffie-Hellman [RFC4492]). 1140 MIKEYv2 Inband 1141 The behavior will depend on which mode is picked. 1143 5.3. Best Effort Encryption 1145 Note: With the ongoing efforts in SDP Capability Negotiation 1146 [I-D.ietf-mmusic-sdp-capability-negotiation], the conclusions 1147 reached in this section may no longer be accurate. 1149 With best effort encryption, SRTP is used with endpoints that support 1150 SRTP, otherwise RTP is used. 1152 SIP needs a backwards-compatible best effort encryption in order for 1153 SRTP to work successfully with SIP retargeting and forking when there 1154 is a mix of forked or retargeted devices that support SRTP and don't 1155 support SRTP. 1157 Consider the case of Bob, with a phone that only does RTP and a 1158 voice mail system that supports SRTP and RTP. If Alice calls Bob 1159 with an SRTP offer, Bob's RTP-only phone will reject the media 1160 stream (with an empty "m=" line) because Bob's phone doesn't 1161 understand SRTP (RTP/SAVP). Alice's phone will see this rejected 1162 media stream and may terminate the entire call (BYE) and re- 1163 initiate the call as RTP-only, or Alice's phone may decide to 1164 continue with call setup with the SRTP-capable leg (the voice mail 1165 system). If Alice's phone decided to re-initiate the call as RTP- 1166 only, and Bob doesn't answer his phone, Alice will then leave 1167 voice mail using only RTP, rather than SRTP as expected. 1169 Currently, several techniques are commonly considered as candidates 1170 to provide opportunistic encryption: 1172 multipart/alternative 1173 [I-D.jennings-sipping-multipart] describes how to form a 1174 multipart/alternative body part in SIP. The significant issues 1175 with this technique are (1) that multipart MIME is incompatible 1176 with existing SIP proxies, firewalls, Session Border Controllers, 1177 and endpoints and (2) when forking, the Heterogeneous Error 1178 Response Forking Problem (HERFP) [I-D.mahy-sipping-herfp-fix] 1179 causes problems if such non-multipart-capable endpoints were 1180 involved in the forking. 1182 SDP Grouping 1183 A new SDP grouping mechanism (following the idea introduced in 1184 [RFC3388]) has been discussed which would allow a media line to 1185 indicate RTP/AVP and another media line to indicate RTP/SAVP, 1186 allowing non-SRTP-aware endpoints to choose RTP/AVP and SRTP-aware 1187 endpoints to choose RTP/SAVP. As of this writing, this SDP 1188 grouping mechanism has not been published as an Internet Draft. 1190 session attribute 1191 With this technique, the endpoints signal their desire to do SRTP 1192 by signaling RTP (RTP/AVP), and using an attribute ("a=") in the 1193 SDP. This technique is entirely backwards compatible with non- 1194 SRTP-aware endpoints, but doesn't use the RTP/SAVP protocol 1195 registered by SRTP [RFC3711]. 1197 Probing 1198 With this technique, the endpoints first establish an RTP session 1199 using RTP (RTP/AVP). The endpoints send probe messages, over the 1200 media path, to determine if the remote endpoint supports their 1201 keying technique. 1203 The following list compares the availability of best effort 1204 encryption for each keying mechanism. 1206 MIKEY-NULL 1207 No best effort encryption. 1209 MIKEY-PSK 1210 No best effort encryption. 1212 MIKEY-RSA 1213 No best effort encryption. 1215 MIKEY-RSA-R 1216 No best effort encryption. 1218 MIKEY-DHSIGN 1219 No best effort encryption. 1221 MIKEY-DHHMAC 1222 No best effort encryption. 1224 MIKEYv2 in SDP 1225 No best effort encryption. 1227 Security Descriptions with SIPS 1228 No best effort encryption. 1230 Security Descriptions with S/MIME 1231 No best effort encryption. 1233 SDP-DH 1234 No best effort encryption. 1236 ZRTP 1237 Best effort encryption is done by probing (sending RTP messages 1238 with header extensions) or by session attribute (see "a=zrtp", 1239 defined in section 10 of [I-D.zimmermann-avt-zrtp]). Current 1240 implementations of ZRTP use probing. 1242 EKT 1243 No best effort encryption. 1245 DTLS-SRTP 1246 No best effort encryption. 1248 MIKEY Inband 1249 No best effort encryption. 1251 5.4. Upgrading Algorithms 1253 It is necessary to allow upgrading SRTP encryption and hash 1254 algorithms, as well as upgrading the cryptographic functions used for 1255 the key exchange mechanism. With SIP's offer/answer model, this can 1256 be computionally expensive because the offer needs to contain all 1257 combinations of the key exchange mechanisms (all MIKEY modes, 1258 Security Descriptions) and all SRTP cryptographic suites (AES-128, 1259 AES-256) and all SRTP cryptographic hash functions (SHA-1, SHA-256) 1260 that the offerer supports. In order to do this, the offerer has to 1261 expend CPU resources to build an offer containing all of this 1262 information which becomes computationally prohibitive. 1264 Thus, it is important to keep the offerer's CPU impact fixed so that 1265 offering multiple new SRTP encryption and hash functions incurs no 1266 additional expense. 1268 The following list describes the CPU effort involved in using each 1269 key exchange technique. 1271 MIKEY-NULL 1272 No significant computaional expense. 1274 MIKEY-PSK 1275 No significant computational expense. 1277 MIKEY-RSA 1278 For each offered SRTP crypto suite, the offerer has to perform 1279 RSA operation to encrypt the TGK 1281 MIKEY-RSA-R 1282 For each offered SRTP crypto suite, the offerer has to perform 1283 public key operation to sign the MIKEY message. 1285 MIKEY-DHSIGN 1286 For each offered SRTP crypto suite, the offerer has to perform 1287 Diffie-Hellman operation, and a public key operation to sign 1288 the Diffie-Hellman output. 1290 MIKEY-DHHMAC 1291 For each offered SRTP crypto suite, the offerer has to perform 1292 Diffie-Hellman operation. 1294 MIKEYv2 in SDP 1295 The behavior will depend on which mode is picked. 1297 Security Descriptions with SIPS 1298 No significant computational expense. 1300 Security Descriptions with S/MIME 1301 S/MIME requires the offerer and the answerer to encrypt the SDP 1302 with the other's public key, and to decrypt the received SDP 1303 with their own private key. 1305 SDP-DH 1306 For each offered SRTP crypto suite, the offerer has to perform 1307 a Diffie-Hellman operation. 1309 ZRTP 1310 The offerer has no additional computational expense at all, as 1311 the offer contains no information about ZRTP or might contain 1312 "a=zrtp". 1314 EKT 1315 The offerer's Computational expense depends entirely on the EKT 1316 bootstrapping mechanism selected (one or more MIKEY modes or 1317 Security Descriptions). 1319 DTLS-SRTP 1320 The offerer has no additional computational expense at all, as 1321 the offer contains only a fingerprint of the certificate that 1322 will be presented in the DTLS exchange. 1324 MIKEYv2 Inband 1325 The behavior will depend on which mode is picked. 1327 6. Security Considerations 1329 This entire document discusses security. 1331 7. Acknowledgements 1333 Special thanks to Steffen Fries and Dragan Ignjatic for their 1334 excellent MIKEY comparison document 1335 [I-D.ietf-msec-mikey-applicability]. 1337 Thanks also to Cullen Jennings, David Oran, David McGrew, Mark 1338 Baugher, Flemming Andreasen, Eric Raymond, Dave Ward, Leo Huang, Eric 1339 Rescorla, Lakshminath Dondeti, Steffen Fries, Alan Johnston, Dragan 1340 Ignjatic and John Elwell for their assistance with this document. 1342 8. IANA Considerations 1344 This document does not add new IANA registrations. 1346 9. References 1348 9.1. Normative References 1350 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1351 A., Peterson, J., Sparks, R., Handley, M., and E. 1352 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1353 June 2002. 1355 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1356 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1357 RFC 3711, March 2004. 1359 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1360 Authenticated Identity Management in the Session 1361 Initiation Protocol (SIP)", RFC 4474, August 2006. 1363 9.2. Informational References 1365 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 1366 Carrara, "Key Management Extensions for Session 1367 Description Protocol (SDP) and Real Time Streaming 1368 Protocol (RTSP)", RFC 4567, July 2006. 1370 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1371 Description Protocol (SDP) Security Descriptions for Media 1372 Streams", RFC 4568, July 2006. 1374 [I-D.ietf-mmusic-securityprecondition] 1375 Andreasen, F. and D. Wing, "Security Preconditions for 1376 Session Description Protocol (SDP) Media Streams", 1377 draft-ietf-mmusic-securityprecondition-03 (work in 1378 progress), October 2006. 1380 [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for 1381 Multimedia Internet KEYing (MIKEY)", RFC 4650, 1382 September 2006. 1384 [I-D.ietf-msec-mikey-ecc] 1385 Milne, A., "ECC Algorithms for MIKEY", 1386 draft-ietf-msec-mikey-ecc-01 (work in progress), 1387 October 2006. 1389 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 1390 RSA-R: An Additional Mode of Key Distribution in 1391 Multimedia Internet KEYing (MIKEY)", RFC 4738, 1392 November 2006. 1394 [I-D.ietf-sip-certs] 1395 Jennings, C., "Certificate Management Service for The 1396 Session Initiation Protocol (SIP)", 1397 draft-ietf-sip-certs-02 (work in progress), October 2006. 1399 [I-D.mahy-sipping-herfp-fix] 1400 Mahy, R., "A Solution to the Heterogeneous Error Response 1401 Forking Problem (HERFP) in the Session Initiation 1402 Protocol (SIP)", draft-mahy-sipping-herfp-fix-01 (work in 1403 progress), March 2006. 1405 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1406 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1407 August 2004. 1409 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1410 with Session Description Protocol (SDP)", RFC 3264, 1411 June 2002. 1413 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1414 Provisional Responses in Session Initiation Protocol 1415 (SIP)", RFC 3262, June 2002. 1417 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1418 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1419 for Transport Layer Security (TLS)", RFC 4492, May 2006. 1421 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 1422 Schulzrinne, "Grouping of Media Lines in the Session 1423 Description Protocol (SDP)", RFC 3388, December 2002. 1425 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1426 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1428 [I-D.fischl-sipping-media-dtls] 1429 Fischl, J., "Datagram Transport Layer Security (DTLS) 1430 Protocol for Protection of Media Traffic Established with 1431 the Session Initiation Protocol", 1432 draft-fischl-sipping-media-dtls-01 (work in progress), 1433 June 2006. 1435 [I-D.ietf-msec-mikey-applicability] 1436 Fries, S. and D. Ignjatic, "On the applicability of 1437 various MIKEY modes and extensions", 1438 draft-ietf-msec-mikey-applicability-03 (work in progress), 1439 December 2006. 1441 [I-D.zimmermann-avt-zrtp] 1442 Zimmermann, P., "ZRTP: Extensions to RTP for Diffie- 1443 Hellman Key Agreement for SRTP", 1444 draft-zimmermann-avt-zrtp-02 (work in progress), 1445 October 2006. 1447 [I-D.baugher-mmusic-sdp-dh] 1448 Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for 1449 Multimedia Sessions", draft-baugher-mmusic-sdp-dh-00 (work 1450 in progress), February 2006. 1452 [I-D.mcgrew-srtp-ekt] 1453 McGrew, D., "Encrypted Key Transport for Secure RTP", 1454 draft-mcgrew-srtp-ekt-01 (work in progress), June 2006. 1456 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1457 Transform Carrying Roll-Over Counter for the Secure Real- 1458 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1460 [I-D.peterson-sipping-retarget] 1461 Peterson, J., "Retargeting and Security in SIP: A 1462 Framework and Requirements", 1463 draft-peterson-sipping-retarget-00 (work in progress), 1464 February 2005. 1466 [I-D.ietf-mmusic-ice] 1467 Rosenberg, J., "Interactive Connectivity Establishment 1468 (ICE): A Methodology for Network Address Translator (NAT) 1469 Traversal for Offer/Answer Protocols", 1470 draft-ietf-mmusic-ice-13 (work in progress), January 2007. 1472 [I-D.ietf-sip-connected-identity] 1473 Elwell, J., "Connected Identity in the Session Initiation 1474 Protocol (SIP)", draft-ietf-sip-connected-identity-04 1475 (work in progress), January 2007. 1477 [I-D.jennings-sipping-multipart] 1478 Wing, D. and C. Jennings, "Session Initiation Protocol 1479 (SIP) Offer/Answer with Multipart Alternative", 1480 draft-jennings-sipping-multipart-02 (work in progress), 1481 March 2006. 1483 [I-D.mcgrew-tls-srtp] 1484 Rescorla, E. and D. McGrew, "Datagram Transport Layer 1485 Security (DTLS) Extension to Establish Keys for Secure 1486 Real-time Transport Protocol (SRTP)", 1487 draft-mcgrew-tls-srtp-00 (work in progress), June 2006. 1489 [I-D.dondeti-msec-rtpsec-mikeyv2] 1490 Dondeti, L., "MIKEYv2: SRTP Key Management using MIKEY, 1491 revisited", draft-dondeti-msec-rtpsec-mikeyv2-00 (work in 1492 progress), June 2006. 1494 [I-D.ietf-mmusic-sdp-capability-negotiation] 1495 Andreasen, F., "SDP Capability Negotiation", 1496 draft-ietf-mmusic-sdp-capability-negotiation-01 (work in 1497 progress), January 2007. 1499 Appendix A. Changelog 1501 Note to RFC Editor: this appendix should be removed prior to 1502 publication. 1504 A.1. Changes from -01 to -02 1506 o Removed DTLS-RTP 1508 o Added note about SDP Capability Negotiation and its impact on 1509 best-effort SRTP 1511 A.2. Changes from -00 to -01 1513 o Added MIKEYv2 as part of the main proposals. 1515 o Removed retargeting as a problem for best-effort encryption's 1516 multipart/alternative 1518 o "Opportunistic encryption" to "best-effort encryption" 1520 o Added 'Upgrading Algorithm' section 1522 o Separate analysis of 'Security Descriptions with SIPS' and 1523 'Security Descriptions with S/MIME' 1525 Authors' Addresses 1527 Francois Audet 1528 Nortel 1529 4655 Great America Parkway 1530 Santa Clara, CA 95054 1531 USA 1533 Email: audet@nortel.com 1535 Dan Wing 1536 Cisco Systems 1537 170 West Tasman Drive 1538 San Jose, CA 95134 1539 USA 1541 Email: dwing@cisco.com 1543 Full Copyright Statement 1545 Copyright (C) The IETF Trust (2007). 1547 This document is subject to the rights, licenses and restrictions 1548 contained in BCP 78, and except as set forth therein, the authors 1549 retain all their rights. 1551 This document and the information contained herein are provided on an 1552 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1553 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1554 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1555 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1556 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1557 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1559 Intellectual Property 1561 The IETF takes no position regarding the validity or scope of any 1562 Intellectual Property Rights or other rights that might be claimed to 1563 pertain to the implementation or use of the technology described in 1564 this document or the extent to which any license under such rights 1565 might or might not be available; nor does it represent that it has 1566 made any independent effort to identify any such rights. Information 1567 on the procedures with respect to rights in RFC documents can be 1568 found in BCP 78 and BCP 79. 1570 Copies of IPR disclosures made to the IETF Secretariat and any 1571 assurances of licenses to be made available, or the result of an 1572 attempt made to obtain a general license or permission for the use of 1573 such proprietary rights by implementers or users of this 1574 specification can be obtained from the IETF on-line IPR repository at 1575 http://www.ietf.org/ipr. 1577 The IETF invites any interested party to bring to its attention any 1578 copyrights, patents or patent applications, or other proprietary 1579 rights that may cover technology that may be required to implement 1580 this standard. Please address the information to the IETF at 1581 ietf-ipr@ietf.org. 1583 Acknowledgment 1585 Funding for the RFC Editor function is provided by the IETF 1586 Administrative Support Activity (IASA).