idnits 2.17.1 draft-ietf-sip-media-security-requirements-01.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1938. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1949. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1956. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1962. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 900 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 (November 18, 2007) is 6002 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-avt-dtls-srtp-01 == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-sdp-capability-negotiation-07 == Outdated reference: A later version (-09) exists of draft-ietf-msec-mikey-applicability-06 == Outdated reference: A later version (-15) exists of draft-ietf-sip-certs-04 == Outdated reference: A later version (-06) exists of draft-mcgrew-srtp-ekt-03 == Outdated reference: A later version (-04) exists of draft-wing-sipping-srtp-key-02 == Outdated reference: A later version (-22) exists of draft-zimmermann-avt-zrtp-04 -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 3388 (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP D. Wing, Ed. 3 Internet-Draft Cisco 4 Intended status: Informational S. Fries 5 Expires: May 21, 2008 Siemens AG 6 H. Tschofenig 7 Nokia Siemens Networks 8 F. Audet 9 Nortel 10 November 18, 2007 12 Requirements and Analysis of Media Security Management Protocols 13 draft-ietf-sip-media-security-requirements-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 21, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This documents describes requirements for a protocol to negotiate 47 security context for SIP-signaled SRTP media. In addition to the 48 natural security requirements, this negotiation protocol must 49 interoperate well with SIP in certain ways. A number of proposals 50 have been published and a summary of these proposals is in the 51 appendix of this document. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Document Organization . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Call Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. Clipping Media Before Signaling Answer . . . . . . . . . . 7 61 4.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 8 62 4.3. Shared Key Conferencing . . . . . . . . . . . . . . . . . 11 63 4.4. Recording . . . . . . . . . . . . . . . . . . . . . . . . 13 64 4.5. PSTN gateway . . . . . . . . . . . . . . . . . . . . . . . 13 65 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 5.1. Key Management Protocol Requirements . . . . . . . . . . . 14 67 5.2. Attack Scenario Requirements . . . . . . . . . . . . . . . 16 68 5.3. Requirements Outside of the Key Management Protocol . . . 18 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 75 Appendix A. Overview of Keying Mechanisms . . . . . . . . . . . . 22 76 A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 23 77 A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 23 78 A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 23 79 A.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 24 80 A.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 24 81 A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 24 82 A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 24 83 A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 25 84 A.1.8. Security Descriptions with SIPS . . . . . . . . . . . 25 85 A.1.9. Security Descriptions with S/MIME . . . . . . . . . . 25 86 A.1.10. SDP-DH (expired) . . . . . . . . . . . . . . . . . . . 25 87 A.1.11. MIKEYv2 in SDP (expired) . . . . . . . . . . . . . . . 25 88 A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 26 89 A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 26 90 A.3. Signaling and Media Path Keying Techniques . . . . . . . . 26 91 A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 26 92 A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 27 93 A.3.3. MIKEYv2 Inband (expired) . . . . . . . . . . . . . . . 27 94 Appendix B. Evaluation Criteria - SIP . . . . . . . . . . . . . . 27 95 B.1. Secure Retargeting and Secure Forking . . . . . . . . . . 27 96 B.2. Clipping Media Before SDP Answer . . . . . . . . . . . . . 30 97 B.3. Centralized Keying . . . . . . . . . . . . . . . . . . . . 31 98 B.4. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . . . 33 99 Appendix C. Evaluation Criteria - Security . . . . . . . . . . . 35 100 C.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 35 101 C.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 37 102 C.3. Best Effort Encryption . . . . . . . . . . . . . . . . . . 39 103 C.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . . . 40 104 Appendix D. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 42 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 106 Intellectual Property and Copyright Statements . . . . . . . . . . 44 108 1. Introduction 110 The work on media security started when the Session Initiation 111 Protocol (SIP) was still in its infancy. With the increased SIP 112 deployment and the availability of new SIP extensions and related 113 protocols, the need for end-to-end security was re-evaluated. The 114 procedure of re-evaluating prior protocol work and design decisions 115 is not an uncommon strategy and, to some extent, considered necessary 116 protocol work to ensure that the developed protocols indeed meet the 117 previously envisioned needs for the users in the Internet. 119 This document summarizes media security requirements, i.e., 120 requirements for mechanisms that negotiate security context such as 121 cryptographic keys and parameters for SRTP. 123 1.1. Document Organization 125 The organization of this document is as follows: Section 2 introduces 126 terminology, Section 3 describes various attack scenarios against the 127 signaling path and media path, Section 4 provides an overview about 128 possible call scenarios, Section 5 lists requirements for media 129 security. The main part of the document concludes with the security 130 considerations Section 6, IANA considerations Section 7 and an 131 acknowledgement section in Section 8. Appendix A lists and compares 132 available solution proposals. The following Appendix B compares the 133 different approaches regarding their suitability for the SIP 134 signaling scenarios described in Appendix A, while Appendix C 135 provides a comparison regarding security aspects. Appendix D lists 136 non-goals for this document. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119], with the 143 important qualification that, unless otherwise stated, these terms 144 apply to the design of the media security key management protocol, 145 not its implementation or application. 147 Additionally, the following items are used in this document: 149 AOR (Address-of-Record): A SIP or SIPS URI that points to a domain 150 with a location service that can map the URI to another URI where 151 the user might be available. Typically, the location service is 152 populated through registrations. An AOR is frequently thought of 153 as the "public address" of the user. 155 SSRC: The 32-bit value that defines the synchronization source, used 156 in RTP. These are generally unique, but collisions can occur. 158 two-time pad: The use of the same key and the same key index to 159 encrypt different data. For SRTP, a two-time pad occurs if two 160 senders are using the same key and the same RTP SSRC value. 162 PKI: Public Key Infrastructure (see [RFC3280]) 164 Perfect Forward Secrecy (PFS): The property that disclosure of the 165 long-term secret keying material that is used to derive an agreed 166 ephemeral key does not compromise the secrecy of agreed keys from 167 earlier runs. 169 active adversary: An active adversary attempts to alter system 170 resources or affect their operation (see [RFC4949]). 172 passive adversary: A passive adversary attempts to learn or make use 173 of information from a system but does not affect resources of that 174 system (see [RFC4949]). 176 signaling path: The signaling path is the route taken by SIP 177 signaling messages transmitted between the calling and called user 178 agents. This can be either direct signaling between the calling 179 and called user agents or, more commonly involves the SIP proxy 180 servers that were involved in the call setup. 182 media path: The media path is the route taken by media packets 183 exchanged by the endpoints. In the simplest case, the endpoints 184 exchange media directly, and the "media path" is defined by a 185 quartet of IP addresses and TCP/UDP ports, along with an IP route. 186 In other cases, this path may include RTP relays, mixers, 187 transcoders, session border controllers, NATs, or media gateways. 189 3. Attack Scenarios 191 The discussion in this section refers to requirements R6, R7, R14, 192 R17, and R27. 194 This document classifies adversaries according to their access and 195 their capabilities. An adversary might have access to: 197 1. only the media path, 199 2. only the signaling path, 200 3. both the media path and the signaling path. 202 An attacker that can solely be located along the signaling path, and 203 does not have access to media (item 2), is not considered in this 204 document. 206 There are two different types of adversaries, active and passive. An 207 active adversary may need to be active with regard to the key 208 exchange relevant information traveling along the media path or 209 traveling along the signaling path. 211 Based on their robustness against the adversary capabilities 212 described above, we can group security mechanisms using the following 213 labels, ordered from least secure at the top to most secure at the 214 bottom: 216 no-signaling-passive-media: 217 Access to only the media path is sufficient to reveal the content 218 of the media traffic. This is how unencrypted RTP functions. 220 passive-signaling-passive-media: 221 Passive attack on the signaling and passive attack on the media 222 path is necessary to reveal the content of the media traffic. 224 active-signaling-passive-media: 225 Active attack on the signaling path and passive attack on the 226 media path is necessary to reveal the content of the media 227 traffic. 229 active-signaling-active-media: 230 Active attack on both the signaling path and the media path is 231 necessary to reveal the content of the media traffic. 233 detect-attack: 234 Active attack on both signaling and media path is necessary to 235 reveal the content of the media traffic (active-signaling-active- 236 media), but the attack is detectable by the end points when 237 adversary tampers with the signaling and/or media messages. 239 For example, Security Descriptions [RFC4568], when protected by TLS 240 (as it is commonly implemented and deployed), belongs in the passive- 241 signaling-passive-media category since the adversary needs to learn 242 the Security Descriptions key by seeing the SIP signaling message at 243 a SIP proxy (assuming that the adversary is in control of the SIP 244 proxy). The media traffic can be decrypted using that learned key. 246 As another example, DTLS-SRTP falls into active-signaling-active- 247 media category when DTLS-SRTP is used with a public key based 248 ciphersuite with self-signed certificates and without SIP-Identity 249 [RFC4474]. An adversary would have to modify the fingerprint that is 250 sent along the signaling path and subsequently to modify the 251 certificates carried in the DTLS handshake that travel along the 252 media path. If DTLS-SRTP is used with SIP-Identity [RFC4474] and 253 protects both the offer and the answer, it would belong to the 254 detect-attack category. 256 The above discussion of DTLS-SRTP demonstrates how a single security 257 protocol can be in different classes depending on the mode in which 258 it is operated. Other protocols can achieve similar effect by adding 259 functions outside of the on-the-wire key management protocol itself. 260 Although it may be appropriate to deploy lower-classed mechanisms in 261 some cases, the ultimate security requirement for a media security 262 negotiation protocol is that it have a mode of operation available in 263 which it is detect-attack, which provides protection against the 264 passive and active attacks and provides detection of such attacks. 265 That is, there must be a way to use the protocol so that an active 266 attack is required against both the signaling and media paths, and so 267 that such attacks are detectable by the endpoints. 269 4. Call Scenarios 271 The following subsections describe call scenarios that pose the most 272 challenge to the key management system for media data in cooperation 273 with SIP signaling. 275 4.1. Clipping Media Before Signaling Answer 277 The discussion in this section refers to requirement R5. 279 Per the SDP Offer/Answer Model [RFC3264], 281 "Once the offerer has sent the offer, it MUST be prepared to 282 receive media for any recvonly streams described by that offer. 283 It MUST be prepared to send and receive media for any sendrecv 284 streams in the offer, and send media for any sendonly streams in 285 the offer (of course, it cannot actually send until the peer 286 provides an answer with the needed address and port information)." 288 To meet this requirement with SRTP, the offerer needs to know the 289 SRTP key for arriving media. If either endpoint receives encrypted 290 media before it has access to the associated SRTP key, it cannot play 291 the media -- causing clipping. 293 For key exchange mechanisms that send the answerer's key in SDP, a 294 SIP provisional response [RFC3261], such as 183 (session progress), 295 is useful. However, the 183 messages are not reliable unless both 296 the calling and called end point support PRACK [RFC3262], use TCP 297 across all SIP proxies, implement Security Preconditions [RFC5027], 298 or the both ends implement ICE [I-D.ietf-mmusic-ice] and the answerer 299 implements the reliable provisional response mechanism described in 300 ICE. Unfortunately, there is not wide deployment of any of these 301 techniques and there is industry reluctance to set requirements 302 regarding these techniques to avoid the problem described in this 303 section. 305 Note that the receipt of an SDP answer is not always sufficient to 306 allow media to be played to the offerer. Sometimes, the offerer must 307 send media in order to open up firewall holes or NAT bindings before 308 media can be received. In this case, even a solution that makes the 309 key available before the SDP answer arrives will not help. 311 Fixes to early media might make the requirements to become obsolete, 312 but at the time of writing no progress has been accomplished. 314 4.2. Retargeting and Forking 316 The discussion in this section relates to requirements R1, R2, and 317 R3. 319 In SIP, a request sent to a specific AOR but delivered to a different 320 AOR is called a "retarget". A typical scenario is a "call 321 forwarding" feature. In Figure 1 Alice sends an Invite in step 1 322 that is sent to Bob in step 2. Bob responds with a redirect (SIP 323 response code 3xx) pointing to Carol in step 3. This redirect 324 typically does not propagate back to Alice but only goes to a proxy 325 (i.e., the retargeting proxy) that sends the original Invite to Carol 326 in step 4. 328 +-----+ 329 |Alice| 330 +--+--+ 331 | 332 | Invite (1) 333 V 334 +----+----+ 335 | proxy | 336 ++-+-----++ 337 | ^ | 338 Invite (2) | | | Invite (4) 339 & redirect (3) | | | 340 V | V 341 ++-++ ++----+ 342 |Bob| |Carol| 343 +---+ +-----+ 345 Figure 1: Retargeting 347 Using retargeting might lead to situations where the UAC does not 348 know where its request will be going. This might not immediately 349 seem like a serious problem; after all, when one places a telephone 350 call on the PSTN, one never really knows if it will be forwarded to a 351 different number, who will pick up the line when it rings, and so on. 352 However, when considering SIP mechanisms for authenticating the 353 called party, this function can also make it difficult to 354 differentiate an intermediary that is behaving legitimately from an 355 attacker. From this perspective, the main problems with retargeting 356 ares: 358 Not detectable by the caller: The originating user agent has no 359 means of anticipating that the condition will arise, nor any means 360 of determining that it has occurred until the call has already 361 been set up, i.e. the negative consequences have already been 362 realized. 364 Not preventable by the caller: There is no existing security 365 mechanism that might be employed by the originating user agent in 366 order to guarantee that the call will not be re-targeted. 368 The mechanism used by SIP for identifying the calling party is SIP 369 Identity [RFC3261]. However, due to the nature of retargeting SIP 370 Identity can only identify the calling party (that is, the party that 371 initiated the SIP request). Some key exchange mechanisms predate SIP 372 Identity and include their own identity mechanism. However, those 373 built-in identity mechanism also suffer from the SIP retargeting 374 problem. Going forward, Connected Identity [RFC4916] allows 375 identifying the called party. 377 In SIP, 'forking' is the delivery of a request to multiple locations. 378 This happens when a single AOR is registered more than once. An 379 example of forking is when a user has a desk phone, PC client, and 380 mobile handset all registered with the same AOR. 382 +-----+ 383 |Alice| 384 +--+--+ 385 | 386 | Invite 387 V 388 +-----+-----+ 389 | proxy | 390 ++---------++ 391 | | 392 Invite | | Invite 393 V V 394 +--+--+ +--+--+ 395 |Bob-1| |Bob-2| 396 +-----+ +-----+ 398 Figure 2: Forking 400 With forking, both Bob-1 and Bob-2 might send back SDP answers in SIP 401 responses. Alice will see those intermediate (18x) and final (200) 402 responses. It is useful for Alice to be able to associate the SIP 403 response with the incoming media stream. Although this association 404 can be done with ICE [I-D.ietf-mmusic-ice], and ICE is useful to make 405 this association with RTP, it is not desirable to require ICE to 406 accomplish this association. 408 Forking and retargeting are often used together. For example, a boss 409 and secretary might have both phones ring (forking) and rollover to 410 voice mail if neither phone is answered (retargeting). 412 To maintain security of the media traffic, only the end point that 413 answers the call should know the SRTP keys for the session. This is 414 only an issue when the key management is encrypted with a key 415 corresponding to the responder. It does not lead to problems with 416 DH-based approaches. For key exchange mechanisms that do not provide 417 secure forking or secure retargeting, one workaround is to re-key 418 immediately after forking or retargeting. However, because the 419 originator may not be aware that the call forked this mechanism 420 requires rekeying immediately after every session is established. 421 This doubles the number of messages processed by the network. 423 Retargeting securely introduces a more significant problem. With 424 retargeting, the actual recipient of the request is not the original 425 recipient. This means that if the offerer encrypted material (such 426 as the session key or the SDP) using the original recipient's public 427 key (or a shared secret established previously), the actual recipient 428 will not be able to decrypt that material because the recipient won't 429 have the original recipient's private key. In some cases, this is 430 the intended behavior, i.e., you wanted to establish a secure 431 connection with a specific individual. In other cases, it is not 432 intended behavior (you want all voice media to be encrypted, 433 regardless of who answers). 435 Further compounding this problem is a particularity of SIP that when 436 forking is used, there is always only one final error response 437 delivered to the sender of the request: the forking proxy is 438 responsible for choosing which final response to choose in the event 439 where forking results in multiple final error responses being 440 received by the forking proxy. This means that if a request is 441 rejected, say with information that the keying information was 442 rejected and providing the far end's credentials, it is very possible 443 that the rejection will never reach the sender. This problem, called 444 the Heterogeneous Error Response Forking Problem (HERFP) 445 [I-D.mahy-sipping-herfp-fix], is difficult to solve in SIP. Because 446 we expect the HERFP to continue to be a problem in SIP for the 447 foreseeable future, a media security system should function even in 448 the presence of HERFP behavior. 450 4.3. Shared Key Conferencing 452 The consensus on the RTPSEC mailing list was to concentrate on 453 unicast, point-to-point sessions. Thus, there are no requirements 454 related to shared key conferencing. This section is retained for 455 informational purposes. 457 For efficient scaling, large audio and video conference bridges 458 operate most efficiently by encrypting the current speaker once and 459 distributing that stream to the conference attendees. Typically, 460 inactive participants receive the same streams -- they hear (or see) 461 the active speaker(s), and the active speakers receive distinct 462 streams that don't include themselves. In order to maintain 463 confidentiality of such conferences where listeners share a common 464 key, all listeners must rekeyed when a listener joins or leaves a 465 conference. 467 An important use case for mixers/translators is a conference bridge: 469 +----+ 470 A --- 1 --->| | 471 <-- 2 ----| M | 472 | I | 473 B --- 3 --->| X | 474 <-- 4 ----| E | 475 | R | 476 C --- 5 --->| | 477 <-- 6 ----| | 478 +----+ 480 Figure 3: Centralized Keying 482 In the figure above, 1, 3, and 5 are RTP media contributions from 483 Alice, Bob, and Carol, and 2, 4, and 6 are the RTP flows to those 484 devices carrying the 'mixed' media. 486 Several scenarios are possible: 488 a. Multiple inbound sessions: 1, 3, and 5 are distinct RTP sessions, 490 b. Multiple outbound sessions: 2, 4, and 6 are distinct RTP 491 sessions, 493 c. Single inbound session: 1, 3, and 5 are just different sources 494 within the same RTP session, 496 d. Single outbound session: 2, 4, and 6 are different flows of the 497 same (multi-unicast) RTP session 499 If there are multiple inbound sessions and multiple outbound sessions 500 (scenarios a and b), then every keying mechanism behaves as if the 501 mixer were an end point and can set up a point-to-point secure 502 session between the participant and the mixer. This is the simplest 503 situation, but is computationally wasteful, since SRTP processing has 504 to be done independently for each participant. The use of multiple 505 inbound sessions (scenario a) doesn't waste computational resources, 506 though it does consume additional cryptographic context on the mixer 507 for each participant and has the advantage of non-repudiation of the 508 originator of the incoming stream. 510 To support a single outbound session (scenario d), the mixer has to 511 dictate its encryption key to the participants. Some keying 512 mechanisms allow the transmitter to determine its own key, and others 513 allow the offerer to determine the key for the offerer and answerer. 514 Depending on how the call is established, the offerer might be a 515 participant (such as a participant dialing into a conference bridge) 516 or the offerer might be the mixer (such as a conference bridge 517 calling a participant). The use of offerless Invites may help some 518 keying mechanisms reverse the role of offerer/answerer. A 519 difficulty, however, is knowing a priori if the role should be 520 reversed for a particular call. 522 4.4. Recording 524 The discussion in this section relates to requirement R23. 526 Some business environments, such as stock brokers, banks, and catalog 527 call centers, require recording calls with customers. This is the 528 familiar "this call is being recorded for quality purposes" heard 529 during calls to these sorts of businesses. In these environments, 530 media recording is typically performed by an intermediate device 531 (with RTP, this is typically implemented in a 'sniffer'). 533 When performing such call recording with SRTP, the end-to-end 534 security is compromised. This is unavoidable, but necessary because 535 the operation of the business requires such recording. It is 536 desirable that the media security is not unduly compromised by the 537 media recording. The endpoint within the organization needs to be 538 informed that there is an intermediate device and needs to cooperate 539 with that intermediate device. 541 This scenario does not place a requirement directly on the key 542 management protocol. The requirement could be met directly by the 543 key management protocol (e.g., MIKEY-NULL or [RFC4568]) or through an 544 external out-of-band-mechanism (e.g., [I-D.wing-sipping-srtp-key]). 546 4.5. PSTN gateway 548 The discussion in this section relates to requirement R26. 550 A typical case of using media security is the one where two entities 551 are having a VoIP conversation over IP capable networks. However, 552 there are cases where the other end of the communication is not 553 connected to an IP capable network. In this kind of setting, there 554 needs to be some kind of gateway at the edge of the IP network which 555 converts the VoIP conversation to format understood by the other 556 network. An example of such gateway is a PSTN gateway sitting at the 557 edge of IP and PSTN networks. 559 If media security (e.g., SRTP protection) is employed in this kind of 560 gateway-setting, then media security and the related key management 561 needs to be terminated at the gateway. The other network (e.g., 562 PSTN) may have its own measures to protect the communication, but 563 this means that from media security point of view the media security 564 is not employed end-to-end between the communicating entities. 566 5. Requirements 568 This section is divided into several parts: requirements specific to 569 the key management protocol (Section 5.1), attack scenarios 570 (Section 5.2), and requirements which can be met inside the key 571 management protocol or outside of the key management protocol 572 (Section 5.3). 574 5.1. Key Management Protocol Requirements 576 SIP Forking and Retargeting, from Section 4.2: 578 R1: The media security key management protocol MUST support forking 579 and retargeting when all endpoints are willing to use SRTP 580 without causing the call setup to fail, unless the execution of 581 the authentication and key exchange protocol leads to a failure 582 (e.g., an unsuccessful authentication attempt). 584 R3: The media security key management protocol MUST create 585 distinct, independent cryptographic contexts for each endpoint 586 in a forked session. 588 Security characteristics: 590 R8: The media security key management protocol MUST be able to 591 support perfect forward secrecy. 593 R9: The media security key management protocol MUST support 594 negotiation of SRTP cipher suites without incurring per- 595 algorithm computational expense. This allows an offer to be 596 built without incurring computational expense for each 597 algorithm. 599 R12: The media security key management protocol MUST NOT require 3rd 600 parties to sign certificates. 602 R13: The media security key management protocol SHOULD use 603 algorithms that allow FIPS 140-2 [FIPS-140-2] certification. 605 Note that the United States Government can only purchase and 606 use crypto implementations that have been validated by the 607 FIPS-140 [FIPS-140-2] process: 609 "The FIPS-140 standard is applicable to all Federal agencies 610 that use cryptographic-based security systems to protect 611 sensitive information in computer and telecommunication 612 systems, including voice systems. The adoption and use of this 613 standard is available to private and commercial 614 organizations."[cryptval] 616 Some commercial organizations, such as banks and defense 617 contractors, also require or prefer equipment which has 618 validated by the FIPS-140 process. 620 R16: The media security key management protocol SHOULD NOT introduce 621 new denial of service vulnerabilities (e.g., the protocol 622 should not request the endpoint to perform CPU-intensive 623 operations without the client being able to validate or 624 authorize the request). 626 R18: If two parties share an authentication infrastructure, they 627 SHOULD be able to make use of it. 629 R19: The media security key management protocol MUST provide crypto- 630 agility, i.e., the ability to adapt to evolving cryptography 631 and security requirements (update of cryptographic algorithms 632 without substantial disruption to deployed implementations) 634 R20: The media security key management protocol MUST protect cipher 635 suite negotiation against downgrading attacks. 637 R24: 639 Performance considerations: 641 R4: The media security key management protocol MAY support the re- 642 use of a previously established security context. 644 Specialized devices may need to avoid public key operations or 645 Diffie-Hellman operations as much as possible because of the 646 computational cost or because of the additional call setup 647 delay. For example, it can take a second or two to perform a 648 Diffie-Hellman operation in certain devices. Examples of these 649 specialized devices would include some handsets, intelligent 650 SIMs, and PSTN gateways. For the typical case because a phone 651 call has not yet been established, ancillary processing cycles 652 can be utilized to perform the PK or DH operation; for example, 653 in a PSTN gateway the DSP, which is not yet involved with 654 typical DSP operations, could be used to perform the 655 calculation, so as to avoid having the central host processor 656 perform the calculation. Some devices, such as handsets, and 657 intelligent SIMs do not have such ancillary processing 658 capability. 660 R11: 662 Media considerations: 664 R5: The media security key management protocol SHOULD avoid 665 clipping media before SDP answer without requiring PRACK 666 [RFC3262]. This requirement comes from Section 4.1. 668 R10: If SRTP key negotiation is performed over the media path (i.e., 669 using the same UDP/TCP ports as media packets), the key 670 negotiation packets MUST NOT pass the RTP validity check 671 defined in Appendix A.1 of [RFC3550]. 673 R15: The media security key management protocol SHOULD allow 674 endpoints to start with RTP and then upgrade to SRTP. 676 Issue: Does this mean 677 [I-D.ietf-mmusic-sdp-capability-negotiation] (which overlaps 678 with R1 and R2), allow RTP during early media (and upgrade to 679 SRTP when the SDP answer arrives), or support an "Encrypt this 680 call" button on the phone? 682 R21: The media security key management protocol MUST allow a SIP 683 User Agent to negotiate media security parameters for each 684 individual session. 686 R25: The media security key management protocol MUST work when there 687 are intermediate nodes (e.g., transcoders), terminating or 688 processing media, between the end points. 690 Issue: Unclear how requirement for transcoders is met. 692 R26: The media security key management protocol MUST support 693 termination of media security in a PSTN gateway. This 694 requirement is from Section 4.5. 696 5.2. Attack Scenario Requirements 698 This section describes requirements from the attack scenarios 699 (Section 3). 701 Required for the passive-signaling-passive-media scenario: 703 R6: The media security key management protocol MUST have a mode 704 which prevents a passive adversary with access to the media 705 path from gaining access to keying material used to protect 706 SRTP media packets. 708 R7: The media security key management protocol MUST have a mode in 709 which it prevents a passive adversary with access to the 710 signaling path from gaining access to keying material used to 711 protect SRTP media packets. 713 Required for the active-signaling-passive-media scenario: 715 R14: The media security key management protocol SHOULD include a 716 mechanism for associating key management messages with both the 717 signaling traffic that initiated the session and with protected 718 media traffic. Allowing such an association also allows the 719 SDP offerer to avoid performing CPU-consuming operations (e.g., 720 DH or public key operations) with attackers that have not seen 721 the signaling messages. 723 For example, if using a Diffie-Hellman keying technique with 724 security preconditions that forks to 20 end points, the call 725 initiator would get 20 provisional responses containing 20 726 signed Diffie-Hellman key pairs. Calculating 20 DH secrets and 727 validating signatures can be a difficult task depending on the 728 device capabilities. Hence, in the case of forking, it is not 729 desirable to perform a DH or PK operation with every party, but 730 rather only with the party that answers the call (and incur 731 some media clipping). To do this, the signaling and media need 732 to be associated so the calling party knows which key 733 management needs to be completed. This might be done by using 734 the transport address indicated in the SDP, although NATs can 735 complicate this association. 737 Required for the active-signaling-active-media scenario: 739 R17: The media security key management protocol SHOULD require the 740 adversary to have access to the signaling path as well as the 741 media path for a successful attack to be launched. An 742 adversary that is located only along the data or only along the 743 signaling path MUST NOT be able to successfully mount an 744 attack. A successful attack refers to the ability for the 745 adversary to obtain keying material to decrypt the SRTP 746 encrypted media traffic. 748 Required for the detect-attack scenario:: 750 R27: The media security key management protocol SHOULD include 751 information in the SDP that can be signed by SIP signaling and 752 validated by the either party (e.g., SIP-Identity [RFC4474] and 753 SIP-Connected-Identity [RFC4916]). This allows the both 754 parties to validate the From: address. The called party can 755 validate the From: address prior to accepting the call. 757 5.3. Requirements Outside of the Key Management Protocol 759 The requirements in this section can be solved within the key 760 management protocol itself, or can be solved outside of the key 761 management protocol itself (e.g., solved in SIP or in SDP). 763 R2: Even when some end points of a forked or retargeted call are 764 incapable of using SRTP, the solution MUST be described which 765 allows the establishment of SRTP associations with SRTP-capable 766 endpoints and / or RTP associations with non-SRTP-capable 767 endpoints. This requirement comes from Section 4.2. 769 R23: The media security key management protocol SHOULD be able to 770 negotiate keys for SRTP sessions created via different call 771 signaling protocols (e.g., between Jabber, SIP, H.323, MGCP). 773 R23: A solution SHOULD be described which supports recording of 774 decrypted media. This requirement comes from Section 4.4. 776 6. Security Considerations 778 This document lists requirements for securing media traffic. As 779 such, it addresses security throughout the document. 781 7. IANA Considerations 783 This document does not require actions by IANA. 785 8. Acknowledgements 787 For contributions to the requirements portion of this document, the 788 authors would like to thank the active participants of the RTPSEC BoF 789 and on the RTPSEC mailing list. The authors would furthermore like 790 to thank Wolfgang Buecker, Guenther Horn, Peter Howard, Hans-Heinrich 791 Grusdt, Srinath Thiruvengadam, Martin Euchner, Eric Rescorla, Matt 792 Lepinski, Dan York, Werner Dittmann, Richard Barnes, Vesa Lehtovirta, 793 Colin Perkins, Peter Schneider, and Christer Holmberg for their 794 feedback to this document. 796 For contributions to the analysis portion of this document, the 797 authors would like to thank Special thanks to Steffen Fries and 798 Dragan Ignjatic for their excellent MIKEY comparison document 799 [I-D.ietf-msec-mikey-applicability]. The authors would furthermore 800 like to thank Cullen Jennings, David Oran, David McGrew, Mark 801 Baugher, Flemming Andreasen, Eric Raymond, Dave Ward, Leo Huang, Eric 802 Rescorla, Lakshminath Dondeti, Steffen Fries, Alan Johnston, Dragan 803 Ignjatic and John Elwell for their feedback to this document. 805 9. References 807 9.1. Normative References 809 [FIPS-140-2] 810 NIST, "Security Requirements for Cryptographic Modules", 811 June 2005, . 814 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 815 Requirement Levels", BCP 14, RFC 2119, March 1997. 817 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 818 A., Peterson, J., Sparks, R., Handley, M., and E. 819 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 820 June 2002. 822 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 823 Provisional Responses in Session Initiation Protocol 824 (SIP)", RFC 3262, June 2002. 826 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 827 with Session Description Protocol (SDP)", RFC 3264, 828 June 2002. 830 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 831 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 832 RFC 3711, March 2004. 834 [cryptval] 835 NIST, "Cryptographic Module Validation Program", 836 December 2006, 837 . 839 9.2. Informative References 841 [I-D.baugher-mmusic-sdp-dh] 842 Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for 843 Multimedia Sessions", draft-baugher-mmusic-sdp-dh-00 (work 844 in progress), February 2006. 846 [I-D.dondeti-msec-rtpsec-mikeyv2] 847 Dondeti, L., "MIKEYv2: SRTP Key Management using MIKEY, 848 revisited", draft-dondeti-msec-rtpsec-mikeyv2-01 (work in 849 progress), March 2007. 851 [I-D.fischl-sipping-media-dtls] 852 Fischl, J., "Datagram Transport Layer Security (DTLS) 853 Protocol for Protection of Media Traffic Established with 854 the Session Initiation Protocol", 855 draft-fischl-sipping-media-dtls-03 (work in progress), 856 July 2007. 858 [I-D.ietf-avt-dtls-srtp] 859 McGrew, D. and E. Rescorla, "Datagram Transport Layer 860 Security (DTLS) Extension to Establish Keys for Secure 861 Real-time Transport Protocol (SRTP)", 862 draft-ietf-avt-dtls-srtp-01 (work in progress), 863 November 2007. 865 [I-D.ietf-mmusic-ice] 866 Rosenberg, J., "Interactive Connectivity Establishment 867 (ICE): A Protocol for Network Address Translator (NAT) 868 Traversal for Offer/Answer Protocols", 869 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 871 [I-D.ietf-mmusic-sdp-capability-negotiation] 872 Andreasen, F., "SDP Capability Negotiation", 873 draft-ietf-mmusic-sdp-capability-negotiation-07 (work in 874 progress), October 2007. 876 [I-D.ietf-msec-mikey-applicability] 877 Fries, S. and D. Ignjatic, "On the applicability of 878 various MIKEY modes and extensions", 879 draft-ietf-msec-mikey-applicability-06 (work in progress), 880 July 2007. 882 [I-D.ietf-msec-mikey-ecc] 883 Milne, A., "ECC Algorithms for MIKEY", 884 draft-ietf-msec-mikey-ecc-03 (work in progress), 885 June 2007. 887 [I-D.ietf-sip-certs] 888 Jennings, C., "Certificate Management Service for The 889 Session Initiation Protocol (SIP)", 890 draft-ietf-sip-certs-04 (work in progress), July 2007. 892 [I-D.jennings-sipping-multipart] 893 Wing, D. and C. Jennings, "Session Initiation Protocol 894 (SIP) Offer/Answer with Multipart Alternative", 895 draft-jennings-sipping-multipart-02 (work in progress), 896 March 2006. 898 [I-D.mahy-sipping-herfp-fix] 899 Mahy, R., "A Solution to the Heterogeneous Error Response 900 Forking Problem (HERFP) in the Session Initiation 901 Protocol (SIP)", draft-mahy-sipping-herfp-fix-01 (work in 902 progress), March 2006. 904 [I-D.mcgrew-srtp-ekt] 905 McGrew, D., "Encrypted Key Transport for Secure RTP", 906 draft-mcgrew-srtp-ekt-03 (work in progress), July 2007. 908 [I-D.wing-sipping-srtp-key] 909 Wing, D., Audet, F., Fries, S., and H. Tschofenig, 910 "Disclosing Secure RTP (SRTP) Session Keys with a SIP 911 Event Package", draft-wing-sipping-srtp-key-02 (work in 912 progress), November 2007. 914 [I-D.zimmermann-avt-zrtp] 915 Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure 916 RTP", draft-zimmermann-avt-zrtp-04 (work in progress), 917 July 2007. 919 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 920 X.509 Public Key Infrastructure Certificate and 921 Certificate Revocation List (CRL) Profile", RFC 3280, 922 April 2002. 924 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 925 Schulzrinne, "Grouping of Media Lines in the Session 926 Description Protocol (SDP)", RFC 3388, December 2002. 928 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 929 Jacobson, "RTP: A Transport Protocol for Real-Time 930 Applications", STD 64, RFC 3550, July 2003. 932 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 933 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 934 August 2004. 936 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 937 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 939 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 940 Authenticated Identity Management in the Session 941 Initiation Protocol (SIP)", RFC 4474, August 2006. 943 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 944 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 945 for Transport Layer Security (TLS)", RFC 4492, May 2006. 947 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 948 Description Protocol (SDP) Security Descriptions for Media 949 Streams", RFC 4568, July 2006. 951 [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for 952 Multimedia Internet KEYing (MIKEY)", RFC 4650, 953 September 2006. 955 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 956 RSA-R: An Additional Mode of Key Distribution in 957 Multimedia Internet KEYing (MIKEY)", RFC 4738, 958 November 2006. 960 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 961 Transform Carrying Roll-Over Counter for the Secure Real- 962 time Transport Protocol (SRTP)", RFC 4771, January 2007. 964 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 965 Protocol (SIP)", RFC 4916, June 2007. 967 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 968 RFC 4949, August 2007. 970 [RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for 971 Session Description Protocol (SDP) Media Streams", 972 RFC 5027, October 2007. 974 Appendix A. Overview of Keying Mechanisms 976 Based on how the SRTP keys are exchanged, each SRTP key exchange 977 mechanism belongs to one general category: 979 signaling path: All the keying is carried in the call signaling 980 (SIP or SDP) path. 982 media path: All the keying is carried in the SRTP/SRTCP media 983 path, and no signaling whatsoever is carried in the call 984 signaling path. 986 signaling and media path: Parts of the keying are carried in the 987 SRTP/SRTCP media path, and parts are carried in the call 988 signaling (SIP or SDP) path. 990 One of the significant benefits of SRTP over other end-to-end 991 encryption mechanisms, such as for example IPsec, is that SRTP is 992 bandwidth efficient and SRTP retains the header of RTP packets. 993 Bandwidth efficiency is vital for VoIP in many scenarios where access 994 bandwidth is limited or expensive, and retaining the RTP header is 995 important for troubleshooting packet loss, delay, and jitter. 997 Related to SRTP's characteristics is a goal that any SRTP keying 998 mechanism to also be efficient and not cause additional call setup 999 delay. Contributors to additional call setup delay include network 1000 or database operations: retrieval of certificates and additional SIP 1001 or media path messages, and computational overhead of establishing 1002 keys or validating certificates. 1004 When examining the choice between keying in the signaling path, 1005 keying in the media path, or keying in both paths, it is important to 1006 realize the media path is generally 'faster' than the SIP signaling 1007 path. The SIP signaling path has computational elements involved 1008 which parse and route SIP messages. The media path, on the other 1009 hand, does not normally have computational elements involved, and 1010 even when computational elements such as firewalls are involved, they 1011 cause very little additional delay. Thus, the media path can be 1012 useful for exchanging several messages to establish SRTP keys. A 1013 disadvantage of keying over the media path is that interworking 1014 different key exchange requires the interworking function be in the 1015 media path, rather than just in the signaling path; in practice this 1016 involvement is probably unavoidable anyway. 1018 A.1. Signaling Path Keying Techniques 1020 A.1.1. MIKEY-NULL 1022 MIKEY-NULL [RFC3830] has the offerer indicate the SRTP keys for both 1023 directions. The key is sent unencrypted in SDP, which means the SDP 1024 must be encrypted hop-by-hop (e.g., by using TLS (SIPS)) or end-to- 1025 end (e.g., by using S/MIME). 1027 MIKEY-NULL requires one message from offerer to answerer (half a 1028 round trip), and does not add additional media path messages. 1030 A.1.2. MIKEY-PSK 1032 MIKEY-PSK (pre-shared key) [RFC3830] requires that all endpoints 1033 share one common key. MIKEY-PSK has the offerer encrypt the SRTP 1034 keys for both directions using this pre-shared key. 1036 MIKEY-PSK requires one message from offerer to answerer (half a round 1037 trip), and does not add additional media path messages. 1039 A.1.3. MIKEY-RSA 1041 MIKEY-RSA [RFC3830] has the offerer encrypt the keys for both 1042 directions using the intended answerer's public key, which is 1043 obtained from a PKI. 1045 MIKEY-RSA requires one message from offerer to answerer (half a round 1046 trip), and does not add additional media path messages. MIKEY-RSA 1047 requires the offerer to obtain the intended answerer's certificate. 1049 A.1.4. MIKEY-RSA-R 1051 MIKEY-RSA-R [RFC4738] is essentially the same as MIKEY-RSA but 1052 reverses the role of the offerer and the answerer with regards to 1053 providing the keys. That is, the answerer encrypts the keys for both 1054 directions using the offerer's public key. Both the offerer and 1055 answerer validate each other's public keys using a PKI. MIKEY-RSA-R 1056 also enables sending certificates in the MIKEY message. 1058 MIKEY-RSA-R requires one message from offerer to answer, and one 1059 message from answerer to offerer (full round trip), and does not add 1060 additional media path messages. MIKEY-RSA-R requires the offerer 1061 validate the answerer's certificate. 1063 A.1.5. MIKEY-DHSIGN 1065 In MIKEY-DHSIGN [RFC3830] the offerer and answerer derive the key 1066 from a Diffie-Hellman exchange. In order to prevent an active man- 1067 in-the-middle the DH exchange itself is signed using each endpoint's 1068 private key and the associated public keys are validated using a PKI. 1070 MIKEY-DHSIGN requires one message from offerer to answerer, and one 1071 message from answerer to offerer (full round trip), and does not add 1072 additional media path messages. MIKEY-DHSIGN requires the offerer 1073 and answerer to validate each other's certificates. MIKEY-DHSIGN 1074 also enables sending the answerer's certificate in the MIKEY message. 1076 A.1.6. MIKEY-DHHMAC 1078 MIKEY-DHHMAC [RFC4650] uses a pre-shared secret to HMAC the Diffie- 1079 Hellman exchange, essentially combining aspects of MIKEY-PSK with 1080 MIKEY-DHSIGN, but without MIKEY-DHSIGN's need for a PKI to 1081 authenticate the Diffie-Hellman exchange. 1083 MIKEY-DHHMAC requires one message from offerer to answerer, and one 1084 message from answerer to offerer (full round trip), and does not add 1085 additional media path messages. 1087 A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) 1089 ECC Algorithms For MIKEY [I-D.ietf-msec-mikey-ecc] describes how ECC 1090 can be used with MIKEY-RSA (using ECDSA signature) and with MIKEY- 1091 DHSIGN (using a new DH-Group code), and also defines two new ECC- 1092 based algorithms, Elliptic Curve Integrated Encryption Scheme (ECIES) 1093 and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) . 1095 For the purposes of this paper, the ECDSA signature, MIKEY-ECIES, and 1096 MIKEY-ECMQV function exactly like MIKEY-RSA, and the new DH-Group 1097 code function exactly like MIKEY-DHSIGN. Therefore these ECC 1098 mechanisms aren't discussed separately in this paper. 1100 A.1.8. Security Descriptions with SIPS 1102 Security Descriptions [RFC4568] has each side indicate the key it 1103 will use for transmitting SRTP media, and the keys are sent in the 1104 clear in SDP. Security Descriptions relies on hop-by-hop (TLS via 1105 "SIPS:") encryption to protect the keys exchanged in signaling. 1107 Security Descriptions requires one message from offerer to answerer, 1108 and one message from answerer to offerer (full round trip), and does 1109 not add additional media path messages. 1111 A.1.9. Security Descriptions with S/MIME 1113 This keying mechanism is identical to Appendix A.1.8, except that 1114 rather than protecting the signaling with TLS, the entire SDP is 1115 encrypted with S/MIME. 1117 A.1.10. SDP-DH (expired) 1119 SDP Diffie-Hellman [I-D.baugher-mmusic-sdp-dh] exchanges Diffie- 1120 Hellman messages in the signaling path to establish session keys. To 1121 protect against active man-in-the-middle attacks, the Diffie-Hellman 1122 exchange needs to be protected with S/MIME, SIPS, or SIP-Identity 1123 [RFC4474] and [RFC4474]. 1125 SDP-DH requires one message from offerer to answerer, and one message 1126 from answerer to offerer (full round trip), and does not add 1127 additional media path messages. 1129 A.1.11. MIKEYv2 in SDP (expired) 1131 MIKEYv2 [I-D.dondeti-msec-rtpsec-mikeyv2] adds mode negotiation to 1132 MIKEYv1 and removes the time synchronization requirement. It 1133 therefore now takes 2 round-trips to complete. In the first round 1134 trip, the communicating parties learn each other's identities, agree 1135 on a MIKEY mode, crypto algorithm, SRTP policy, and exchanges nonces 1136 for replay protection. In the second round trip, they negotiate 1137 unicast and/or group SRTP context for SRTP and/or SRTCP. 1139 Furthemore, MIKEYv2 also defines an in-band negotiation mode as an 1140 alternative to SDP (see Appendix A.3.3). 1142 A.2. Media Path Keying Technique 1144 A.2.1. ZRTP 1146 ZRTP [I-D.zimmermann-avt-zrtp] does not exchange information in the 1147 signaling path (although it's possible for endpoints to indicate 1148 support for ZRTP with "a=zrtp" in the initial Offer). In ZRTP the 1149 keys are exchanged entirely in the media path using a Diffie-Hellman 1150 exchange. The advantage to this mechanism is that the signaling 1151 channel is used only for call setup and the media channel is used to 1152 establish an encrypted channel -- much like encryption devices on the 1153 PSTN. ZRTP uses voice authentication of its Diffie-Hellman exchange 1154 by having each person read digits to the other person. Subsequent 1155 sessions with the same ZRTP endpoint can be authenticated using the 1156 stored hash of the previously negotiated key rather than voice 1157 authentication. 1159 ZRTP uses 4 media path messages (Hello, Commit, DHPart1, and DHPart2) 1160 to establish the SRTP key, and 3 media path confirmation messages. 1161 These initial messages are all sent as non-RTP packets. 1163 Note that when ZRTP probing is used, unencrypted RTP is being 1164 exchanged until the SRTP keys are established. 1166 A.3. Signaling and Media Path Keying Techniques 1168 A.3.1. EKT 1170 EKT [I-D.mcgrew-srtp-ekt] relies on another SRTP key exchange 1171 protocol, such as Security Descriptions or MIKEY, for bootstrapping. 1172 In the initial phase, each member of a conference uses an SRTP key 1173 exchange protocol to establish a common key encryption key (KEK). 1174 Each member may use the KEK to securely transport its SRTP master key 1175 and current SRTP rollover counter (ROC), via RTCP, to the other 1176 participants in the session. 1178 EKT requires the offerer to send some parameters (EKT_Cipher, KEK, 1179 and security parameter index (SPI)) via the bootstrapping protocol 1180 such as Security Descriptions or MIKEY. Each answerer sends an SRTCP 1181 message which contains the answerer's SRTP Master Key, rollover 1182 counter, and the SRTP sequence number. Rekeying is done by sending a 1183 new SRTCP message. For reliable transport, multiple RTCP messages 1184 need to be sent. 1186 A.3.2. DTLS-SRTP 1188 DTLS-SRTP [I-D.ietf-avt-dtls-srtp] exchanges public key fingerprints 1189 in SDP [I-D.fischl-sipping-media-dtls] and then establishes a DTLS 1190 session over the media channel. The endpoints use the DTLS handshake 1191 to agree on crypto suites and establish SRTP session keys. SRTP 1192 packets are then exchanged between the endpoints. 1194 DTLS-SRTP requires one message from offerer to answerer (half round 1195 trip), and, if the offerer wishes to correlate the SDP answer with 1196 the endpoint, requires one message from answer to offerer (full round 1197 trip). DTLS-SRTP uses 4 media path messages to establish the SRTP 1198 key. 1200 This paper assumes DTLS will use TLS_RSA_WITH_3DES_EDE_CBC_SHA as its 1201 cipher suite, which is the mandatory-to-implement cipher suite in TLS 1202 [RFC4346]. 1204 A.3.3. MIKEYv2 Inband (expired) 1206 As defined in Appendix A.1.11, MIKEYv2 also defines an in-band 1207 negotiation mode as an alternative to SDP (see Appendix A.3.3). The 1208 details are not sorted out in the draft yet on what in-band actually 1209 means (i.e., UDP, RTP, RTCP, etc.). 1211 Appendix B. Evaluation Criteria - SIP 1213 This section considers how each keying mechanism interacts with SIP 1214 features. 1216 B.1. Secure Retargeting and Secure Forking 1218 Retargeting and forking of signaling requests is described within 1219 Section 4.2. The following builds upon this description. 1221 The following list compares the behavior of secure forking, answering 1222 association, two-time pads, and secure retargeting for each keying 1223 mechanism. 1225 MIKEY-NULL Secure Forking: No, all AORs see offerer's and 1226 answerer's keys. Answer is associated with media by the SSRC 1227 in MIKEY. Additionally, a two-time pad occurs if two branches 1228 choose the same 32-bit SSRC and transmit SRTP packets. 1230 Secure Retargeting: No, all targets see offerer's and 1231 answerer's keys. Suffers from retargeting identity problem. 1233 MIKEY-PSK 1234 Secure Forking: No, all AORs see offerer's and answerer's keys. 1235 Answer is associated with media by the SSRC in MIKEY. Note 1236 that all AORs must share the same pre-shared key in order for 1237 forking to work at all with MIKEY-PSK. Additionally, a two- 1238 time pad occurs if two branches choose the same 32-bit SSRC and 1239 transmit SRTP packets. 1241 Secure Retargeting: Not secure. For retargeting to work, the 1242 final target must possess the correct PSK. As this is likely 1243 in scenarios were the call is targeted to another device 1244 belonging to the same user (forking), it is very unlikely that 1245 other users will possess that PSK and be able to successfully 1246 answer that call. 1248 MIKEY-RSA 1249 Secure Forking: No, all AORs see offerer's and answerer's keys. 1250 Answer is associated with media by the SSRC in MIKEY. Note 1251 that all AORs must share the same private key in order for 1252 forking to work at all with MIKEY-RSA. Additionally, a two- 1253 time pad occurs if two branches choose the same 32-bit SSRC and 1254 transmit SRTP packets. 1256 Secure Retargeting: No. 1258 MIKEY-RSA-R 1259 Secure Forking: Yes. Answer is associated with media by the 1260 SSRC in MIKEY. 1262 Secure Retargeting: Yes. 1264 MIKEY-DHSIGN 1265 Secure Forking: Yes, each forked endpoint negotiates unique 1266 keys with the offerer for both directions. Answer is 1267 associated with media by the SSRC in MIKEY. 1269 Secure Retargeting: Yes, each target negotiates unique keys 1270 with the offerer for both directions. 1272 MIKEYv2 in SDP 1273 The behavior will depend on which mode is picked. 1275 MIKEY-DHHMAC 1276 Secure Forking: Yes, each forked endpoint negotiates unique 1277 keys with the offerer for both directions. Answer is 1278 associated with media by the SSRC in MIKEY. 1280 Secure Retargeting: Yes, each target negotiates unique keys 1281 with the offerer for both directions. Note that for the keys 1282 to be meaningful, it would require the PSK to be the same for 1283 all the potential intermediaries, which would only happen 1284 within a single domain. 1286 Security Descriptions with SIPS 1287 Secure Forking: No. Each forked endpoint sees the offerer's 1288 key. Answer is not associated with media. 1290 Secure Retargeting: No. Each target sees the offerer's key. 1292 Security Descriptions with S/MIME 1293 Secure Forking: No. Each forked endpoint sees the offerer's 1294 key. Answer is not associated with media. 1296 Secure Retargeting: No. Each target sees the offerer's key. 1297 Suffers from retargeting identity problem. 1299 SDP-DH 1300 Secure Forking: Yes. Each forked endpoint calculates a unique 1301 SRTP key. Answer is not associated with media. 1303 Secure Retargeting: Yes. The final target calculates a unique 1304 SRTP key. 1306 ZRTP 1307 Secure Forking: Yes. Each forked endpoint calculates a unique 1308 SRTP key. As ZRTP isn't signaled in SDP, there is no 1309 association of the answer with media. 1311 Secure Retargeting: Yes. The final target calculates a unique 1312 SRTP key. 1314 EKT 1315 Secure Forking: Inherited from the bootstrapping mechanism (the 1316 specific MIKEY mode or Security Descriptions). Answer is 1317 associated with media by the SPI in the EKT protocol. Answer 1318 is associated with media by the SPI in the EKT protocol. 1320 Secure Retargeting: Inherited from the bootstrapping mechanism 1321 (the specific MIKEY mode or Security Descriptions). 1323 DTLS-SRTP 1324 Secure Forking: Yes. Each forked endpoint calculates a unique 1325 SRTP key. Answer is associated with media by the certificate 1326 fingerprint in signaling and certificate in the media path. 1328 Secure Retargeting: Yes. The final target calculates a unique 1329 SRTP key. 1331 MIKEYv2 Inband 1332 The behavior will depend on which mode is picked. 1334 B.2. Clipping Media Before SDP Answer 1336 Clipping media before receiving the signaling answer is described 1337 within Section 4.1. The following builds upon this description. 1339 Furthermore, the problem of clipping gets compounded when forking is 1340 used. For example, if using a Diffie-Hellman keying technique with 1341 security preconditions that forks to 20 endpoints, the call initiator 1342 would get 20 provisional responses containing 20 signed Diffie- 1343 Hellman half keys. Calculating 20 DH secrets and validating 1344 signatures can be a difficult task depending on the device 1345 capabilities. 1347 The following list compares the behavior of clipping before SDP 1348 answer for each keying mechanism. 1350 MIKEY-NULL 1351 Not clipped. The offerer provides the answerer's keys. 1353 MIKEY-PSK 1354 Not clipped. The offerer provides the answerer's keys. 1356 MIKEY-RSA 1357 Not clipped. The offerer provides the answerer's keys. 1359 MIKEY-RSA-R 1360 Clipped. The answer contains the answerer's encryption key. 1362 MIKEY-DHSIGN 1363 Clipped. The answer contains the answerer's Diffie-Hellman 1364 response. 1366 MIKEY-DHHMAC 1367 Clipped. The answer contains the answerer's Diffie-Hellman 1368 response. 1370 MIKEYv2 in SDP 1371 The behavior will depend on which mode is picked. 1373 Security Descriptions with SIPS 1374 Clipped. The answer contains the answerer's encryption key. 1376 Security Descriptions with S/MIME 1377 Clipped. The answer contains the answerer's encryption key. 1379 SDP-DH 1380 Clipped. The answer contains the answerer's Diffie-Hellman 1381 response. 1383 ZRTP 1384 Not clipped because the session intially uses RTP. While RTP 1385 is flowing, both ends negotiate SRTP keys in the media path and 1386 then switch to using SRTP. 1388 EKT 1389 Not clipped, as long as the first RTCP packet (containing the 1390 answerer's key) is not lost in transit. The answerer sends its 1391 encryption key in RTCP, which arrives at the same time (or 1392 before) the first SRTP packet encrypted with that key. 1394 Note: RTCP needs to work, in the answerer-to-offerer 1395 direction, before the offerer can decrypt SRTP media. 1397 DTLS-SRTP 1398 Not clipped. Keys are exchanged in the media path without 1399 relying on the signaling path. 1401 MIKEYv2 Inband 1402 Not clipped. Keys are exchanged in the media path without 1403 relying on the signaling path. 1405 B.3. Centralized Keying 1407 Centralized keying is described within Section 4.3. The following 1408 builds upon this description. 1410 The following list describes how each keying mechanism behaves with 1411 centralized keying (scenario d) and rekeying. 1413 MIKEY-NULL 1414 Keying: Yes, if offerer is the mixer. No, if offerer is the 1415 participant (end user). 1417 Rekeying: Yes, via re-Invite 1419 MIKEY-PSK 1420 Keying: Yes, if offerer is the mixer. No, if offerer is the 1421 participant (end user). 1423 Rekeying: Yes, with a re-Invite 1425 MIKEY-RSA 1426 Keying: Yes, if offerer is the mixer. No, if offerer is the 1427 participant (end user). 1429 Rekeying: Yes, with a re-Invite 1431 MIKEY-RSA-R 1432 Keying: No, if offerer is the mixer. Yes, if offerer is the 1433 participant (end user). 1435 Rekeying: n/a 1437 MIKEY-DHSIGN 1438 Keying: No; a group-key Diffie-Hellman protocol is not 1439 supported. 1441 Rekeying: n/a 1443 MIKEY-DHHMAC 1444 Keying: No; a group-key Diffie-Hellman protocol is not 1445 supported. 1447 Rekeying: n/a 1449 MIKEYv2 in SDP 1450 The behavior will depend on which mode is picked. 1452 Security Descriptions with SIPS 1453 Keying: Yes, if offerer is the mixer. Yes, if offerer is the 1454 participant. 1456 Rekeying: Yes, with a Re-Invite. 1458 Security Descriptions with S/MIME 1459 Keying: Yes, if offerer is the mixer. Yes, if offerer is the 1460 participant. 1462 Rekeying: Yes, with a Re-Invite. 1464 SDP-DH 1465 Keying: No; a group-key Diffie-Hellman protocol is not 1466 supported. 1468 Rekeying: n/a 1470 ZRTP 1471 Keying: No; a group-key Diffie-Hellman protocol is not 1472 supported. 1474 Rekeying: n/a 1476 EKT 1477 Keying: Yes. After bootstrapping a KEK using Security 1478 Descriptions or MIKEY, each member originating an SRTP stream 1479 can send its SRTP master key, sequence number and ROC via RTCP. 1481 Rekeying: Yes. EKT supports each sender to transmit its SRTP 1482 master key to the group via RTCP packets. Thus, EKT supports 1483 each originator of an SRTP stream to rekey at any time. 1485 DTLS-SRTP 1486 Keying: Yes, because with the assumed cipher suite, 1487 TLS_RSA_WITH_3DES_EDE_CBC_SHA, each end indicates its SRTP key. 1489 Rekeying: via DTLS in the media path. 1491 MIKEYv2 Inband 1492 The behavior will depend on which mode is picked. 1494 B.4. SSRC and ROC 1496 In SRTP, a cryptographic context is defined as the SSRC, destination 1497 network address, and destination transport port number. Whereas RTP, 1498 a flow is defined as the destination network address and destination 1499 transport port number. This results in a problem -- how to 1500 communicate the SSRC so that the SSRC can be used for the 1501 cryptographic context. 1503 Two approaches have emerged for this communication. One, used by all 1504 MIKEY modes, is to communicate the SSRCs to the peer in the MIKEY 1505 exchange. Another, used by Security Descriptions, is to use "late 1506 bindng" -- that is, any new packet containing a previously-unseen 1507 SSRC (which arrives at the same destination network address and 1508 destination transport port number) will create a new cryptographic 1509 context. Another approach, common amongst techniques with media-path 1510 SRTP key establishment, is to require a handshake over that media 1511 path before SRTP packets are sent. MIKEY's approach changes RTP's 1512 SSRC collision detection behavior by requiring RTP to pre-establish 1513 the SSRC values for each session. 1515 Another related issue is that SRTP introduces a rollover counter 1516 (ROC), which records how many times the SRTP sequence number has 1517 rolled over. As the sequence number is used for SRTP's default 1518 ciphers, it is important that all endpoints know the value of the 1519 ROC. The ROC starts at 0 at the beginning of a session. 1521 Some keying mechanisms cause a two-time pad to occur if two endpoints 1522 of a forked call have an SSRC collision. 1524 Note: A proposal has been made to send the ROC value on every Nth 1525 SRTP packet[RFC4771]. This proposal has not yet been incorporated 1526 into this document. 1528 The following list examines handling of SSRC and ROC: 1530 MIKEY-NULL 1531 Each endpoint indicates a set of SSRCs and the ROC for SRTP 1532 packets it transmits. 1534 MIKEY-PSK 1535 Each endpoint indicates a set of SSRCs and the ROC for SRTP 1536 packets it transmits. 1538 MIKEY-RSA 1539 Each endpoint indicates a set of SSRCs and the ROC for SRTP 1540 packets it transmits. 1542 MIKEY-RSA-R 1543 Each endpoint indicates a set of SSRCs and the ROC for SRTP 1544 packets it transmits. 1546 MIKEY-DHSIGN 1547 Each endpoint indicates a set of SSRCs and the ROC for SRTP 1548 packets it transmits. 1550 MIKEY-DHHMAC 1551 Each endpoint indicates a set of SSRCs and the ROC for SRTP 1552 packets it transmits. 1554 MIKEYv2 in SDP 1555 Each endpoint indicates a set of SSRCs and the ROC for SRTP 1556 packets it transmits. 1558 Security Descriptions with SIPS 1559 Neither SSRC nor ROC are signaled. SSRC 'late binding' is 1560 used. 1562 Security Descriptions with S/MIME 1563 Neither SSRC nor ROC are signaled. SSRC 'late binding' is 1564 used. 1566 SDP-DH 1567 Neither SSRC nor ROC are signaled. SSRC 'late binding' is 1568 used. 1570 ZRTP 1571 Neither SSRC nor ROC are signaled. SSRC 'late binding' is 1572 used. 1574 EKT 1575 The SSRC of the SRTCP packet containing an EKT update 1576 corresponds to the SRTP master key and other parameters within 1577 that packet. 1579 DTLS-SRTP 1580 Neither SSRC nor ROC are signaled. SSRC 'late binding' is 1581 used. 1583 MIKEYv2 Inband 1584 Each endpoint indicates a set of SSRCs and the ROC for SRTP 1585 packets it transmits. 1587 Appendix C. Evaluation Criteria - Security 1589 This section evaluates each keying mechanism on the basis of their 1590 security properties. 1592 C.1. Public Key Infrastructure 1594 There are two aspects of PKI requirements -- one aspect is if PKI is 1595 necessary in order for the mechanism to function at all, the other is 1596 if PKI is used to authenticate a certificate. With interactive 1597 communications it is desirable to avoid fetching certificates that 1598 delay call setup; rather it is preferable to fetch or validate 1599 certificates in such a way that call setup isn't delayed. For 1600 example, a certificate can be validated while the phone is ringing or 1601 can be validated while ring-back tones are being played or even while 1602 the called party is answering the phone and saying "hello". 1604 SRTP key exchange mechanisms that require a particular authentication 1605 infrastructure to operate are gated on the deployment of a such an 1606 infrastructure available to both endpoints. This means that no media 1607 security is achievable until such an infrastructure exists. For SIP, 1608 something like sip-certs [I-D.ietf-sip-certs] might be used to obtain 1609 the certificate of a peer. 1611 Note: Even if sip-certs [I-D.ietf-sip-certs] was deployed, the 1612 retargeting problem (Appendix B.1) would still prevent successful 1613 deployment of keying techniques which require the offerer to 1614 obtain the actual target's public key. 1616 The following list compares the PKI requirements of each keying 1617 mechanism, both if a PKI is required for the key exchange itself, and 1618 if PKI is only used to authenticate the certificate supplied in 1619 signaling. 1621 MIKEY-NULL 1622 PKI not used. 1624 MIKEY-PSK 1625 PKI not used; rather, all endpoints must have some way to 1626 exchange per-endpoint or per-system pre-shared keys. 1628 MIKEY-RSA 1629 The offerer obtains the intended answerer's public key before 1630 initiating the call. This public key is used to encrypt the 1631 SRTP keys. There is no defined mechanism for the offerer to 1632 obtain the answerer's public key, although [I-D.ietf-sip-certs] 1633 might be viable in the future. 1635 MIKEY-RSA-R 1636 The offer contains the offerer's public key. The answerer uses 1637 that public key to encrypt the SRTP keys that will be used by 1638 the offerer and the answerer. A PKI is necessary to validate 1639 the certificates. 1641 MIKEY-DHSIGN 1642 PKI is used to authenticate the public key that is included in 1643 the MIKEY message, by walking the CA trust chain. 1645 MIKEY-DHHMAC 1646 PKI not used; rather, all endpoints must have some way to 1647 exchange per-endpoint or per-system pre-shared keys. 1649 MIKEYv2 in SDP 1650 The behavior will depend on which mode is picked. 1652 Security Descriptions with SIPS 1653 PKI not used. 1655 Security Descriptions with S/MIME 1656 PKI is needed for S/MIME. The offerer must obtain the intended 1657 target's public key and encrypt their SDP with that key. The 1658 answerer must obtain the offerer's public key and encrypt their 1659 SDP with that key. 1661 SDP-DH 1662 PKI not used. 1664 ZRTP 1665 PKI not used. 1667 EKT 1668 PKI not used by EKT itself, but might be used by the EKT 1669 bootstrapping keying mechanism (such as certain MIKEY modes). 1671 DTLS-SRTP 1672 Remote party's certificate is sent in media path, and a 1673 fingerprint of the same certificate is sent in the signaling 1674 path. 1676 MIKEYv2 Inband 1677 The behavior will depend on which mode is picked. 1679 C.2. Perfect Forward Secrecy 1681 In the context of SRTP, Perfect Forward Secrecy is the property that 1682 SRTP session keys that protected a previous session are not 1683 compromised if the static keys belonging to the endpoints are 1684 compromised. That is, if someone were to record your encrypted 1685 session content and later acquires either party's private key, that 1686 encrypted session content would be safe from decryption if your key 1687 exchange mechanism had perfect forward secrecy. 1689 The following list describes how each key exchange mechanism provides 1690 PFS. 1692 MIKEY-NULL 1693 No PFS. 1695 MIKEY-PSK 1696 No PFS. 1698 MIKEY-RSA 1699 No PFS. 1701 MIKEY-RSA-R 1702 No PFS. 1704 MIKEY-DHSIGN 1705 PFS is provided with the Diffie-Hellman exchange. 1707 MIKEY-DHHMAC 1708 PFS is provided with the Diffie-Hellman exchange. 1710 MIKEYv2 in SDP 1711 The behavior will depend on which mode is picked. 1713 Security Descriptions with SIPS 1714 No PFS. 1716 Security Descriptions with S/MIME 1717 No PFS. 1719 SDP-DH 1720 PFS is provided with the Diffie-Hellman exchange. 1722 ZRTP 1723 PFS is provided with the Diffie-Hellman exchange. 1725 EKT 1726 No PFS. 1728 DTLS-SRTP 1729 PFS is achieved if the negotiated cipher suite includes an 1730 exponential or discrete-logarithmic key exchange (such as 1731 Diffie-Hellman or Elliptic Curve Diffie-Hellman [RFC4492]). 1733 MIKEYv2 Inband 1734 The behavior will depend on which mode is picked. 1736 C.3. Best Effort Encryption 1738 With best effort encryption, SRTP is used with endpoints that support 1739 SRTP, otherwise RTP is used. 1741 SIP needs a backwards-compatible best effort encryption in order for 1742 SRTP to work successfully with SIP retargeting and forking when there 1743 is a mix of forked or retargeted devices that support SRTP and don't 1744 support SRTP. 1746 Consider the case of Bob, with a phone that only does RTP and a 1747 voice mail system that supports SRTP and RTP. If Alice calls Bob 1748 with an SRTP offer, Bob's RTP-only phone will reject the media 1749 stream (with an empty "m=" line) because Bob's phone doesn't 1750 understand SRTP (RTP/SAVP). Alice's phone will see this rejected 1751 media stream and may terminate the entire call (BYE) and re- 1752 initiate the call as RTP-only, or Alice's phone may decide to 1753 continue with call setup with the SRTP-capable leg (the voice mail 1754 system). If Alice's phone decided to re-initiate the call as RTP- 1755 only, and Bob doesn't answer his phone, Alice will then leave 1756 voice mail using only RTP, rather than SRTP as expected. 1758 Currently, several techniques are commonly considered as candidates 1759 to provide opportunistic encryption: 1761 multipart/alternative 1762 [I-D.jennings-sipping-multipart] describes how to form a 1763 multipart/alternative body part in SIP. The significant issues 1764 with this technique are (1) that multipart MIME is incompatible 1765 with existing SIP proxies, firewalls, Session Border Controllers, 1766 and endpoints and (2) when forking, the Heterogeneous Error 1767 Response Forking Problem (HERFP) [I-D.mahy-sipping-herfp-fix] 1768 causes problems if such non-multipart-capable endpoints were 1769 involved in the forking. 1771 SDP Grouping 1772 A new SDP grouping mechanism (following the idea introduced in 1773 [RFC3388]) has been discussed which would allow a media line to 1774 indicate RTP/AVP and another media line to indicate RTP/SAVP, 1775 allowing non-SRTP-aware endpoints to choose RTP/AVP and SRTP-aware 1776 endpoints to choose RTP/SAVP. As of this writing, this SDP 1777 grouping mechanism has not been published as an Internet Draft. 1779 session attribute 1780 With this technique, the endpoints signal their desire to do SRTP 1781 by signaling RTP (RTP/AVP), and using an attribute ("a=") in the 1782 SDP. This technique is entirely backwards compatible with non- 1783 SRTP-aware endpoints, but doesn't use the RTP/SAVP protocol 1784 registered by SRTP [RFC3711]. 1786 SDP Capability Negotiation 1787 SDP Capability Negotiation 1788 [I-D.ietf-mmusic-sdp-capability-negotiation] provides a backwards- 1789 compatible mechanism to allow offering both SRTP and RTP in a 1790 single offer. This is the preferred technique. 1792 Probing 1793 With this technique, the endpoints first establish an RTP session 1794 using RTP (RTP/AVP). The endpoints send probe messages, over the 1795 media path, to determine if the remote endpoint supports their 1796 keying technique. 1798 The preferred technique, SDP Capability Negotiation 1799 [I-D.ietf-mmusic-sdp-capability-negotiation], can be used with all 1800 key exchange mechanisms. What remains unique is ZRTP, which can also 1801 accomplish its best effort encryption by probing (sending ZRTP 1802 messages over the media path) or by session attribute (see "a=zrtp", 1803 defined in Section 10 of [I-D.zimmermann-avt-zrtp]). Current 1804 implementations of ZRTP use probing. 1806 C.4. Upgrading Algorithms 1808 It is necessary to allow upgrading SRTP encryption and hash 1809 algorithms, as well as upgrading the cryptographic functions used for 1810 the key exchange mechanism. With SIP's offer/answer model, this can 1811 be computionally expensive because the offer needs to contain all 1812 combinations of the key exchange mechanisms (all MIKEY modes, 1813 Security Descriptions) and all SRTP cryptographic suites (AES-128, 1814 AES-256) and all SRTP cryptographic hash functions (SHA-1, SHA-256) 1815 that the offerer supports. In order to do this, the offerer has to 1816 expend CPU resources to build an offer containing all of this 1817 information which becomes computationally prohibitive. 1819 Thus, it is important to keep the offerer's CPU impact fixed so that 1820 offering multiple new SRTP encryption and hash functions incurs no 1821 additional expense. 1823 The following list describes the CPU effort involved in using each 1824 key exchange technique. 1826 MIKEY-NULL 1827 No significant computaional expense. 1829 MIKEY-PSK 1830 No significant computational expense. 1832 MIKEY-RSA 1833 For each offered SRTP crypto suite, the offerer has to perform 1834 RSA operation to encrypt the TGK 1836 MIKEY-RSA-R 1837 For each offered SRTP crypto suite, the offerer has to perform 1838 public key operation to sign the MIKEY message. 1840 MIKEY-DHSIGN 1841 For each offered SRTP crypto suite, the offerer has to perform 1842 Diffie-Hellman operation, and a public key operation to sign 1843 the Diffie-Hellman output. 1845 MIKEY-DHHMAC 1846 For each offered SRTP crypto suite, the offerer has to perform 1847 Diffie-Hellman operation. 1849 MIKEYv2 in SDP 1850 The behavior will depend on which mode is picked. 1852 Security Descriptions with SIPS 1853 No significant computational expense. 1855 Security Descriptions with S/MIME 1856 S/MIME requires the offerer and the answerer to encrypt the SDP 1857 with the other's public key, and to decrypt the received SDP 1858 with their own private key. 1860 SDP-DH 1861 For each offered SRTP crypto suite, the offerer has to perform 1862 a Diffie-Hellman operation. 1864 ZRTP 1865 The offerer has no additional computational expense at all, as 1866 the offer contains no information about ZRTP or might contain 1867 "a=zrtp". 1869 EKT 1870 The offerer's Computational expense depends entirely on the EKT 1871 bootstrapping mechanism selected (one or more MIKEY modes or 1872 Security Descriptions). 1874 DTLS-SRTP 1875 The offerer has no additional computational expense at all, as 1876 the offer contains only a fingerprint of the certificate that 1877 will be presented in the DTLS exchange. 1879 MIKEYv2 Inband 1880 The behavior will depend on which mode is picked. 1882 Appendix D. Out-of-Scope 1884 Discussions concluded that key management for shared-key encryption 1885 of conferencing is outside the scope of this document. As the 1886 priority is point-to-point unicast SRTP session keying, resolving 1887 shared-key SRTP session keying is deferred to later and left as an 1888 item for future investigations. 1890 Authors' Addresses 1892 Dan Wing (editor) 1893 Cisco Systems, Inc. 1894 170 West Tasman Drive 1895 San Jose, CA 95134 1896 USA 1898 Email: dwing@cisco.com 1900 Steffen Fries 1901 Siemens AG 1902 Otto-Hahn-Ring 6 1903 Munich, Bavaria 81739 1904 Germany 1906 Email: steffen.fries@siemens.com 1907 Hannes Tschofenig 1908 Nokia Siemens Networks 1909 Otto-Hahn-Ring 6 1910 Munich, Bavaria 81739 1911 Germany 1913 Email: Hannes.Tschofenig@nsn.com 1914 URI: http://www.tschofenig.com 1916 Francois Audet 1917 Nortel 1918 4655 Great America Parkway 1919 Santa Clara, CA 95054 1920 USA 1922 Email: audet@nortel.com 1924 Full Copyright Statement 1926 Copyright (C) The IETF Trust (2007). 1928 This document is subject to the rights, licenses and restrictions 1929 contained in BCP 78, and except as set forth therein, the authors 1930 retain all their rights. 1932 This document and the information contained herein are provided on an 1933 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1934 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1935 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1936 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1937 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1938 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1940 Intellectual Property 1942 The IETF takes no position regarding the validity or scope of any 1943 Intellectual Property Rights or other rights that might be claimed to 1944 pertain to the implementation or use of the technology described in 1945 this document or the extent to which any license under such rights 1946 might or might not be available; nor does it represent that it has 1947 made any independent effort to identify any such rights. Information 1948 on the procedures with respect to rights in RFC documents can be 1949 found in BCP 78 and BCP 79. 1951 Copies of IPR disclosures made to the IETF Secretariat and any 1952 assurances of licenses to be made available, or the result of an 1953 attempt made to obtain a general license or permission for the use of 1954 such proprietary rights by implementers or users of this 1955 specification can be obtained from the IETF on-line IPR repository at 1956 http://www.ietf.org/ipr. 1958 The IETF invites any interested party to bring to its attention any 1959 copyrights, patents or patent applications, or other proprietary 1960 rights that may cover technology that may be required to implement 1961 this standard. Please address the information to the IETF at 1962 ietf-ipr@ietf.org. 1964 Acknowledgment 1966 Funding for the RFC Editor function is provided by the IETF 1967 Administrative Support Activity (IASA).