idnits 2.17.00 (12 Aug 2021) /tmp/idnits47615/draft-wing-srtp-keying-eval-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1373. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1240 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 (May 25, 2006) is 5839 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) == Unused Reference: 'I-D.ietf-sip-identity' is defined on line 1191, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mmusic-securityprecondition' is defined on line 1211, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sipping-certs' is defined on line 1232, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-msec-mikey-applicability' is defined on line 1271, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tls-ecc' is defined on line 1298, but no explicit reference was found in the text == Unused Reference: 'I-D.peterson-sipping-retarget' is defined on line 1302, but no explicit reference was found in the text == Outdated reference: draft-ietf-sip-identity has been published as RFC 4474 == Outdated reference: draft-ietf-mmusic-sdescriptions has been published as RFC 4568 == Outdated reference: draft-ietf-mmusic-kmgmt-ext has been published as RFC 4567 == Outdated reference: draft-ietf-mmusic-securityprecondition has been published as RFC 5027 == Outdated reference: draft-ietf-msec-mikey-dhhmac has been published as RFC 4650 == Outdated reference: A later version (-03) exists of draft-ietf-msec-mikey-ecc-00 == Outdated reference: draft-ietf-msec-mikey-rsa-r has been published as RFC 4738 -- 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-00 == Outdated reference: A later version (-04) exists of draft-fischl-mmusic-sdp-dtls-00 == Outdated reference: draft-ietf-msec-mikey-applicability has been published as RFC 5197 == Outdated reference: draft-zimmermann-avt-zrtp has been published as RFC 6189 == Outdated reference: A later version (-06) exists of draft-mcgrew-srtp-ekt-00 == Outdated reference: draft-lehtovirta-srtp-rcc has been published as RFC 4771 == Outdated reference: draft-ietf-tls-ecc has been published as RFC 4492 == Outdated reference: draft-ietf-mmusic-ice has been published as RFC 5245 == Outdated reference: draft-ietf-sip-connected-identity has been published as RFC 4916 == Outdated reference: A later version (-02) exists of draft-mcgrew-tls-srtp-00 Summary: 3 errors (**), 0 flaws (~~), 26 warnings (==), 9 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 Expires: November 26, 2006 D. Wing 5 Cisco Systems 6 May 25, 2006 8 Evaluation of SRTP Keying with SIP 9 draft-wing-srtp-keying-eval-00 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 November 26, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . 7 64 3.1.9. SDP-DH . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2. Media Path Keying Technique . . . . . . . . . . . . . . . 7 66 3.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.3. Signaling and Media Path Keying Techniques . . . . . . . . 8 68 3.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.3.2. RTP-DTLS . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.3.3. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 9 71 4. Evaluation Criteria - SIP . . . . . . . . . . . . . . . . . . 9 72 4.1. Secure Retargeting and Secure Forking . . . . . . . . . . 9 73 4.2. Clipping Media Before SDP Answer . . . . . . . . . . . . . 14 74 4.3. Centralized Keying . . . . . . . . . . . . . . . . . . . . 16 75 4.4. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . . . 19 76 5. Evaluation Criteria - Security . . . . . . . . . . . . . . . . 21 77 5.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 21 78 5.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 23 79 5.3. Opportunistic Encryption . . . . . . . . . . . . . . . . . 24 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 85 9.2. Informational References . . . . . . . . . . . . . . . . . 27 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 87 Intellectual Property and Copyright Statements . . . . . . . . . . 32 89 1. Introduction 91 SIP needs to operate across the world-wide public Internet and thus 92 needs a single, mandatory-to-implement mechanism for strongly 93 authenticating an endpoint. It is likely that the mechanism will be 94 based on RSA, Diffie-Hellman, or Digital Signature Standard (DSS) but 95 cannot rely on an X.509 PKI or pre-shared keys. 97 There are currently 13 mechanisms defined or under consideration by 98 the IETF to establish SRTP [RFC3711] keys between endpoints. 99 Although an endpoint can implement several mechanisms, these 13 100 mechanisms are not interoperable with each other. The mechanisms can 101 be broken into three general categories for exchanging SRTP keying: 102 exchanging keys in signaling, media, or both. 104 The goals of an SRTP key exchange mechanism are, in rough order: 106 1. Ability to deploy the mechanism across administrative boundaries, 107 such as on the Internet, 108 2. Cryptographically authenticate the endpoints, 109 3. Securely exchange SRTP keys, 110 4. Support SIP features such as retargeting and forking. 112 Existing key exchange mechanisms fail to meet all of these 113 requirements. 115 Two mechanisms, MIKEY and Security Descriptions, have been 116 standardized for SRTP key exchange. Both of these mechanisms perform 117 key exchange in the signaling path (SIP or RTSP). 119 All MIKEY modes share a common syntax (a=key-mgmt, defined in Key 120 Management Extensions for Session Description Protocol (SDP) and Real 121 Time Streaming Protocol (RTSP) [I-D.ietf-mmusic-kmgmt-ext]). The 122 base MIKEY specification [RFC3830] defines four MIKEY modes and 123 additional modes are defined in other specifications. MIKEY modes 124 are not compatible with each other. 126 The other standard mechanism, Security Descriptions, uses a different 127 syntax (a=crypto, defined in Security Descriptions [I-D.ietf-mmusic- 128 sdescriptions]). 130 Several extensions to MIKEY have been proposed and several techniques 131 which perform some, or all, keying in the media path have been 132 proposed. These new techniques are also discussed in this document. 134 Out of scope of this document is how SIP, RTSP, and SDP messages 135 themselves are encrypted. 137 Call signaling (new call, end of call, call transfer, etc.) is done 138 in SIP, and media is sent in RTP. In the following diagram, Alice is 139 calling Bob. This causes Alice to emit a SIP message to her SIP 140 proxy, which processes the message and routes the message to Bob's 141 proxy which then routes it to Bob. 143 +---------+ SIP Invite +-------| 144 | Alice's +------------------>+ Bob's | 145 | proxy | | proxy | 146 +----+----+ +---+---| 147 ^ | 148 SIP Invite | | SIP Invite 149 | V 150 +---+---+ +-----+ 151 | Alice |<===================>+ Bob | 152 +-------+ SRTP +-----+ 154 Figure 1: Simplified SIP Model 156 2. Terminology 158 AOR (Address-of-Record): A SIP or SIPS URI that points to a domain 159 with a location service that can map the URI to another URI where 160 the user might be available. Typically, the location service is 161 populated through registrations. An AOR is frequently thought of 162 as the "public address" of the user. 164 SSRC: The 32-bit value that defines the synchronization source, 165 used in RTP. These are generally unique, but collisions can 166 occur. 167 two-time pad: The use of the same key and the same key index to 168 encrypt different data. For SRTP, a two-time pad occurs if two 169 senders are using the same key and the same RTP SSRC value. 171 3. Overview of Keying Mechanisms 173 Based on how the SRTP keys are exchanged, each SRTP key exchange 174 mechanism belongs to one general category: 176 signaling path: 177 All the keying is carried in the call signaling (SIP or SDP) 178 path. 179 media path: 180 All the keying is carried in the SRTP/SRTCP media path, and no 181 signaling whatsoever is carried in the call signaling path. 182 signaling and media path: 183 Parts of the keying are carried in the SRTP/SRTCP media path, 184 and parts are carried in the call signaling (SIP or SDP) path. 186 One of the significant benefits of SRTP over other end-to-end 187 encryption mechanisms, such as for example IPsec, is that SRTP is 188 bandwidth efficient and SRTP retains the header of RTP packets. 189 Bandwidth efficiency is vital for VoIP in many scenarios where access 190 bandwidth is limited or expensive, and retaining the RTP header is 191 important for troubleshooting packet loss, delay, and jitter. 193 Related to SRTP's characteristics is a goal that any SRTP keying 194 mechanism to also be efficient and not cause additional call setup 195 delay. Contributors to additional call setup delay include network 196 or database operations: retrieval of certificates and additional SIP 197 or media path messages, and computational overhead of establishing 198 keys or validating certificates. 200 When examining the choice between keying in the signaling path, 201 keying in the media path, or keying in both paths, it is important to 202 realize the media path is generally 'faster' than the SIP signaling 203 path. The SIP signaling path has computational elements involved 204 which parse and route SIP messages. The media path, on the other 205 hand, does not normally have computational elements involved, and 206 even when computational elements such as firewalls are involved, they 207 cause very little additional delay. Thus, the media path can be 208 useful for exchanging several messages to establish SRTP keys. 210 3.1. Signaling Path Keying Techniques 212 3.1.1. MIKEY-NULL 214 MIKEY-NULL [RFC3830] has the offerer indicate the SRTP keys for both 215 directions. The key is sent unencrypted in SDP, which means the SDP 216 must be encrypted hop-by-hop (e.g., by using TLS (SIPS)) or end-to- 217 end (e.g., by using S/MIME). 219 MIKEY-NULL requires one message from offerer to answerer (half a 220 round trip), and does not add additional media path messages. 222 3.1.2. MIKEY-PSK 224 MIKEY-PSK (pre-shared key) [RFC3830] requires that all endpoints 225 share one common key. MIKEY-PSK has the offerer encrypt the SRTP 226 keys for both directions using this pre-shared key. 228 MIKEY-PSK requires one message from offerer to answerer (half a round 229 trip), and does not add additional media path messages. 231 3.1.3. MIKEY-RSA 233 MIKEY-RSA [RFC3830] has the offerer encrypt the keys for both 234 directions using the intended answerer's public key, which is 235 obtained from a PKI. 237 MIKEY-RSA requires one message from offerer to answerer (half a round 238 trip), and does not add additional media path messages. MIKEY-RSA 239 requires the offerer to obtain the intended answerer's certificate. 241 3.1.4. MIKEY-RSA-R 243 MIKEY-RSA-R An additional mode of key distribution in MIKEY: MIKEY- 244 RSA-R [I-D.ietf-msec-mikey-rsa-r] is essentially the same as MIKEY- 245 RSA-R but reverses the role of the offerer and the answerer with 246 regards to providing the keys. That is, the answerer encrypts the 247 keys for both directions using the offerer's public key. Both the 248 offerer and answerer validate each other's public keys using a PKI. 249 MIKEY-RSA-R also enables sending certificates in the MIKEY message. 251 MIKEY-RSA-R requires one message from offerer to answer, and one 252 message from answerer to offerer (full round trip), and does not add 253 additional media path messages. MIKEY-RSA-R requires the offerer 254 validate the answerer's certificate. 256 3.1.5. MIKEY-DHSIGN 258 In MIKEY-DHSIGN [RFC3830] the offerer and answerer derive the key 259 from a Diffie-Hellman exchange. In order to prevent an active man- 260 in-the-middle the DH exchange itself is signed using each endpoint's 261 private key and the associated public keys are validated using a PKI. 263 MIKEY-DHSIGN requires one message from offerer to answerer, and one 264 message from answerer to offerer (full round trip), and does not add 265 additional media path messages. MIKEY-DHSIGN requires the offerer 266 and answerer to validate each other's certificates. MIKEY-DHSIGN 267 also enables sending the answerer's certificate in the MIKEY message. 269 3.1.6. MIKEY-DHHMAC 271 MIKEY-DHHMAC [I-D.ietf-msec-mikey-dhhmac] uses a pre-shared secret to 272 HMAC the Diffie-Hellman exchange, essentially combining aspects of 273 MIKEY-PSK with MIKEY-DHSIGN, but without MIKEY-DHSIGN's need for a 274 PKI to authenticate the Diffie-Hellman exchange. 276 MIKEY-DHHMAC requires one message from offerer to answerer, and one 277 message from answerer to offerer (full round trip), and does not add 278 additional media path messages. 280 3.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) 282 ECC Algorithms For MIKEY [I-D.ietf-msec-mikey-ecc] describes how ECC 283 can be used with MIKEY-RSA (using ECDSA signature) and with MIKEY- 284 DHSIGN (using a new DH-Group code), and also defines two new ECC- 285 based algorithms, Elliptic Curve Integrated Encryption Scheme (ECIES) 286 and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) . 288 For the purposes of this paper, the ECDSA signature, MIKEY-ECIES, and 289 MIKEY-ECMQV function exactly like MIKEY-RSA, and the new DH-Group 290 code function exactly like MIKEY-DHSIGN. Therefore these ECC 291 mechanisms aren't discussed separately in this paper. 293 3.1.8. Security Descriptions 295 Security Descriptions [I-D.ietf-mmusic-sdescriptions] has each side 296 indicate the key it will use for transmitting SRTP media, and the 297 keys are sent in the clear in SDP. Security Descriptions relies on 298 hop-by-hop (TLS via SIPS) or end-to-end (S/MIME) encryption to 299 protect the keys exchanged in signaling. 301 Security Descriptions requires one message from offerer to answerer, 302 and one message from answerer to offerer (full round trip), and does 303 not add additional media path messages. 305 3.1.9. SDP-DH 307 SDP Diffie-Hellman [I-D.baugher-mmusic-sdp-dh] exchanges Diffie- 308 Hellman messages in the signaling path to establish session keys. 310 SDP-DH requires one message from offerer to answerer, and one message 311 from answerer to offerer (full round trip), and does not add 312 additional media path messages. 314 3.2. Media Path Keying Technique 315 3.2.1. ZRTP 317 ZRTP [I-D.zimmermann-avt-zrtp] does not exchange information in the 318 signaling path (although it's possible for endpoints to do so if they 319 desire). In ZRTP the keys are exchanged entirely in the media path. 320 The advantage to this mechanism is that the signaling channel is used 321 only for call setup and the media channel is used to establish an 322 encrypted channel -- much like encryption devices on the PSTN. ZRTP 323 uses voice authentication of the DH exchange by having each person 324 read digits to the other person. Subsequent sessions with the same 325 peer can be authenticated using a hash of the previously negotiated 326 key rather than voice authentication. 328 ZRTP uses 4 media path messages (Hello, Commit, DHPart1, and DHPart2) 329 to establish the SRTP key, and 3 media path confirmation messages. 330 The first 4 are sent as RTP packets (using RTP header extensions), 331 and the last 3 are sent in conjunction with SRTP media packets (again 332 as SRTP header extensions). Note that unencrypted RTP is being 333 exchanged until the SRTP keys are established. 335 3.3. Signaling and Media Path Keying Techniques 337 3.3.1. EKT 339 EKT [I-D.mcgrew-srtp-ekt] relies on another SRTP key exchange 340 protocol, such as Security Descriptions or MIKEY, for bootstrapping. 341 In the initial phase, each member of a conference uses an SRTP key 342 exchange protocol to establish a common key encryption key (KEK). 343 Each member may use the KEK to securely transport its SRTP master key 344 and current SRTP rollover counter (ROC), via RTCP, to the other 345 participants in the session. 347 EKT requires the offerer to send some parameters (EKT_Cipher, KEK, 348 and security parameter index (SPI)) via the bootstrapping protocol 349 such as Security Descriptions or MIKEY. Each answerer sends an SRTCP 350 message which contains the answerer's SRTP Master Key, rollover 351 counter, and the SRTP sequence number. Rekeying is done by sending a 352 new SRTCP message. For reliable transport, multiple RTCP messages 353 need to be sent. 355 3.3.2. RTP-DTLS 357 RTP-DTLS [I-D.fischl-mmusic-sdp-dtls] exchanges public key 358 fingerprints in SDP and then establishes a DTLS session over the 359 media channel [I-D.fischl-sipping-media-dtls]. The endpoints use the 360 DTLS handshake to agree on crypto suites and establish DTLS session 361 keys. Once established, the endpoints use a modified DTLS mode to 362 exchange encrypted media packets on the wire. These encrypted media 363 packets closely resemble SRTP's on-the-wire format, most importantly 364 by retaining the same RTP header as RTP packets so that header 365 compression and RTP analysis tools can be used. However, these 366 packets are not compatible with SRTP [RFC3711]. 368 The authors of this mechanism have deprecated the mechanism in favor 369 of DTLS-SRTP (Section 3.3.3). 371 3.3.3. DTLS-SRTP 373 DTLS-SRTP [I-D.draft-mcgrew-dtls-srtp] exchanges public key 374 fingerprints in SDP and then establishes a DTLS session over the 375 media channel. The endpoints use the DTLS handshake to agree on 376 crypto suites and establish SRTP session keys. SRTP packets are then 377 exchanged between the endpoints. 379 DTLS-SRTP requires one message from offerer to answerer (half round 380 trip), and, if the offerer wishes to correlate the SDP answer with 381 the endpoint, requires one message from answer to offerer (full round 382 trip). DTLS-SRTP uses 4 media path messages to establish the SRTP 383 key. 385 This paper assumes DTLS will use TLS_RSA_WITH_3DES_EDE_CBC_SHA as its 386 cipher suite, which is the mandatory-to-implement cipher suite in TLS 387 [RFC4346]. 389 4. Evaluation Criteria - SIP 391 This section considers how each keying mechanism interacts with SIP 392 features. 394 4.1. Secure Retargeting and Secure Forking 395 In SIP, a request sent to a specific AOR but delivered to a different 396 AOR is called a "retarget". A typical scenario is a "call 397 forwarding" feature. In the figure below, Alice sends an Invite in 398 step 1 which is sent to Bob in step 2. Bob responds with a redirect 399 (SIP response code 3xx) pointing to Carol in step 3. This redirect 400 typically does not propagate back to Alice but only goes to a proxy 401 (i.e., the retargeting proxy) which sends the original Invite to 402 Carol in step 4. 404 +-----+ 405 |Alice| 406 +--+--+ 407 | 408 | Invite (1) 409 V 410 +----+----+ 411 | proxy | 412 ++-+-----++ 413 | ^ | 414 Invite (2) | | | Invite (4) 415 & redirect (3) | | | 416 V | V 417 ++-++ ++----+ 418 |Bob| |Carol| 419 +---+ +-----+ 421 Figure 2: Retargeting 423 Successful use of SRTP requires strongly identifying both calling 424 party and the called party. The mechanism used by SIP for 425 identifying the calling party is SIP Identity [I-D.ietf-sip- 426 identity]. However, due to SIP retargeting issues [I-D.peterson- 427 sipping-retarget], SIP Identity can only identify the calling party 428 (that is, the party that initiated the SIP request). Some key 429 exchange mechanisms predate SIP Identity and include their own 430 identity mechanism. However, those built-in identity mechanism 431 suffer from the same SIP retargeting problem described in the above 432 draft. Going forward, it is anticipated that Connected Identity 433 [I-D.ietf-sip-connected-identity] may allow identifying the called 434 party. In the list below, this is described as the 'retargeting 435 identity' problem. 437 In SIP, 'forking' is the delivery of a request to multiple locations. 438 This happens when a single AOR is registered more than once. An 439 example of forking is when a user has a desk phone, PC client, and 440 mobile handset all registered with the same AOR. 442 +-----+ 443 |Alice| 444 +--+--+ 445 | 446 | Invite 447 V 448 +-----+-----+ 449 | proxy | 450 ++---------++ 451 | | 452 Invite | | Invite 453 V V 454 +--+--+ +--+--+ 455 |Bob-1| |Bob-2| 456 +-----+ +-----+ 458 Figure 3: Forking 460 With forking, both Bob-1 and Bob-2 might send back SDP answers in SIP 461 responses. Alice will see those intermediate (18x) and final (200) 462 responses. It is useful for Alice to be able to associate the SIP 463 response with the incoming media stream. Although this association 464 can be done with ICE [I-D.ietf-mmusic-ice], and ICE is useful to make 465 this association with RTP, it isn't desirable to require ICE to 466 accomplish this association. The table below analyzes if it is 467 possible for an offerer to associate the media stream with each SDP 468 answer, without using ICE. 470 Forking and retargeting are often used together. For example, a boss 471 and secretary might have both phones ring and rollover to voice mail 472 if neither phone is answered. 474 To maintain media security, only the endpoint that answers the call 475 should know the SRTP keys for the session. For key exchange 476 mechanisms that don't provide secure forking or secure retargeting, 477 one workaround is to rekey immediately after forking or retargeting. 478 However, because the originator may not be aware that the call forked 479 this mechanism requires rekeying immediately after every session is 480 established which causes additional signaling messages. 482 Retargeting securely introduces a more significant problem. With 483 retargeting, the actual recipient of the request is not the original 484 recipient. This means that if the offerer encrypted material (such 485 as the session key or the SDP) using the original recipient's public 486 key, the recipient will not be able to decrypt that material because 487 the actual recipient won't have the original recipient's private key. 488 In some cases, this is the intended behavior, i.e., you wanted to 489 establish a secure connection with a specific individual. In other 490 cases, it is not intended behavior (you want all voice media to be 491 encrypted, regardless of who answers). 493 Further compounding this problem is a particularity of SIP that when 494 forking is used, there is always only one final error response 495 delivered to the sender of the request: the forking proxy is 496 responsible for choosing which final response to choose in the event 497 where forking results in multiple final error responses being 498 received by the forking proxy. This means that if a request is 499 rejected, say with information that the keying information was 500 rejected and providing the far end-end's credentials, it is very 501 possible that the rejection will never reach the sender. This 502 problem, called the Heterogeneous Error Response Forking Problem 503 (HERFP) [I-D.mahy-sipping-herfp-fix] is a complicated problem to 504 solve in SIP. 506 The following list compares the behavior of secure forking, answering 507 association, two-time pads, and secure retargeting for each keying 508 mechanism. 510 MIKEY-NULL 511 Secure Forking: No, all AORs see offerer's and answerer's 512 keys. Answer is associated with media by the SSRC in MIKEY. 513 Additionally, a two-time pad occurs if two branches choose the 514 same 32-bit SSRC and transmit SRTP packets. 516 Secure Retargeting: No, all targets see offerer's and 517 answerer's keys. Suffers from retargeting identity problem. 519 MIKEY-PSK 520 Secure Forking: No, all AORs see offerer's and answerer's 521 keys. Answer is associated with media by the SSRC in MIKEY. 522 Note that all AORs must share the same pre-shared key in order 523 for forking to work at all with MIKEY-PSK. Additionally, a 524 two-time pad occurs if two branches choose the same 32-bit SSRC 525 and transmit SRTP packets. 527 Secure Retargeting: Not secure. For retargeting to work, the 528 final target must possess the correct PSK. As this is likely 529 in scenarios were the call is targeted to another device 530 belonging to the same user (forking), it is very unlikely that 531 other users will possess that PSK and be able to successfully 532 answer that call. 534 MIKEY-RSA 535 Secure Forking: No, all AORs see offerer's and answerer's 536 keys. Answer is associated with media by the SSRC in MIKEY. 537 Note that all AORs must share the same private key in order for 538 forking to work at all with MIKEY-RSA. Additionally, a two- 539 time pad occurs if two branches choose the same 32-bit SSRC and 540 transmit SRTP packets. 542 Secure Retargeting: No. 544 MIKEY-RSA-R 545 Secure Forking: Yes. Answer is associated with media by the 546 SSRC in MIKEY. 548 Secure Retargeting: Yes. 550 MIKEY-DHSIGN 551 Secure Forking: Yes, each forked endpoint negotiates unique 552 keys with the offerer for both directions. Answer is 553 associated with media by the SSRC in MIKEY. 555 Secure Retargeting: Yes, each target negotiates unique keys 556 with the offerer for both directions. 558 MIKEY-DHHMAC 559 Secure Forking: Yes, each forked endpoint negotiates unique 560 keys with the offerer for both directions. Answer is 561 associated with media by the SSRC in MIKEY. 563 Secure Retargeting: Yes, each target negotiates unique keys 564 with the offerer for both directions. Note that for the keys 565 to be meaningful, it would require the PSK to be the same for 566 all the potential intermediaries, which would only happen 567 within a single domain. 569 Security Descriptions 570 Secure Forking: No. Each forked endpoint sees the offerer's 571 key. Answer is not associated with media. 573 Secure Retargeting: No. Each target sees the offerer's key. 575 SDP-DH 576 Secure Forking: Yes. Each forked endpoint calculates a unique 577 SRTP key. Answer is not associated with media. 579 Secure Retargeting: Yes. The final target calculates a unique 580 SRTP key. 582 ZRTP 583 Secure Forking: Yes. Each forked endpoint calculates a unique 584 SRTP key. As ZRTP isn't signaled in SDP, there is no 585 association of the answer with media. 587 Secure Retargeting: Yes. The final target calculates a unique 588 SRTP key. 590 EKT 591 Secure Forking: Inherited from the bootstrapping mechanism 592 (the specific MIKEY mode or Security Descriptions). Answer is 593 associated with media by the SPI in the EKT protocol. Answer 594 is associated with media by the SPI in the EKT protocol. 596 Secure Retargeting: Inherited from the bootstrapping mechanism 597 (the specific MIKEY mode or Security Descriptions). 599 RTP-DTLS 600 Secure Forking: Yes. Each forked endpoint calculates a unique 601 SRTP key. Answer is associated with media by the certificate 602 fingerprint in signaling and certificate in the media path. 604 Secure Retargeting: Yes. The final target calculates a unique 605 SRTP key. 607 DTLS-SRTP 608 Secure Forking: Yes. Each forked endpoint calculates a unique 609 SRTP key. Answer is associated with media by the certificate 610 fingerprint in signaling and certificate in the media path. 612 Secure Retargeting: Yes. The final target calculates a unique 613 SRTP key. 615 4.2. Clipping Media Before SDP Answer 617 With RTP, the offerer is able to play out any media that arrives 618 prior to the SDP answer arriving if the answerer uses the same 619 payload types as the offerer, as is common practice. To avoid 620 clipping, the offerer immediately plays out media as soon as it is 621 received, even if it hasn't yet received the answer. With SRTP, 622 however, the offerer needs to know the SRTP key in order to decrypt 623 the media before it can play the media. If the SRTP media arrives 624 before the associated SRTP key, the offerer cannot play the media -- 625 causing clipping. 627 For key exchange mechanisms which send the answerer's key in SDP, a 628 SIP provisional response [RFC3261] such as 183 (session progress) is 629 useful. However the 183 messages aren't reliable unless both the 630 calling and called endpoint support PRACK [RFC3262], use TCP across 631 all SIP proxies, implement Security Preconditions [I-D.ietf-mmusic- 632 securityprecondition], or the both ends implement ICE [I-D.ietf- 633 mmusic-ice] and the answerer implements the reliable provisional 634 response mechanism described in ICE. However, there is not wide 635 deployment of any of these techniques and there is industry 636 reluctance to requiring these techniques as solutions to avoid the 637 problem described in this section. 639 Furthermore, the problem gets compounded when forking is used. For 640 example, if using a Diffie-Hellman keying technique with security 641 preconditions that forks to 20 endpoints, the call initiator would 642 get 20 provisional responses containing 20 signed Diffie-Hellman half 643 keys. Calculating 20 DH secrets and validating signatures can be a 644 difficult task depending on the device capabilities. 646 The following list compares the behavior of clipping before SDP 647 answer for each keying mechanism. 649 MIKEY-NULL 650 Not clipped. The offerer provides the answerer's keys. 652 MIKEY-PSK 653 Not clipped. The offerer provides the answerer's keys. 655 MIKEY-RSA 656 Not clipped. The offerer provides the answerer's keys. 658 MIKEY-RSA-R 659 Clipped. The answer contains the answerer's encryption key. 661 MIKEY-DHSIGN 662 Clipped. The answer contains the answerer's Diffie-Hellman 663 response. 665 MIKEY-DHHMAC 666 Clipped. The answer contains the answerer's Diffie-Hellman 667 response. 669 Security Descriptions 670 Clipped. The answer contains the answerer's encryption key. 672 SDP-DH 673 Clipped. The answer contains the answerer's Diffie-Hellman 674 response. 676 ZRTP 677 Not clipped because the session intially uses RTP. While RTP 678 is flowing, both ends negotiate SRTP keys in the media path and 679 then switch to using SRTP. 681 EKT 682 Not clipped. The answerer sends its encryption key in RTCP, 683 which arrives at the same time (or before) the first SRTP 684 packet encrypted with that key. 685 Note: RTCP needs to work, in the answerer-to-offerer 686 direction, before the offerer can decrypt SRTP media. 688 RTP-DTLS 689 Not clipped. Media keys are exchanged in the media path 690 without relying on the signaling path. 692 DTLS-SRTP 693 Not clipped. Keys are exchanged in the media path without 694 relying on the signaling path. 696 4.3. Centralized Keying 698 For efficient scaling, large audio and video conference bridges 699 operate most efficiently by encrypting the current speaker once and 700 distributing that stream to the conference attendees. Typically, 701 inactive participants receive the same streams -- they hear (or see) 702 the active speaker(s), and the active speakers receive distinct 703 streams that don't include themselves. In order to maintain 704 confidentiality of such conferences where listeners share a common 705 key, all listeners must rekeyed when a listener joins or leaves a 706 conference. 708 An important use case for mixers/translators is a conference bridge: 710 +----+ 711 A --- 1 --->| | 712 <-- 2 ----| M | 713 | I | 714 B --- 3 --->| X | 715 <-- 4 ----| E | 716 | R | 717 C --- 5 --->| | 718 <-- 6 ----| | 719 +----+ 721 Figure 4: Centralized Keying 723 In the figure above, 1, 3, and 5 are RTP media contributions from 724 Alice, Bob, and Carol, and 2, 4, and 6 are the RTP flows to those 725 devices carrying the 'mixed' media. 727 Several scenarios are possible: 729 a. Multiple inbound sessions: 1, 3, and 5 are distinct RTP 730 sessions, 731 b. Multiple outbound sessions: 2, 4, and 6 are distinct RTP 732 sessions, 733 c. Single inbound session: 1, 3, and 5 are just different sources 734 within the same RTP session, 735 d. Single outbound session: 2, 4, and 6 are different flows of the 736 same (multi-unicast) RTP session 738 If there are multiple inbound sessions and multiple outbound sessions 739 (scenarios a and b), then every keying mechanism behaves as if the 740 mixer were an endpoint and can set up a point-to-point secure session 741 between the participant and the mixer. This is the simplest 742 situation, but is computationally wasteful, since SRTP processing has 743 to be done independently for each participant. The use of multiple 744 inbound sessions (scenario a) doesn't waste computational resources, 745 though it does consume additional cryptographic context on the mixer 746 for each participant and has the advantage of non-repudiation of the 747 originator of the incoming stream. 749 To support a single outbound session (scenario d), the mixer has to 750 dictate its encryption key to the participants. Some keying 751 mechanisms allow the transmitter to determine its own key, and others 752 allow the offerer to determine the key for the offerer and answerer. 753 Depending on how the call is established, the offerer might be a 754 participant (such as a participant dialing into a conference bridge) 755 or the offerer might be the mixer (such as a conference bridge 756 calling a participant). 757 The use of offerless Invites may help some keying mechanisms 758 reverse the role of offerer/answerer. A difficulty, however, is 759 knowing a priori if the role should be reversed for a particular 760 call. 762 The following list describes how each keying mechanism behaves with 763 centralized keying (scenario d) and rekeying. 765 MIKEY-NULL 766 Keying: Yes, if offerer is the mixer. No, if offerer is the 767 participant (end user). 769 Rekeying: Yes, via re-Invite 771 MIKEY-PSK 772 Keying: Yes, if offerer is the mixer. No, if offerer is the 773 participant (end user). 775 Rekeying: Yes, with a re-Invite 777 MIKEY-RSA 778 Keying: Yes, if offerer is the mixer. No, if offerer is the 779 participant (end user). 781 Rekeying: Yes, with a re-Invite 783 MIKEY-RSA-R 784 Keying: No, if offerer is the mixer. Yes, if offerer is the 785 participant (end user). 787 Rekeying: n/a 789 MIKEY-DHSIGN 790 Keying: No; a group-key Diffie-Hellman protocol is not 791 supported. 793 Rekeying: n/a 795 MIKEY-DHHMAC 796 Keying: No; a group-key Diffie-Hellman protocol is not 797 supported. 799 Rekeying: n/a 801 Security Descriptions 802 Keying: Yes, if offerer is the mixer. Yes, if offerer is the 803 participant. 805 Rekeying: Yes, with a Re-Invite 807 SDP-DH 808 Keying: No; a group-key Diffie-Hellman protocol is not 809 supported. 811 Rekeying: n/a 813 ZRTP 814 Keying: No; a group-key Diffie-Hellman protocol is not 815 supported. 817 Rekeying: n/a 819 EKT 820 Keying: Yes. After bootstrapping a KEK using SDES or MIKEY, 821 each member originating an SRTP stream can send its SRTP master 822 key, sequence number and ROC via RTCP. 824 Rekeying: Yes. EKT supports each sender to transmit its SRTP 825 master key to the group via RTCP packets. Thus, EKT supports 826 each originator of an SRTP stream to rekey at any time. 828 RTP-DTLS 829 Keying: Yes, because with the assumed cipher suite, 830 TLS_RSA_WITH_3DES_EDE_CBC_SHA, each end indicates its SRTP key. 832 Rekeying: via DTLS in the media path. 834 DTLS-SRTP 835 Keying: Yes, because with the assumed cipher suite, 836 TLS_RSA_WITH_3DES_EDE_CBC_SHA, each end indicates its SRTP key. 838 Rekeying: via DTLS in the media path. 840 4.4. SSRC and ROC 842 In SRTP, a cryptographic context is defined as the SSRC, destination 843 network address, and destination transport port number. Whereas RTP, 844 a flow is defined as the destination network address and destination 845 transport port number. This results in a problem -- how to 846 communicate the SSRC so that the SSRC can be used for the 847 cryptographic context. 849 Two approaches have emerged for this communication. One, used by all 850 MIKEY modes, is to communicate the SSRCs to the peer in the MIKEY 851 exchange. Another, used by Security Descriptions, is to use "late 852 bindng" -- that is, any new packet containing a previously-unseen 853 SSRC (which arrives at the same destination network address and 854 destination transport port number) will create a new cryptographic 855 context. Another approach, common amongst techniques with media-path 856 SRTP key establishment, is to require a handshake over that media 857 path before SRTP packets are sent. MIKEY's approach changes RTP's 858 SSRC collision detection behavior by requiring RTP to pre-establish 859 the SSRC values for each session. 861 Another related issue is that SRTP introduces a rollover counter 862 (ROC), which records how many times the SRTP sequence number has 863 rolled over. As the sequence number is used for SRTP's default 864 ciphers, it is important that all endpoints know the value of the 865 ROC. The ROC starts at 0 at the beginning of a session. 867 Some keying mechanisms cause a two-time pad to occur if two endpoints 868 of a forked call have an SSRC collision. 870 Note: A proposal has been made to send the ROC value on every Nth 871 SRTP packet[I-D.lehtovirta-srtp-rcc]. This proposal has not yet been 872 incorporated into this document. 874 The following list examines handling of SSRC and ROC: 876 MIKEY-NULL 877 Each endpoint indicates a set of SSRCs and the ROC for SRTP 878 packets it transmits. 880 MIKEY-PSK 881 Each endpoint indicates a set of SSRCs and the ROC for SRTP 882 packets it transmits. 884 MIKEY-RSA 885 Each endpoint indicates a set of SSRCs and the ROC for SRTP 886 packets it transmits. 888 MIKEY-RSA-R 889 Each endpoint indicates a set of SSRCs and the ROC for SRTP 890 packets it transmits. 892 MIKEY-DHSIGN 893 Each endpoint indicates a set of SSRCs and the ROC for SRTP 894 packets it transmits. 896 MIKEY-DHHMAC 897 Each endpoint indicates a set of SSRCs and the ROC for SRTP 898 packets it transmits. 900 Security Descriptions 901 Neither SSRC nor ROC are signaled. SSRC 'late binding' is 902 used. 904 SDP-DH 905 Neither SSRC nor ROC are signaled. SSRC 'late binding' is 906 used. 908 ZRTP 909 Neither SSRC nor ROC are signaled. SSRC 'late binding' is 910 used. 912 EKT 913 The SSRC of the SRTCP packet containing an EKT update 914 corresponds to the SRTP master key and other parameters within 915 that packet. 917 RTP-DTLS 918 Neither SSRC nor ROC are signaled. SSRC 'late binding' is 919 used. 921 DTLS-SRTP 922 Neither SSRC nor ROC are signaled. SSRC 'late binding' is 923 used. 925 5. Evaluation Criteria - Security 927 This section evaluates each keying mechanism on the basis of their 928 security properties. 930 5.1. Public Key Infrastructure 932 There are two aspects of PKI requirements -- one aspect is if PKI is 933 necessary in order for the mechanism to function at all, the other is 934 if PKI is used to authenticate a certificate. With interactive 935 communications it is desirable to avoid fetching certificates that 936 delay call setup; rather it is preferable to fetch or validate 937 certificates in such a way that call setup isn't delayed. For 938 example, a certificate can be validated while the phone is ringing or 939 can be validated while ring-back tones are being played or even while 940 the called party is answering the phone and saying "hello". 942 SRTP key exchange mechanisms that require a global PKI to operate are 943 gated on the deployment of a common PKI available to both endpoints. 944 This means that no media security is achievable until such a PKI 945 exists. For SIP, something like sipping-certs [I-D.ietf-sipping- 946 certs] might be used to obtain the certificate of a peer. 948 Note: Even if Sipping-certs was deployed, the retargeting problem 949 (Section 4.1) would still prevent successful deployment of keying 950 techniques which require the offerer to obtain the actual target's 951 public key. 953 The following list compares the PKI requirements of each keying 954 mechanism, both if a PKI is required for the key exchange itself, and 955 if PKI is only used to authenticate the certificate supplied in 956 signaling. 958 MIKEY-NULL 959 PKI not used. 961 MIKEY-PSK 962 PKI not used; rather, all endpoints must have some way to 963 exchange per-endpoint or per-system pre-shared keys. 965 MIKEY-RSA 966 The offerer obtains the intended answerer's public key before 967 initiating the call. This public key is used to encrypt the 968 SRTP keys. There is no defined mechanism for the offerer to 969 obtain the answerer's public key, although [I-D.ietf-sipping- 970 certs] might be viable in the future. 972 MIKEY-RSA-R 973 The offer contains the offerer's public key. The answerer uses 974 that public key to encrypt the SRTP keys that will be used by 975 the offerer and the answerer. A PKI is necessary to validate 976 the certificates. 978 MIKEY-DHSIGN 979 PKI is used to authenticate the public key that is included in 980 the MIKEY message, by walking the CA trust chain. 982 MIKEY-DHHMAC 983 PKI not used; rather, all endpoints must have some way to 984 exchange per-endpoint or per-system pre-shared keys. 986 Security Descriptions 987 PKI not used. 989 SDP-DH 990 PKI not used. 992 ZRTP 993 PKI not used. 995 EKT 996 PKI not used. 998 RTP-DTLS 999 Remote party's certificate is sent in media path, and a 1000 fingerprint of the same certificate is sent in the signaling 1001 path. PKI is used to authenticate the remote party's 1002 certificate, by walking the CA trust chain. 1004 DTLS-SRTP 1005 Remote party's certificate is sent in media path, and a 1006 fingerprint of the same certificate is sent in the signaling 1007 path. PKI is used to authenticate the remote party's 1008 certificate, by walking the CA trust chain.. 1010 5.2. Perfect Forward Secrecy 1012 In the context of SRTP, Perfect Forward Secrecy is the property that 1013 SRTP session keys that protected a previous session are not 1014 compromised if the static keys belonging to the endpoints are 1015 compromised. That is, if someone were to record your encrypted 1016 session content and later acquires either party's private key, that 1017 encrypted session content would be safe from decryption if your key 1018 exchange mechanism had perfect forward secrecy. 1020 The following list describes how each key exchange mechanism provides 1021 PFS. 1023 MIKEY-NULL 1024 No PFS. 1026 MIKEY-PSK 1027 No PFS. 1029 MIKEY-RSA 1030 No PFS. 1032 MIKEY-RSA-R 1033 No PFS. 1035 MIKEY-DHSIGN 1036 PFS is provided with the Diffie-Hellman exchange. 1038 MIKEY-DHHMAC 1039 PFS is provided with the Diffie-Hellman exchange. 1041 Security Descriptions 1042 No PFS. 1044 SDP-DH 1045 PFS is provided with the Diffie-Hellman exchange. 1047 ZRTP 1048 PFS is provided with the Diffie-Hellman exchange. 1050 EKT 1051 No PFS. 1053 RTP-DTLS 1054 PFS is achieved if the negotiated cipher suite includes an 1055 exponential or discrete-logarithmic key exchange (such as 1056 Diffie-Hellman or Elliptic Curve Diffie-Hellman [I-D.ietf-tls- 1057 ecc]). 1059 DTLS-SRTP 1060 PFS is achieved if the negotiated cipher suite includes an 1061 exponential or discrete-logarithmic key exchange (such as 1062 Diffie-Hellman or Elliptic Curve Diffie-Hellman [I-D.ietf-tls- 1063 ecc]). 1065 5.3. Opportunistic Encryption 1067 With opportunistic encryption, SRTP is used if possible but otherwise 1068 RTP is used. 1070 SIP needs a backwards-compatible opportunistic encryption in order 1071 for SRTP to work successfully with SIP retargeting and forking. 1073 Consider the case of Bob, with a phone that only does RTP and a 1074 voice mail system that supports SRTP and RTP. If Alice calls Bob 1075 with an SRTP offer, Bob's RTP-only phone will reject the media 1076 stream (with an empty "m=" line) because Bob's phone doesn't 1077 understand SRTP (RTP/SAVP). Alice's phone will see this rejected 1078 media stream and may terminate the entire call (BYE) and re- 1079 initiate the call as RTP-only, or Alice's phone may decide to 1080 continue with call setup with the SRTP-capable leg (the voice mail 1081 system). If Alice's phone decided to re-initiate the call as RTP- 1082 only, and Bob doesn't answer his phone, Alice will then leave 1083 voice mail using only RTP, rather than SRTP as expected. 1084 Currently, several techniques are commonly considered as candidates 1085 to provide opportunistic encryption: 1087 multipart/alternative 1088 [I-D.jennings-sipping-multipart] describes how to form a 1089 multipart/alternative body part in SIP. The significant issues 1090 with this technique are (1) that multipart MIME is incompatible 1091 with existing SIP proxies, firewalls, Session Border Controllers, 1092 and endpoints and (2) when forking, the Heterogeneous Error 1093 Response Forking Problem (HERFP) [I-D.mahy-sipping-herfp-fix] 1094 causes problems if such non-multipart-capable endpoints were 1095 involved in the forking. Retargeting which involves a non- 1096 multipart-capable device also causes retargeting to prematurely 1097 stop. 1099 SDP Grouping 1100 A new SDP grouping mechanism (following the idea introduced in 1101 [RFC3388]) has been discussed which would allow a media line to 1102 indicate RTP/AVP and another media line to indicate RTP/SAVP, 1103 allowing non-SRTP-aware endpoints to choose RTP/AVP and SRTP-aware 1104 endpoints to choose RTP/SAVP. As of this writing, this SDP 1105 grouping mechanism has not been published as an Internet Draft. 1107 session attribute With this technique, the endpoints signal their 1108 desire to do SRTP by signaling RTP (RTP/AVP), and using an 1109 attribute ("a=") in the SDP. This technique is entirely backwards 1110 compatible with non-SRTP-aware endpoints, but doesn't use the RTP/ 1111 SAVP protocol registered by SRTP [RFC3711]. 1112 Probing With this technique, the endpoints first establish an RTP 1113 session using RTP (RTP/AVP). The endpoints send probe messages, 1114 over the media path, to determine if the remote endpoint supports 1115 their keying technique. 1117 The following list compares the availability of opportunistic 1118 encryption for each keying mechanism. 1120 MIKEY-NULL 1121 No opportunistic encryption. 1123 MIKEY-PSK 1124 No opportunistic encryption. 1126 MIKEY-RSA 1127 No opportunistic encryption. 1129 MIKEY-RSA-R 1130 No opportunistic encryption. 1132 MIKEY-DHSIGN 1133 No opportunistic encryption. 1135 MIKEY-DHHMAC 1136 No opportunistic encryption. 1138 Security Descriptions 1139 No opportunistic encryption. 1141 SDP-DH 1142 No opportunistic encryption. 1144 ZRTP 1145 Opportunistic encryption is done by probing (sending RTP 1146 messages with header extensions) or by session attribute (see 1147 "a=zrtp", defined in section 10 of [I-D.zimmermann-avt-zrtp]). 1148 Current implementations of ZRTP use probing. 1150 EKT 1151 No opportunistic encryption. 1153 RTP-DTLS 1154 No opportunistic encryption. 1156 DTLS-SRTP 1157 No opportunistic encryption. 1159 6. Security Considerations 1161 This entire document discusses security. 1163 7. Acknowledgements 1165 Special thanks to Steffen Fries and Dragan Ignjatic for their 1166 excellent MIKEY comparison document [I-D.ietf-msec-mikey- 1167 applicability]. 1169 Thanks also to Cullen Jennings, David Oran, David McGrew, Mark 1170 Baugher, Flemming Andreasen, Eric Raymond, Dave Ward, Leo Huang, Eric 1171 Rescorla, Lakshminath Dondeti, Steffen Fries, Alan Johnston, and 1172 Dragon Ignjatic for their assistance with this document. 1174 8. IANA Considerations 1176 This document does not add new IANA registrations. 1178 9. References 1180 9.1. Normative References 1182 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1183 A., Peterson, J., Sparks, R., Handley, M., and E. 1184 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1185 June 2002. 1187 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1188 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1189 RFC 3711, March 2004. 1191 [I-D.ietf-sip-identity] 1192 Peterson, J. and C. Jennings, "Enhancements for 1193 Authenticated Identity Management in the Session 1194 Initiation Protocol (SIP)", draft-ietf-sip-identity-06 1195 (work in progress), October 2005. 1197 9.2. Informational References 1199 [I-D.ietf-mmusic-sdescriptions] 1200 Andreasen, F., "Session Description Protocol Security 1201 Descriptions for Media Streams", 1202 draft-ietf-mmusic-sdescriptions-12 (work in progress), 1203 September 2005. 1205 [I-D.ietf-mmusic-kmgmt-ext] 1206 Arkko, J., "Key Management Extensions for Session 1207 Description Protocol (SDP) and Real Time Streaming 1208 Protocol (RTSP)", draft-ietf-mmusic-kmgmt-ext-15 (work in 1209 progress), June 2005. 1211 [I-D.ietf-mmusic-securityprecondition] 1212 Andreasen, F. and D. Wing, "Security Preconditions for 1213 Session Description Protocol Media Streams", 1214 draft-ietf-mmusic-securityprecondition-01 (work in 1215 progress), October 2005. 1217 [I-D.ietf-msec-mikey-dhhmac] 1218 Euchner, M., "HMAC-authenticated Diffie-Hellman for 1219 MIKEY", draft-ietf-msec-mikey-dhhmac-11 (work in 1220 progress), April 2005. 1222 [I-D.ietf-msec-mikey-ecc] 1223 Milne, A., "ECC Algorithms For MIKEY", 1224 draft-ietf-msec-mikey-ecc-00 (work in progress), 1225 February 2006. 1227 [I-D.ietf-msec-mikey-rsa-r] 1228 Ignjatic, D., "An additional mode of key distribution in 1229 MIKEY: MIKEY-RSA-R", draft-ietf-msec-mikey-rsa-r-04 (work 1230 in progress), April 2006. 1232 [I-D.ietf-sipping-certs] 1233 Jennings, C. and J. Peterson, "Certificate Management 1234 Service for The Session Initiation Protocol (SIP)", 1235 draft-ietf-sipping-certs-03 (work in progress), 1236 March 2006. 1238 [I-D.mahy-sipping-herfp-fix] 1239 Mahy, R., "A Solution to the Heterogeneous Error Response 1240 Forking Problem (HERFP) in the Session Initiation 1241 Protocol (SIP)", draft-mahy-sipping-herfp-fix-01 (work in 1242 progress), March 2006. 1244 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1245 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1246 August 2004. 1248 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1249 Provisional Responses in Session Initiation Protocol 1250 (SIP)", RFC 3262, June 2002. 1252 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 1253 Schulzrinne, "Grouping of Media Lines in the Session 1254 Description Protocol (SDP)", RFC 3388, December 2002. 1256 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1257 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1259 [I-D.fischl-sipping-media-dtls] 1260 Fischl, J., "Session Initiation Protocol (SIP) for Media 1261 Over Datagram Transport Layer Security (DTLS)", 1262 draft-fischl-sipping-media-dtls-00 (work in progress), 1263 March 2006. 1265 [I-D.fischl-mmusic-sdp-dtls] 1266 Fischl, J. and H. Tschofenig, "Session Description 1267 Protocol (SDP) Indicators for Datagram Transport Layer 1268 Security (DTLS)", draft-fischl-mmusic-sdp-dtls-00 (work in 1269 progress), March 2006. 1271 [I-D.ietf-msec-mikey-applicability] 1272 Fries, S. and D. Ignjatic, "On the applicability of 1273 various MIKEY modes and extensions", 1274 draft-ietf-msec-mikey-applicability-00 (work in progress), 1275 May 2006. 1277 [I-D.zimmermann-avt-zrtp] 1278 Zimmermann, P., "ZRTP: Extensions to RTP for Diffie- 1279 Hellman Key Agreement for SRTP", 1280 draft-zimmermann-avt-zrtp-01 (work in progress), 1281 March 2006. 1283 [I-D.baugher-mmusic-sdp-dh] 1284 Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for 1285 Multimedia Sessions", draft-baugher-mmusic-sdp-dh-00 (work 1286 in progress), February 2006. 1288 [I-D.mcgrew-srtp-ekt] 1289 McGrew, D., "Encrypted Key Transport for Secure RTP", 1290 draft-mcgrew-srtp-ekt-00 (work in progress), 1291 February 2006. 1293 [I-D.lehtovirta-srtp-rcc] 1294 Lehtovirta, V., "Integrity Transform Carrying Roll-over 1295 Counter", draft-lehtovirta-srtp-rcc-01 (work in progress), 1296 February 2006. 1298 [I-D.ietf-tls-ecc] 1299 Gupta, V., "ECC Cipher Suites for TLS", 1300 draft-ietf-tls-ecc-12 (work in progress), October 2005. 1302 [I-D.peterson-sipping-retarget] 1303 Peterson, J., "Retargeting and Security in SIP: A 1304 Framework and Requirements", 1305 draft-peterson-sipping-retarget-00 (work in progress), 1306 February 2005. 1308 [I-D.ietf-mmusic-ice] 1309 Rosenberg, J., "Interactive Connectivity Establishment 1310 (ICE): A Methodology for Network Address Translator (NAT) 1311 Traversal for Offer/Answer Protocols", 1312 draft-ietf-mmusic-ice-08 (work in progress), March 2006. 1314 [I-D.ietf-sip-connected-identity] 1315 Elwell, J., "Connected Identity in the Session Initiation 1316 Protocol (SIP)", draft-ietf-sip-connected-identity-00 1317 (work in progress), April 2006. 1319 [I-D.jennings-sipping-multipart] 1320 Wing, D. and C. Jennings, "Session Initiation Protocol 1321 (SIP) Offer/Answer with Multipart Alternative", 1322 draft-jennings-sipping-multipart-02 (work in progress), 1323 March 2006. 1325 [I-D.draft-mcgrew-dtls-srtp] 1326 McGrew, D. and E. Rescorla, "Datagram Transport Layer 1327 Security (DTLS) Extension to Establish Keys for Secure 1328 Real-time Transport Protocol (SRTP)", 1329 draft-mcgrew-tls-srtp-00 (work in progress), March 2006, < 1330 http://scm.sipfoundry.org/rep/ietf-drafts/ekr/ 1331 draft-mcgrew-dtls-srtp.txt>. 1333 Authors' Addresses 1335 Francois Audet 1336 Nortel 1337 4655 Great America Parkway 1338 Santa Clara, CA 95054 1339 USA 1341 Email: audet@nortel.com 1343 Dan Wing 1344 Cisco Systems 1345 170 West Tasman Drive 1346 San Jose, CA 95134 1347 USA 1349 Email: dwing@cisco.com 1351 Intellectual Property Statement 1353 The IETF takes no position regarding the validity or scope of any 1354 Intellectual Property Rights or other rights that might be claimed to 1355 pertain to the implementation or use of the technology described in 1356 this document or the extent to which any license under such rights 1357 might or might not be available; nor does it represent that it has 1358 made any independent effort to identify any such rights. Information 1359 on the procedures with respect to rights in RFC documents can be 1360 found in BCP 78 and BCP 79. 1362 Copies of IPR disclosures made to the IETF Secretariat and any 1363 assurances of licenses to be made available, or the result of an 1364 attempt made to obtain a general license or permission for the use of 1365 such proprietary rights by implementers or users of this 1366 specification can be obtained from the IETF on-line IPR repository at 1367 http://www.ietf.org/ipr. 1369 The IETF invites any interested party to bring to its attention any 1370 copyrights, patents or patent applications, or other proprietary 1371 rights that may cover technology that may be required to implement 1372 this standard. Please address the information to the IETF at 1373 ietf-ipr@ietf.org. 1375 Disclaimer of Validity 1377 This document and the information contained herein are provided on an 1378 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1379 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1380 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1381 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1382 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1383 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1385 Copyright Statement 1387 Copyright (C) The Internet Society (2006). This document is subject 1388 to the rights, licenses and restrictions contained in BCP 78, and 1389 except as set forth therein, the authors retain all their rights. 1391 Acknowledgment 1393 Funding for the RFC Editor function is currently provided by the 1394 Internet Society.