idnits 2.17.1 draft-ietf-avtcore-rtp-security-options-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (January 15, 2014) is 3753 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-avt-srtp-not-mandatory-14 == Outdated reference: A later version (-11) exists of draft-ietf-avtcore-aria-srtp-06 == Outdated reference: A later version (-17) exists of draft-ietf-avtcore-srtp-aes-gcm-10 == Outdated reference: A later version (-03) exists of draft-ietf-avtcore-srtp-ekt-01 == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-38 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-08 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-07 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Westerlund 3 Internet-Draft Ericsson 4 Intended status: Informational C. Perkins 5 Expires: July 19, 2014 University of Glasgow 6 January 15, 2014 8 Options for Securing RTP Sessions 9 draft-ietf-avtcore-rtp-security-options-10 11 Abstract 13 The Real-time Transport Protocol (RTP) is used in a large number of 14 different application domains and environments. This heterogeneity 15 implies that different security mechanisms are needed to provide 16 services such as confidentiality, integrity and source authentication 17 of RTP/RTCP packets suitable for the various environments. The range 18 of solutions makes it difficult for RTP-based application developers 19 to pick the most suitable mechanism. This document provides an 20 overview of a number of security solutions for RTP, and gives 21 guidance for developers on how to choose the appropriate security 22 mechanism. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 19, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Point-to-Point Sessions . . . . . . . . . . . . . . . . . 4 61 2.2. Sessions Using an RTP Mixer . . . . . . . . . . . . . . . 4 62 2.3. Sessions Using an RTP Translator . . . . . . . . . . . . 5 63 2.3.1. Transport Translator (Relay) . . . . . . . . . . . . 5 64 2.3.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 7 66 2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 7 67 2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 7 68 3. Security Options . . . . . . . . . . . . . . . . . . . . . . 9 69 3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.1.1. Key Management for SRTP: DTLS-SRTP . . . . . . . . . 11 71 3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . 13 72 3.1.3. Key Management for SRTP: Security Descriptions . . . 14 73 3.1.4. Key Management for SRTP: Encrypted Key Transport . . 15 74 3.1.5. Key Management for SRTP: ZRTP and Other Solutions . . 15 75 3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 16 76 3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 3.4. RTP over TLS over TCP . . . . . . . . . . . . . . . . . . 16 78 3.5. RTP over Datagram TLS (DTLS) . . . . . . . . . . . . . . 17 79 3.6. Media Content Security/Digital Rights Management . . . . 17 80 3.6.1. ISMA Encryption and Authentication . . . . . . . . . 18 81 4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 18 82 4.1. Application Requirements . . . . . . . . . . . . . . . . 19 83 4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 19 84 4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 20 85 4.1.3. Source Authentication . . . . . . . . . . . . . . . . 20 86 4.1.4. Identifiers and Identity . . . . . . . . . . . . . . 22 87 4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 23 88 4.2. Application Structure . . . . . . . . . . . . . . . . . . 23 89 4.3. Automatic Key Management . . . . . . . . . . . . . . . . 24 90 4.4. End-to-End Security vs Tunnels . . . . . . . . . . . . . 24 91 4.5. Plain Text Keys . . . . . . . . . . . . . . . . . . . . . 24 92 4.6. Interoperability . . . . . . . . . . . . . . . . . . . . 25 93 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25 94 5.1. Media Security for SIP-established Sessions using DTLS- 95 SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . 25 96 5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 26 97 5.3. IP Multimedia Subsystem (IMS) Media Security . . . . . . 27 98 5.4. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 28 99 5.5. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 29 100 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 102 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 103 9. Informative References . . . . . . . . . . . . . . . . . . . 30 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 106 1. Introduction 108 Real-time Transport Protocol (RTP) [RFC3550] is widely used in a 109 large variety of multimedia applications, including Voice over IP 110 (VoIP), centralized multimedia conferencing, sensor data transport, 111 and Internet television (IPTV) services. These applications can 112 range from point-to-point phone calls, through centralised group 113 teleconferences, to large-scale television distribution services. 114 The types of media can vary significantly, as can the signalling 115 methods used to establish the RTP sessions. 117 This multi-dimensional heterogeneity has so far prevented development 118 of a single security solution that meets the needs of the different 119 applications. Instead significant number of different solutions have 120 been developed to meet different sets of security goals. This makes 121 it difficult for application developers to know what solutions exist, 122 and whether their properties are appropriate. This memo gives an 123 overview of the available RTP solutions, and provides guidance on 124 their applicability for different application domains. It also 125 attempts to provide indication of actual and intended usage at time 126 of writing as additional input to help with considerations such as 127 interoperability, availability of implementations etc. The guidance 128 provided is not exhaustive, and this memo does not provide normative 129 recommendations. 131 It is important that application developers consider the security 132 goals and requirements for their application. The IETF considers it 133 important that protocols implement secure modes of operation and 134 makes them available to users [RFC3365]. Because of the 135 heterogeneity of RTP applications and use cases, however, a single 136 security solution cannot be mandated 137 [I-D.ietf-avt-srtp-not-mandatory]. Instead, application developers 138 need to select mechanisms that provide appropriate security for their 139 environment. It is strongly encouraged that common mechanisms are 140 used by related applications in common environments. The IETF 141 publishes guidelines for specific classes of applications, so it is 142 worth searching for such guidelines. 144 The remainder of this document is structured as follows. Section 2 145 provides additional background. Section 3 outlines the available 146 security mechanisms at the time of this writing, and lists their key 147 security properties and constraints. That is followed by guidelines 148 and important aspects to consider when securing an RTP application in 149 Section 4. Finally, we give some examples of application domains 150 where guidelines for security exist in Section 5. 152 2. Background 154 RTP can be used in a wide variety of topologies due to its support 155 for point-to-point sessions, multicast groups, and other topologies 156 built around different types of RTP middleboxes. In the following we 157 review the different topologies supported by RTP to understand their 158 implications for the security properties and trust relations that can 159 exist in RTP sessions. 161 2.1. Point-to-Point Sessions 163 The most basic use case is two directly connected end-points, shown 164 in Figure 1, where A has established an RTP session with B. In this 165 case the RTP security is primarily about ensuring that any third 166 party can't compromise the confidentiality and integrity of the media 167 communication. This requires confidentiality protection of the RTP 168 session, integrity protection of the RTP/RTCP packets, and source 169 authentication of all the packets to ensure no man-in-the-middle 170 attack is taking place. 172 The source authentication can also be tied to a user or an end- 173 point's verifiable identity to ensure that the peer knows who they 174 are communicating with. Here the combination of the security 175 protocol protecting the RTP session (and hence the RTP and RTCP 176 traffic) and the key-management protocol becomes important to 177 determine what security claims can be made. 179 +---+ +---+ 180 | A |<------->| B | 181 +---+ +---+ 183 Figure 1: Point-to-point topology 185 2.2. Sessions Using an RTP Mixer 187 An RTP mixer is an RTP session-level middlebox that one can build a 188 multi-party RTP based conference around. The RTP mixer might 189 actually perform media mixing, like mixing audio or compositing video 190 images into a new media stream being sent from the mixer to a given 191 participant; or it might provide a conceptual stream, for example the 192 video of the current active speaker. From a security point of view, 193 the important features of an RTP mixer is that it generates a new 194 media stream, and has its own source identifier, and does not simply 195 forward the original media. 197 An RTP session using a mixer might have a topology like that in 198 Figure 2. In this example, participants A through D each send 199 unicast RTP traffic to the RTP mixer, and receive an RTP stream from 200 the mixer, comprising a mixture of the streams from the other 201 participants. 203 +---+ +------------+ +---+ 204 | A |<---->| |<---->| B | 205 +---+ | | +---+ 206 | Mixer | 207 +---+ | | +---+ 208 | C |<---->| |<---->| D | 209 +---+ +------------+ +---+ 211 Figure 2: Example RTP mixer Topology 213 A consequence of an RTP mixer having its own source identifier, and 214 acting as an active participant towards the other end-points is that 215 the RTP mixer needs to be a trusted device that has access to the 216 security context(s) established. The RTP mixer can also become a 217 security enforcing entity. For example, a common approach to secure 218 the topology in Figure 2 is to establish a security context between 219 the mixer and each participant independently, and have the mixer 220 source authenticate each peer. The mixer then ensures that one 221 participant cannot impersonate another. 223 2.3. Sessions Using an RTP Translator 225 RTP translators are middleboxes that provide various levels of in- 226 network media translation and transcoding. Their security properties 227 vary widely, depending on which type of operations they attempt to 228 perform. We identify three different categories of RTP translator: 229 transport translators, gateways, and media transcoders. We discuss 230 each in turn. 232 2.3.1. Transport Translator (Relay) 234 A transport translator [RFC5117] operates on a level below RTP and 235 RTCP. It relays the RTP/RTCP traffic from one end-point to one or 236 more other addresses. This can be done based only on IP addresses 237 and transport protocol ports, with each receive port on the 238 translator can have a very basic list of where to forward traffic. 239 Transport translators also need to implement ingress filtering to 240 prevent random traffic from being forwarded that isn't coming from a 241 participant in the conference. 243 Figure 3 shows an example transport translator, where traffic from 244 any one of the four participants will be forwarded to the other three 245 participants unchanged. The resulting topology is very similar to 246 Any Source Multicast (ASM) session (as discussed in Section 2.4), but 247 implemented at the application layer. 249 +---+ +------------+ +---+ 250 | A |<---->| |<---->| B | 251 +---+ | Relay | +---+ 252 | Translator | 253 +---+ | | +---+ 254 | C |<---->| |<---->| D | 255 +---+ +------------+ +---+ 257 Figure 3: RTP relay translator topology 259 A transport translator can often operate without needing access to 260 the security context, as long as the security mechanism does not 261 provide protection over the transport-layer information. A transport 262 translator does, however, make the group communication visible, and 263 so can complicate keying and source authentication mechanisms. This 264 is further discussed in Section 2.4. 266 2.3.2. Gateway 268 Gateways are deployed when the endpoints are not fully compatible. 269 Figure 4 shows an example topology. The functions a gateway provides 270 can be diverse, and range from transport layer relaying between two 271 domains not allowing direct communication, via transport or media 272 protocol function initiation or termination, to protocol or media 273 encoding translation. The supported security protocol might even be 274 one of the reasons a gateway is needed. 276 +---+ +-----------+ +---+ 277 | A |<---->| Gateway |<---->| B | 278 +---+ +-----------+ +---+ 280 Figure 4: RTP gateway topology 282 The choice of security protocol, and the details of the gateway 283 function, will determine if the gateway needs to be trusted with 284 access to the application security context. Many gateways need to be 285 trusted by all peers to perform the translation; in other cases some 286 or all peers might not be aware of the presence of the gateway. The 287 security protocols have different properties depending on the degree 288 of trust and visibility needed. Ensuring communication is possible 289 without trusting the gateway can be strong incentive for accepting 290 different security properties. Some security solutions will be able 291 to detect the gateways as manipulating the media stream, unless the 292 gateway is a trusted device. 294 2.3.3. Media Transcoder 296 A Media transcoder is a special type of gateway device that changes 297 the encoding of the media being transported by RTP. The discussion 298 in Section 2.3.2 applies. A media transcoder alters the media data, 299 and thus needs to be trusted with access to the security context. 301 2.4. Any Source Multicast 303 Any Source Multicast [RFC1112] is the original multicast model where 304 any multicast group participant can send to the multicast group, and 305 get their packets delivered to all group members (see Figure 5). 306 This form of communication has interesting security properties, due 307 to the many-to-many nature of the group. Source authentication is 308 important, but all participants with access to group security context 309 will have the necessary secrets to decrypt and verify integrity of 310 the traffic. Thus use of any group security context fails if the 311 goal is to separate individual sources; alternate solutions are 312 needed. 314 +-----+ 315 +---+ / \ +---+ 316 | A |----/ \---| B | 317 +---+ / Multi- \ +---+ 318 + Cast + 319 +---+ \ Network / +---+ 320 | C |----\ /---| D | 321 +---+ \ / +---+ 322 +-----+ 324 Figure 5: Any source multicast (ASM) group 326 In addition the potential large size of multicast groups creates some 327 considerations for the scalability of the solution and how the key- 328 management is handled. 330 2.5. Source-Specific Multicast 332 Source-Specific Multicast [RFC4607] allows only a specific end-point 333 to send traffic to the multicast group, irrespective of the number of 334 RTP media sources. The end-point is known as the media Distribution 335 Source. For RTP session to function correctly with RTCP over an SSM 336 session extensions have been defined in [RFC5760]. Figure 6 shows a 337 sample SSM-based RTP session where several media sources, MS1...MSm, 338 all send media to a Distribution Source, which then forwards the 339 media data to the SSM group for delivery to the receivers, R1...Rn, 340 and the Feedback Targets, FT1...FTn. RTCP reception quality feedback 341 is sent unicast from each receiver to one of the Feedback Targets. 342 The feedback targets aggregate reception quality feedback and forward 343 it upstream towards the distribution source. The distribution source 344 forwards (possibly aggregated and summarised) reception feedback to 345 the SSM group, and back to the original media sources. The feedback 346 targets are also members of the SSM group and receive the media data, 347 so they can send unicast repair data to the receivers in response to 348 feedback if appropriate. 350 +-----+ +-----+ +-----+ 351 | MS1 | | MS2 | .... | MSm | 352 +-----+ +-----+ +-----+ 353 ^ ^ ^ 354 | | | 355 V V V 356 +---------------------------------+ 357 | Distribution Source | 358 +--------+ | 359 | FT Agg | | 360 +--------+------------------------+ 361 ^ ^ | 362 : . | 363 : +...................+ 364 : | . 365 : / \ . 366 +------+ / \ +-----+ 367 | FT1 |<----+ +----->| FT2 | 368 +------+ / \ +-----+ 369 ^ ^ / \ ^ ^ 370 : : / \ : : 371 : : / \ : : 372 : : / \ : : 373 : ./\ /\. : 374 : /. \ / .\ : 375 : V . V V . V : 376 +----+ +----+ +----+ +----+ 377 | R1 | | R2 | ... |Rn-1| | Rn | 378 +----+ +----+ +----+ +----+ 380 Figure 6: Example SSM-based RTP session with two feedback targets 382 The use of SSM makes it more difficult to inject traffic into the 383 multicast group, but not impossible. Source authentication 384 requirements apply for SSM sessions too, and an individual 385 verification of who sent the RTP and RTCP packets is needed. An RTP 386 session using SSM will have a group security context that includes 387 the media sources, distribution source, feedback targets, and the 388 receivers. Each has a different role and will be trusted to perform 389 different actions. For example, the distribution source will need to 390 authenticate the media sources to prevent unwanted traffic being 391 distributed via the SSM group. Similarly, the receivers need to 392 authenticate both the distribution source and their feedback target, 393 to prevent injection attacks from malicious devices claiming to be 394 feedback targets. An understanding of the trust relationships and 395 group security context is needed between all components of the 396 system. 398 3. Security Options 400 This section provides an overview of security requirements, and the 401 current RTP security mechanisms that implement those requirements. 402 This cannot be a complete survey, since new security mechanisms are 403 defined regularly. The goal is to help applications designer by 404 reviewing the types of solution that are available. This section 405 will use a number of different security related terms, described in 406 the Internet Security Glossary, Version 2 [RFC4949]. 408 3.1. Secure RTP 410 The Secure RTP (SRTP) protocol [RFC3711] is one of the most commonly 411 used mechanisms to provide confidentiality, integrity protection, 412 source authentication and replay protection for RTP. SRTP was 413 developed with RTP header compression and third party monitors in 414 mind. Thus the RTP header is not encrypted in RTP data packets, and 415 the first 8 bytes of the first RTCP packet header in each compound 416 RTCP packet are not encrypted. The entirety of RTP packets and 417 compound RTCP packets are integrity protected. This allows RTP 418 header compression to work, and lets third party monitors determine 419 what RTP traffic flows exist based on the SSRC fields, but protects 420 the sensitive content. 422 SRTP works with transforms where different combinations of encryption 423 algorithm, authentication algorithm, and pseudo-random function can 424 be used, and the authentication tag length can be set to any value. 425 SRTP can also be easily extended with additional cryptographic 426 transforms. This gives flexibility, but requires more security 427 knowledge by the application developer. To simplify things, SDP 428 Security Descriptions (see Section 3.1.3) and DTLS-SRTP (see 429 Section 3.1.1) use pre-defined combinations of transforms, known as 430 SRTP crypto suites and SRTP protection profiles, that bundle together 431 transforms and other parameters, making them easier to use but 432 reducing flexibility. The MIKEY protocol (see Section 3.1.2) 433 provides flexibility to negotiate the full selection of transforms. 434 At the time of this writing, the following transforms, SRTP crypto 435 suites, and SRTP protection profiles are defined or under definition: 437 AES-CM and HMAC-SHA-1: AES Counter Mode encryption with 128-bit keys 438 combined with 160-bit keyed HMAC-SHA-1 with 80-bit authentication 439 tag. This is the default cryptographic transform that needs to be 440 supported. The transforms are defined in SRTP [RFC3711], with the 441 corresponding SRTP crypto suite in [RFC4568] and SRTP protection 442 profile in [RFC5764]. 444 AES-f8 and HMAC-SHA-1: AES f8 mode encryption using 128-bit keys 445 combined with keyed HMAC-SHA-1 using 80-bit authentication. The 446 transforms are defined in [RFC3711], with the corresponding SRTP 447 crypto suite in [RFC4568]. The corresponding SRTP protection 448 profile is not defined. 450 SEED: A Korean national standard cryptographic transform that is 451 defined to be used with SRTP in [RFC5669]. Three options are 452 defined, one using SHA-1 authentication, one using Counter mode 453 with CBC-MAC, and finally one using Galois Counter mode. 455 ARIA: A Korean block cipher [I-D.ietf-avtcore-aria-srtp], that 456 supports 128-, 192- and 256- bit keys. It also defines three 457 options, Counter mode where combined with HMAC-SHA-1 with 80 or 32 458 bits authentication tags, Counter mode with CBC-MAC and Galois 459 Counter mode. It also defines a different key derivation function 460 than the AES based systems. 462 AES-192-CM and AES-256-CM: Cryptographic transforms for SRTP based 463 on AES-192 and AES-256 counter mode encryption and 160-bit keyed 464 HMAC-SHA-1 with 80- and 32-bit authentication tags. These provide 465 192- and 256-bit encryption keys, but otherwise match the default 466 128-bit AES-CM transform. The transforms are defined in [RFC3711] 467 and [RFC6188], with the SRTP crypto suites in [RFC6188]. 469 AES-GCM and AES-CCM: AES Galois Counter Mode and AES Counter with 470 CBC MAC for AES-128 and AES-256. This authentication is included 471 in the cipher text which becomes expanded with the length of the 472 authentication tag instead of using the SRTP authentication tag. 473 This is defined in [I-D.ietf-avtcore-srtp-aes-gcm]. 475 NULL: SRTP [RFC3711] also provides a NULL cipher that can be used 476 when no confidentiality for RTP/RTCP is requested. The 477 corresponding SRTP protection profile is defined in [RFC5764]. 479 The source authentication guarantees provided by SRTP depend on the 480 cryptographic transform and key-management used. Some transforms 481 give strong source authentication even in multiparty sessions; others 482 give weaker guarantees and can authenticate group membership but not 483 sources. TESLA [RFC4383] offers a complement to the regular 484 symmetric keyed authentication transforms, like HMAC-SHA-1, and can 485 provide per-source authentication in some group communication 486 scenarios. The downside is need for buffering the packets for a 487 while before authenticity can be verified. 489 [RFC4771] defines a variant of the authentication tag that enables a 490 receiver to obtain the Roll over Counter for the RTP sequence number 491 that is part of the Initialization vector (IV) for many cryptographic 492 transforms. This enables quicker and easier options for joining a 493 long lived secure RTP group, for example a broadcast session. 495 RTP header extensions are normally carried in the clear and only 496 integrity protected in SRTP. This can be problematic in some cases, 497 so [RFC6904] defines an extension to also encrypt selected header 498 extensions. 500 SRTP is specified and deployed in a number of RTP usage contexts; 501 Significant support in SIP-established VoIP clients including IMS; 502 RTSP [I-D.ietf-mmusic-rfc2326bis] and RTP based media streaming. 503 Thus SRTP in general is widely deployed. When it comes to 504 cryptographic transforms the default (AES-CM and HMAC-SHA-1) is the 505 most commonly used, but it might be expected that AES-GCM, 506 AES-192-CM, and AES-256-CM will gain usage in future, especially due 507 to the AES- and GCM-specific instructions in new CPUs. 509 SRTP does not contain an integrated key-management solution, and 510 instead relies on an external key management protocol. There are 511 several protocols that can be used. The following sections outline 512 some popular schemes. 514 3.1.1. Key Management for SRTP: DTLS-SRTP 516 A Datagram Transport Layer Security extension exists for establishing 517 SRTP keys [RFC5763][RFC5764]. This extension provides secure key- 518 exchange between two peers, enabling Perfect Forward Secrecy (PFS) 519 and binding strong identity verification to an end-point. Perfect 520 Forward Secrecy is a property of the key-agreement protocol that 521 ensures that a session key derived from a set of long-term keys will 522 not be compromised if one of the long-term keys is compromised in the 523 future. The default key generation will generate a key that contains 524 material contributed by both peers. The key-exchange happens in the 525 media plane directly between the peers. The common key-exchange 526 procedures will take two round trips assuming no losses. TLS 527 resumption can be used when establishing additional media streams 528 with the same peer, and reduces the set-up time to one RTT for these 529 streams (see [RFC5764] for a discussion of TLS resumption in this 530 context). 532 The actual security properties of an established SRTP session using 533 DTLS will depend on the cipher suites offered and used, as well as 534 the mechanism for identifying the end-points of the hand-shake. For 535 example some cipher suits provide PFS , while other do not. When 536 using DTLS, the application designer needs to select which cipher 537 suites DTLS-SRTP can offer and accept so that the desired security 538 properties are achieved. The next choice is how to verify the 539 identity of the peer end-point. One choice can be to rely on the 540 certificates and use a PKI to verify them to make an identity 541 assertion. However, this is not the most common way, instead self- 542 signed certificate are common to use, and instead establish trust 543 through signalling or other third party solutions. 545 DTLS-SRTP key management can use the signalling protocol in four 546 ways. First, to agree on using DTLS-SRTP for media security. 547 Secondly, to determine the network location (address and port) where 548 each side is running a DTLS listener to let the parts perform the 549 key-management handshakes that generate the keys used by SRTP. 550 Thirdly, to exchange hashes of each side's certificates to bind these 551 to the signalling, and ensure there is no man-in-the-middle attack. 552 This assumes that one can trust the signalling solution to be 553 resistant to modification, and not be in collaboration with an 554 attacker. Finally to provide an assertable identity, e.g. [RFC4474] 555 that can be used to prevent modification of the signalling and the 556 exchange of certificate hashes. That way enabling binding between 557 the key-exchange and the signalling. 559 This usage is well defined for SIP/SDP in [RFC5763], and in most 560 cases can be adopted for use with other bi-directional signalling 561 solutions. It is to be noted that there is work underway to revisit 562 the SIP Identity mechanism [RFC4474] in the IETF STIR working group. 564 The main question regarding DTLS-SRTP's security properties is how 565 one verifies any peer identity or at least prevents man-in-the-middle 566 attacks. This do requires trust in some DTLS-SRTP external party, 567 either a PKI, a signalling system or some identity provider. 569 DTLS-SRTP usage is clearly on the rise. It is mandatory to support 570 in WebRTC. It has growing support among SIP end-points. DTLS-SRTP 571 was developed in IETF primarily to meet security requirements for RTP 572 based media established using SIP. The requirements considered can 573 be reviewed in "Requirements and Analysis of Media Security 574 Management Protocols." [RFC5479]. 576 3.1.2. Key Management for SRTP: MIKEY 578 Multimedia Internet Keying (MIKEY) [RFC3830] is a keying protocol 579 that has several modes with different properties. MIKEY can be used 580 in point-to-point applications using SIP and RTSP (e.g., VoIP calls), 581 but is also suitable for use in broadcast and multicast applications, 582 and centralized group communications. 584 MIKEY can establish multiple security contexts or cryptographic 585 sessions with a single message. It is useable in scenarios where one 586 entity generates the key and needs to distribute the key to a number 587 of participants. The different modes and the resulting properties 588 are highly dependent on the cryptographic method used to establish 589 the session keys actually used by the security protocol, like SRTP. 591 MIKEY has the following modes of operation: 593 Pre-Shared Key: Uses a pre-shared secret for symmetric key crypto 594 used to secure a keying message carrying the already generated 595 session key. This system is the most efficient from the 596 perspective of having small messages and processing demands. The 597 downside is scalability, where usually the effort for the 598 provisioning of pre-shared keys is only manageable if the number 599 of endpoints is small. 601 Public Key encryption: Uses a public key crypto to secure a keying 602 message carrying the already-generated session key. This is more 603 resource intensive but enables scalable systems. It does require 604 a public key infrastructure to enable verification. 606 Diffie-Hellman: Uses Diffie-Hellman key-agreement to generate the 607 session key, thus providing perfect forward secrecy. The downside 608 is high resource consumption in bandwidth and processing during 609 the MIKEY exchange. This method can't be used to establish group 610 keys as each pair of peers performing the MIKEY exchange will 611 establish different keys. 613 HMAC-Authenticated Diffie-Hellman: [RFC4650] defines a variant of 614 the Diffie-Hellman exchange that uses a pre-shared key in a keyed 615 HMAC to verify authenticity of the keying material instead of a 616 digital signature as in the previous method. This method is still 617 restricted to point-to-point usage. 619 RSA-R: MIKEY-RSA in Reverse mode [RFC4738] is a variant of the 620 public key method which doesn't rely on the initiator of the key- 621 exchange knowing the responder's certificate. This method lets 622 both the initiator and the responder to specify the session keying 623 material depending on use case. Usage of this mode requires one 624 round-trip time. 626 TICKET: [RFC6043] is a MIKEY extension using a trusted centralized 627 key management service (KMS). The Initiator and Responder do not 628 share any credentials; instead, they trust a third party, the KMS, 629 with which they both have or can establish shared credentials. 631 IBAKE: [RFC6267] uses a key management services (KMS) infrastructure 632 but with lower demand on the KMS. Claims to provides both perfect 633 forward and backwards secrecy. 635 SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption in MIKEY. 636 Based on Identity based Public Key Cryptography and a KMS 637 infrastructure to establish a shared secret value and certificate 638 less signatures to provide source authentication. Its features 639 include simplex transmission, scalability, low-latency call set- 640 up, and support for secure deferred delivery. 642 MIKEY messages have several different transports. [RFC4567] defines 643 how MIKEY messages can be embedded in general SDP for usage with the 644 signalling protocols SIP, SAP and RTSP. There also exist a 3GPP 645 defined usage of MIKEY that sends MIKEY messages directly over UDP 646 [T3GPP.33.246] to key the receivers of Multimedia Broadcast and 647 Multicast Service (MBMS) [T3GPP.26.346]. [RFC3830] defines the 648 application/mikey media type allowing MIKEY to be used in, e.g., 649 email and HTTP. 651 Based on the many choices it is important to consider the properties 652 needed in ones solution and based on that evaluate which modes that 653 are candidates for ones usage. More information on the applicability 654 of the different MIKEY modes can be found in [RFC5197]. 656 MIKEY with pre-shared keys are used by 3GPP MBMS [T3GPP.33.246] and 657 IMS media security [T3GPP.33.328] specifies the use of the TICKET 658 mode transported over SIP and HTTP. RTSP 2.0 659 [I-D.ietf-mmusic-rfc2326bis] specifies use of the RSA-R mode. There 660 are some SIP end-points that support MIKEY. The modes they use are 661 unknown to the authors. 663 3.1.3. Key Management for SRTP: Security Descriptions 665 [RFC4568] provides a keying solution based on sending plain text keys 666 in SDP [RFC4566]. It is primarily used with SIP and the SDP Offer/ 667 Answer model, and is well-defined in point-to-point sessions where 668 each side declares its own unique key. Using Security Descriptions 669 to establish group keys is less well defined, and can have security 670 issues since it's difficult to guarantee unique SSRCs (as needed to 671 avoid a "two-time pad" attack - see Section 9 of [RFC3711]). 673 Since keys are transported in plain text in SDP, they can easily be 674 intercepted unless the SDP carrying protocol provides strong end-to- 675 end confidentiality and authentication guarantees. This is not 676 normally the case, where instead hop-by-hop security is provided 677 between signalling nodes using TLS. This leaves the keying material 678 sensitive to capture by the traversed signalling nodes. Thus, in 679 most cases, the security properties of security descriptions are 680 weak. The usage of security descriptions usually requires additional 681 security measures, e.g. the signalling nodes be trusted and protected 682 by strict access control. Usage of security descriptions requires 683 careful design in order to ensure that the security goals can be met. 685 Security Descriptions is the most commonly deployed keying solution 686 for SIP-based end-points, where almost all end-points that support 687 SRTP also support Security Descriptions. It is also used for access 688 protection in IMS Media Security [T3GPP.33.328]. 690 3.1.4. Key Management for SRTP: Encrypted Key Transport 692 Encrypted Key Transport (EKT) [I-D.ietf-avtcore-srtp-ekt] is an SRTP 693 extension that enables group keying despite using a keying mechanism 694 like DTLS-SRTP that doesn't support group keys. It is designed for 695 centralized conferencing, but can also be used in sessions where end- 696 points connect to a conference bridge or a gateway, and need to be 697 provisioned with the keys each participant on the bridge or gateway 698 uses to avoid decryption and encryption cycles on the bridge or 699 gateway. This can enable interworking between DTLS-SRTP and other 700 keying systems where either party can set the key (e.g., interworking 701 with security descriptions). 703 The mechanism is based on establishing an additional EKT key which 704 everyone uses to protect their actual session key. The actual 705 session key is sent in a expanded authentication tag to the other 706 session participants. This key is only sent occasionally or 707 periodically depending on use cases and depending on what 708 requirements exist for timely delivery or notification. 710 The only known deployment of EKT so far are in some Cisco video 711 conferencing products. 713 3.1.5. Key Management for SRTP: ZRTP and Other Solutions 715 The ZRTP [RFC6189] key-management system for SRTP was proposed as an 716 alternative to DTLS-SRTP. ZRTP provides best effort encryption 717 independent of the signalling protocol and utilizes key continuity, 718 Short Authentication Strings, or a PKI for authentication. ZRTP 719 wasn't adopted as an IETF standards track protocol, but was instead 720 published as an informational RFC. Commercial implementations exist. 722 Additional proprietary solutions are also known to exist. 724 3.2. RTP Legacy Confidentiality 726 Section 9 of the RTP standard [RFC3550] defines a DES or 3DES based 727 encryption of RTP and RTCP packets. This mechanism is keyed using 728 plain text keys in SDP [RFC4566] using the "k=" SDP field. This 729 method can provide confidentiality but, as discussed in Section 9 of 730 [RFC3550], it has extremely weak security properties and is not to be 731 used. 733 3.3. IPsec 735 IPsec [RFC4301] can be used in either tunnel or transport mode to 736 protect RTP and RTCP packets in transit from one network interface to 737 another. This can be sufficient when the network interfaces have a 738 direct relation, or in a secured environment where it can be 739 controlled who can read the packets from those interfaces. 741 The main concern with using IPsec to protect RTP traffic is that in 742 most cases using a VPN approach that terminates the security 743 association at some node prior to the RTP end-point leaves the 744 traffic vulnerable to attack between the VPN termination node and the 745 end-point. Thus usage of IPsec requires careful thought and design 746 of its usage so that it meets the security goals. A important 747 question is how one ensures the IPsec terminating peer and the 748 ultimate destination are the same. Applications can have issues 749 using existing APIs with determining if IPsec is being used or not, 750 and when used who the authenticated peer entity is. 752 IPsec with RTP is more commonly used as a security solution between 753 infrastructure nodes that exchange many RTP sessions and media 754 streams. The establishment of a secure tunnel between such nodes 755 minimizes the key-management overhead. 757 3.4. RTP over TLS over TCP 759 Just as RTP can be sent over TCP [RFC4571], it can also be sent over 760 TLS over TCP [RFC4572], using TLS to provide point-to-point security 761 services. The security properties TLS provides are confidentiality, 762 integrity protection and possible source authentication if the client 763 or server certificates are verified and provide a usable identity. 764 When used in multi-party scenarios using a central node for media 765 distribution, the security provide is only between the central node 766 and the peers, so the security properties for the whole session are 767 dependent on what trust one can place in the central node. 769 RTSP 1.0 [RFC2326] and 2.0 [I-D.ietf-mmusic-rfc2326bis] specifies the 770 usage of RTP over the same TLS/TCP connection that the RTSP messages 771 are sent over. It appears that RTP over TLS/TCP is also used in some 772 proprietary solutions that uses TLS to bypass firewalls. 774 3.5. RTP over Datagram TLS (DTLS) 776 Datagram Transport Layer Security (DTLS) [RFC6347] is a based on TLS 777 [RFC5246], but designed to work over a unreliable datagram oriented 778 transport rather than requiring reliable byte stream semantics from 779 the transport protocol. Accordingly, DTLS can provide point-to-point 780 security for RTP flows analogous to that provided by TLS, but over an 781 datagram transport such as UDP. The two peers establish an DTLS 782 association between each other, including the possibility to do 783 certificate-based source authentication when establishing the 784 association. All RTP and RTCP packets flowing will be protected by 785 this DTLS association. 787 Note that using DTLS for RTP flows is different to using DTLS-SRTP 788 key management. DTLS-SRTP uses the same key-management steps as 789 DTLS, but uses SRTP for the per packet security operations. Using 790 DTLS for RTP flows uses the normal datagram TLS data protection, 791 wrapping complete RTP packets. When using DTLS for RTP flows, the 792 RTP and RTCP packets are completely encrypted with no headers in the 793 clear; when using DTLS-SRTP, the RTP headers are in the clear and 794 only the payload data is encrypted. 796 DTLS can use similar techniques to those available for DTLS-SRTP to 797 bind a signalling-side agreement to communicate to the certificates 798 used by the end-point when doing the DTLS handshake. This enables 799 use without having a certificate-based trust chain to a trusted 800 certificate root. 802 There does not appear to be significant usage of DTLS for RTP. 804 3.6. Media Content Security/Digital Rights Management 806 Mechanisms have been defined that encrypt only the media content, 807 operating within the RTP payload data and leaving the RTP headers and 808 RTCP unaffected. There are several reasons why this might be 809 appropriate, but a common rationale is to ensure that the content 810 stored by RTSP streaming servers has the media content in a protected 811 format that cannot be read by the streaming server (this is mostly 812 done in the context of Digital Rights Management). These approaches 813 then use a key-management solution between the rights provider and 814 the consuming client to deliver the key used to protect the content 815 and do not give the media server access to the security context. 816 Such methods have several security weaknesses such as the fact that 817 the same key is handed out to a potentially large group of receiving 818 clients, increasing the risk of a leak. 820 Use of this type of solution can be of interest in environments that 821 allow middleboxes to rewrite the RTP headers and select which streams 822 are delivered to an end-point (e.g., some types of centralised video 823 conference systems). The advantage of encrypting and possibly 824 integrity protecting the payload but not the headers is that the 825 middlebox can't eavesdrop on the media content, but can still provide 826 stream switching functionality. The downside of such a system is 827 that it likely needs two levels of security: the payload level 828 solution to provide confidentiality and source authentication, and a 829 second layer with additional transport security ensuring source 830 authentication and integrity of the RTP headers associated with the 831 encrypted payloads. This can also results in the need to have two 832 different key-management systems as the entity protecting the packets 833 and payloads are different with different set of keys. 835 The aspect of two tiers of security are present in ISMACryp (see 836 Section 3.6.1) and the deprecated 3GPP Packet Based Streaming Service 837 Annex.K [T3GPP.26.234R8] solution. 839 3.6.1. ISMA Encryption and Authentication 841 The Internet Streaming Media Alliance (ISMA) has defined ISMA 842 Encryption and Authentication 2.0 [ISMACryp2]. This specification 843 defines how one encrypts and packetizes the encrypted application 844 data units (ADUs) in an RTP payload using the MPEG-4 Generic payload 845 format [RFC3640]. The ADU types that are allowed are those that can 846 be stored as elementary streams in an ISO Media File format based 847 file. ISMACryp uses SRTP for packet level integrity and source 848 authentication from a streaming server to the receiver. 850 Key-management for a ISMACryp based system can be achieved through 851 Open Mobile Alliance (OMA) Digital Rights Management 2.0 [OMADRMv2], 852 for example. 854 4. Securing RTP Applications 856 In the following we provide guidelines for how to choose appropriate 857 security mechanisms for RTP applications. 859 4.1. Application Requirements 861 This section discusses a number of application requirements that need 862 be considered. An application designer choosing security solutions 863 requires a good understanding of what level of security is needed and 864 what behaviour they strive to achieve. 866 4.1.1. Confidentiality 868 When it comes to confidentiality of an RTP session there are several 869 aspects to consider: 871 Probability of compromise: When using encryption to provide media 872 confidentiality, it is necessary to have some rough understanding 873 of the security goal and how long one expect the protected content 874 to remain confidential. National or other regulations might 875 provide additional requirements on a particular usage of an RTP. 876 From that, one can determine which encryption algorithms are to be 877 used from the set of available transforms. 879 Potential for other leakage: RTP based security in most of its forms 880 simply wraps RTP and RTCP packets into cryptographic containers. 881 This commonly means that the size of the original RTP payload is 882 visible to observers of the protected packet flow. This can 883 provide information to those observers. A well-documented case is 884 the risk with variable bit-rate speech codecs that produce 885 different sized packets based on the speech input [RFC6562]. 886 Potential threats such as these need to be considered and, if they 887 are significant, then restrictions will be needed on mode choices 888 in the codec, or additional padding will need to be added to make 889 all packets equal size and remove the informational leakage. 891 Another case is RTP header extensions. If SRTP is used, header 892 extensions are normally not protected by the security mechanism 893 protecting the RTP payload. If the header extension carries 894 information that is considered sensitive, then the application 895 needs to be modified to ensure that mechanisms used to protect 896 against such information leakage are employed. 898 Who has access: When considering the confidentiality properties of a 899 system, it is important to consider where the media handled in the 900 clear. For example, if the system is based on an RTP mixer that 901 needs the keys to decrypt the media, process, and repacketize it, 902 then is the mixer providing the security guarantees expected by 903 the other parts of the system? Furthermore, it is important to 904 consider who has access to the keys. The policies for the 905 handling of the keys, and who can access the keys, need to be 906 considered along with the confidentiality goals. 908 As can be seen the actual confidentiality level has likely more to do 909 with the application's usage of centralized nodes, and the details of 910 the key-management solution chosen, than with the actual choice of 911 encryption algorithm (although, of course, the encryption algorithm 912 needs to be chosen appropriately for the desired security level). 914 4.1.2. Integrity 916 Protection against modification of content by a third party, or due 917 to errors in the network, is another factor to consider. The first 918 aspect that one considers is what resilience one has against 919 modifications to the content. Some media types are extremely 920 sensitive to network bit errors, whereas others might be able to 921 tolerate some degree of data corruption. Equally important is to 922 consider the sensitivity of the content, who is providing the 923 integrity assertion, what is the source of the integrity tag, and 924 what are the risks of modifications happening prior to that point 925 where protection is applied? These issues affect what cryptographic 926 algorithm is used, and the length of the integrity tags, and whether 927 the entire payload is protected. 929 RTP applications that rely on central nodes need to consider if hop- 930 by-hop integrity is acceptable, or if true end-to-end integrity 931 protection is needed? Is it important to be able to tell if a 932 middlebox has modified the data? There are some uses of RTP that 933 require trusted middleboxes that can modify the data in a way that 934 doesn't break integrity protection as seen by the receiver, for 935 example local advertisement insertion in IPTV systems; there are also 936 uses where it is essential that such in-network modification be 937 detectable. RTP can support both, with appropriate choices of 938 security mechanisms. 940 Integrity of the data is commonly closely tied to the question of 941 source authentication. That is, it becomes important to know who 942 makes an integrity assertion for the data. 944 4.1.3. Source Authentication 946 Source authentication is about determining who sent a particular RTP 947 or RTCP packet. It is normally closely tied with integrity, since a 948 receiver generally also wants to ensure that the data received is 949 what the source really sent, so source authentication without 950 integrity is not particularly useful. Similarly, integrity 951 protection without source authentication is also not particularly 952 useful; a claim that a packet is unchanged that cannot itself be 953 validated as from the source (or some from other known and trusted 954 party) is meaningless. 956 Source authentication can be asserted in several different ways: 958 Base level: Using cryptographic mechanisms that give authentication 959 with some type of key-management provide an implicit method for 960 source authentication. Assuming that the mechanism has sufficient 961 strength to not be circumvented in the time frame when you would 962 accept the packet as valid, it is possible to assert a source- 963 authenticated statement; this message is likely from a source that 964 has the cryptographic key(s) to this communication. 966 What that assertion actually means is highly dependent on the 967 application and how it handles the keys. If only the two peers 968 have access to the keys, this can form a basis for a strong trust 969 relationship that traffic is authenticated coming from one of the 970 peers. However, in a multi-party scenario where security contexts 971 are shared among participants, most base-level authentication 972 solutions can't even assert that this packet is from the same 973 source as the previous packet. 975 Binding the source and the signalling: A step up in the assertion 976 that can be done in base-level systems is to tie the signalling to 977 the key-exchange. Here, the goal is to at least be able to assert 978 that the source of the packets is the same entity that the 979 receiver established the session with. How feasible this is 980 depends on the properties of the key-management system, the 981 ability to tie the signalling to a particular source, and the 982 degree of trust the receiver places on the different nodes 983 involved. 985 For example, systems where the key-exchange is done using the 986 signalling systems, such as Security Descriptions [RFC4568], 987 enable a direct binding between signalling and key-exchange. In 988 such systems, the actual security depends on the trust one can 989 place in the signalling system to correctly associate the peer's 990 identifier with the key-exchange. 992 Using Identifiers: If the applications have access to a system that 993 can provide verifiable identifiers, then the source authentication 994 can be bound to that identifier. For example, in a point-to-point 995 communication even symmetric key crypto, where the key-management 996 can assert that the key has only been exchanged with a particular 997 identifier, can provide a strong assertion about the source of the 998 traffic. SIP identity [RFC4474] provides one example of how this 999 can be done, and could be used to bind DTLS-SRTP certificates used 1000 by an end-point to the identity provider's public key to 1001 authenticate the source of a DTLS-SRTP flow. 1003 Note that all levels of the system need to have matching 1004 capability to assert identifiers. If the signalling can assert 1005 that only a given entity in a multiparty session has a key, then 1006 the media layer might be able to provide guarantees about the 1007 identifier used by the media sender. However, using an signalling 1008 authentication mechanism built on a group key can limit the media 1009 layer to asserting only group membership. 1011 4.1.4. Identifiers and Identity 1013 There exist many different types of systems providing identifiers 1014 with different properties (e.g., SIP identity [RFC4474]). In the 1015 context of RTP applications, the most important property is the 1016 possibility to perform source authentication and verify such 1017 assertions in relation to any claimed identifiers. What an 1018 identifier really represent can also vary but, in the context of 1019 communication, one of the most obvious is the identifiers 1020 representing the identity of the human user one communicates with. 1021 However, the human user can also have additional identifiers in a 1022 particular role. For example, the human Alice, can also be a police 1023 officer and in some cases a identifier for her role as police officer 1024 will be more relevant than one that assert that she is Alice. This 1025 is common in contact with organizations, where it is important to 1026 prove the persons right to represent the organization. Some examples 1027 of identifier/Identity mechanisms that can be used: 1029 Certificate based: A certificate is used to assert the identifiers 1030 used to claim an identity, by having access to the private part of 1031 the certificate one can perform signing to assert ones identity. 1032 Any entity interested in verifying the assertion then needs the 1033 public part of the certificate. By having the certificate, one 1034 can verify the signature against the certificate. The next step 1035 is to determine if one trusts the certificate's trust chain. 1036 Commonly by provisioning the verifier with the public part of a 1037 root certificate, this enables the verifier to verify a trust 1038 chain from the root certificate down to the identifier in the 1039 certificate. However, the trust is based on all steps in the 1040 certificate chain being verifiable and trusted. Thus provisioning 1041 of root certificates and the ability to revoke compromised 1042 certificates are aspects that will require infrastructure. 1044 Online Identity Providers: An online identity provider (IdP) can 1045 authenticate a user's right to use an identifier, then perform 1046 assertions on their behalf or provision the requester with short- 1047 term credentials to assert the identifiers. The verifier can then 1048 contact the IdP to request verification of a particular 1049 identifier. Here the trust is highly dependent on how much one 1050 trusts the IdP. The system also becomes dependent on having 1051 access to the relevant IdP. 1053 In all of the above examples, an important part of the security 1054 properties are related to the method for authenticating the access to 1055 the identity. 1057 4.1.5. Privacy 1059 RTP applications need to consider what privacy goals they have. As 1060 RTP applications communicate directly between peers in many cases, 1061 the IP addresses of any communication peer will be available. The 1062 main privacy concern with IP addresses is related to geographical 1063 location and the possibility to track a user of an end-point. The 1064 main way of avoid such concerns is the introduction of relay (e.g., a 1065 TURN server [RFC5766]) or centralized media mixers or forwarders that 1066 hides the address of a peer from any other peer. The security and 1067 trust placed in these relays obviously needs to be carefully 1068 considered. 1070 RTP itself can contribute to enabling a particular user to be tracked 1071 between communication sessions if the CNAME is generated according to 1072 the RTP specification in the form of user@host. Such RTCP CNAMEs are 1073 likely long term stable over multiple sessions, allowing tracking of 1074 users. This can be desirable for long-term fault tracking and 1075 diagnosis, but clearly has privacy implications. Instead 1076 cryptographically random ones could be used as defined by Guidelines 1077 for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) 1078 [RFC7022]. 1080 If there exist privacy goals, these need to be considered, and the 1081 system designed with them in mind. In addition certain RTP features 1082 might have to be configured to safeguard privacy, or have 1083 requirements on how the implementation is done. 1085 4.2. Application Structure 1087 When it comes to RTP security, the most appropriate solution is often 1088 highly dependent on the topology of the communication session. The 1089 signalling also impacts what information can be provided, and if this 1090 can be instance specific, or common for a group. In the end the key- 1091 management system will highly affect the security properties achieved 1092 by the application. At the same time, the communication structure of 1093 the application limits what key management methods are applicable. 1094 As different key-management have different requirements on underlying 1095 infrastructure it is important to take that aspect into consideration 1096 early in the design. 1098 4.3. Automatic Key Management 1100 The Guidelines for Cryptographic Key Management [RFC4107] provide an 1101 overview of why automatic key management is important. They also 1102 provide a strong recommendation on using automatic key management. 1103 Most of the security solutions reviewed in this document provide or 1104 support automatic key management, at least to establish session keys. 1105 In some more long term use cases, credentials might in certain cases 1106 need to be be manually deployed. 1108 For SRTP an important aspect of automatic key management is to ensure 1109 that two time pads do not occur, in particular by preventing multiple 1110 end points using the same session key and SSRC. In these cases 1111 automatic key management methods can have strong dependencies on 1112 signalling features to function correctly. If those dependencies 1113 can't be fulfilled, additional constrains on usage, e.g., per-end 1114 point session keys, might be needed to avoid the issue. 1116 When selecting security mechanisms for an RTP application it is 1117 important to consider the properties of the key management. Using 1118 key management that is both automatic and integrated will provide 1119 minimal interruption for the user, and is important to ensure that 1120 security can, and will remain, to be on by default. 1122 4.4. End-to-End Security vs Tunnels 1124 If the security mechanism only provides a secured tunnel, for example 1125 like some common uses of IPsec (Section 3.3), it is important to 1126 consider the full end-to-end properties of the system. How does one 1127 ensure that the path from the endpoint to the local tunnel ingress/ 1128 egress is secure and can be trusted (and similarly for the other end 1129 of the tunnel)? How does one handle the source authentication of the 1130 peer, as the security protocol identifies the other end of the 1131 tunnel. These are some of the issues that arise when one considers a 1132 tunnel based security protocol rather than an end-to-end. Even with 1133 clear requirements and knowledge that one still can achieve the 1134 security properties using a tunnel based solution, one ought to 1135 prefer to use end-to-end mechanisms, as they are much less likely to 1136 violate any assumptions made about deployment. These assumptions can 1137 also be difficult to automatically verify. 1139 4.5. Plain Text Keys 1141 Key management solutions that use plain text keys, like SDP Security 1142 Descriptions (Section 3.1.3), require care to ensure a secure 1143 transport of the signalling messages that contain the plain text 1144 keys. For plain text keys the security properties of the system 1145 depend on how securely the plain text keys are protected end-to-end 1146 between the sender and receiver(s). Not only does one need to 1147 consider what transport protection is provided for the signalling 1148 message including the keys, but also the degree to which any 1149 intermediaries in the signalling are trusted. Untrusted 1150 intermediaries can perform man in the middle attacks on the 1151 communication, or can log the keys with the result in encryption 1152 being compromised significantly after the actual communication 1153 occurred. 1155 4.6. Interoperability 1157 Few RTP applications exist as independent applications that never 1158 interoperate with anything else. Rather, they enable communication 1159 with a potentially large number of other systems. To minimize the 1160 number of security mechanisms that need to be implemented, it is 1161 important to consider if one can use the same security mechanisms as 1162 other applications. This can also reduce problems of determining 1163 what security level is actually negotiated in a particular session. 1165 The desire to be interoperable can, in some cases, be in conflict 1166 with the security requirements of an application. To meet the 1167 security goals, it might be necessary to sacrifice interoperability. 1168 Alternatively, one can implement multiple security mechanisms, this 1169 however introduces the complication of ensuring that the user 1170 understands what it means to use a particular security system. In 1171 addition, the application can then become vulnerable to bid-down 1172 attack. 1174 5. Examples 1176 In the following we describe a number of example security solutions 1177 for applications using RTP services or frameworks. These examples 1178 are provided to illustrate the choices available. They are not 1179 normative recommendations for security. 1181 5.1. Media Security for SIP-established Sessions using DTLS-SRTP 1183 The IETF evaluated media security for RTP sessions established using 1184 point-to-point SIP sessions in 2009. A number of requirements were 1185 determined, and based on those, the existing solutions for media 1186 security and especially the keying methods were analysed. The 1187 resulting requirements and analysis were published in [RFC5479]. 1188 Based on this analysis and working group discussion, DTLS-SRTP was 1189 determined to be the best solution. 1191 The security solution for SIP using DTLS-SRTP is defined in the 1192 Framework for Establishing a Secure Real-time Transport Protocol 1193 (SRTP) Security Context Using Datagram Transport Layer Security 1194 (DTLS) [RFC5763]. On a high level the framework uses SIP with SDP 1195 offer/answer procedures to exchange the network addresses where the 1196 server end-point will have a DTLS-SRTP enable server running. The 1197 SIP signalling is also used to exchange the fingerprints of the 1198 certificate each end-point will use in the DTLS establishment 1199 process. When the signalling is sufficiently completed, the DTLS- 1200 SRTP client performs DTLS handshakes and establishes SRTP session 1201 keys. The clients also verify the fingerprints of the certificates 1202 to verify that no man in the middle has inserted themselves into the 1203 exchange. 1205 DTLS has a number of good security properties. For example, to 1206 enable a man in the middle someone in the signalling path needs to 1207 perform an active action and modify both the signalling message and 1208 the DTLS handshake. There also exists solutions that enables the 1209 fingerprints to be bound to identities. SIP Identity provides an 1210 identity established by the first proxy for each user [RFC4474]. 1211 This reduces the number of nodes the connecting user User Agent has 1212 to trust to include just the first hop proxy, rather than the full 1213 signalling path. The biggest security weakness of this system is its 1214 dependency on the signalling. SIP signalling passes multiple nodes 1215 and there is usually no message security deployed, only hop-by-hop 1216 transport security, if any, between the nodes. 1218 5.2. Media Security for WebRTC Sessions 1220 Web Real-Time Communication (WebRTC) [I-D.ietf-rtcweb-overview] is a 1221 solution providing JavaScript web applications with real-time media 1222 directly between browsers. Media is transported using RTP protected 1223 using a mandatory application of SRTP [RFC3711], with keying done 1224 using DTLS-SRTP [RFC5764]. The security configuration is further 1225 defined in the WebRTC Security Architecture 1226 [I-D.ietf-rtcweb-security-arch]. 1228 A hash of the peer's certificate is provided to the JavaScript web 1229 application, allowing that web application to verify identity of the 1230 peer. There are several ways in which the certificate hashes can be 1231 verified. An approach identified in the WebRTC security architecture 1232 [I-D.ietf-rtcweb-security-arch] is to use an identity provider. In 1233 this solution the Identity Provider, which is a third party to the 1234 web application, signs the DTLS-SRTP hash combined with a statement 1235 on the validity of the user identity that has been used to sign the 1236 hash. The receiver of such an identity assertion can then 1237 independently verify the user identity to ensure that it is the 1238 identity that the receiver intended to communicate with, and that the 1239 cryptographic assertion holds; this way a user can be certain that 1240 the application also can't perform a MITM and acquire the keys to the 1241 media communication. Other ways of verifying the certificate hashes 1242 exist, for example they could be verified against a hash carried in 1243 some out of band channel (e.g., compare with a hash printed on a 1244 business card), or using a verbal short authentication string (e.g., 1245 as in ZRTP [RFC6189]), or using hash continuity. 1247 In the development of WebRTC there has also been attention given to 1248 privacy considerations. The main RTP-related concerns that have been 1249 raised are: 1251 Location Disclosure: As ICE negotiation [RFC5245] provides IP 1252 addresses and ports for the browser, this leaks location 1253 information in the signalling to the peer. To prevent this one 1254 can block the usage of any ICE candidate that isn't a relay 1255 candidate, i.e. where the IP and port provided belong to the 1256 service providers media traffic relay. 1258 Prevent tracking between sessions: static RTP CNAMEs and DTLS-SRTP 1259 certificates provide information that is re-used between session 1260 instances. Thus to prevent tracking, such information is ought 1261 not be re-used between sessions, or the information ought not sent 1262 in the clear. Note, that generating new certificates each time 1263 prevents continuity in authentication, however, as WebRTC users 1264 are expected to use multiple devices to access the same 1265 communication service, such continuity can't be expected anyway, 1266 instead the above described identity mechanism has to be relied 1267 on. 1269 Note: The above cases are focused on providing privacy from other 1270 parties, not on providing privacy from the web server that provides 1271 the WebRTC Javascript application. 1273 5.3. IP Multimedia Subsystem (IMS) Media Security 1275 In IMS, the core network is controlled by a single operator, or by 1276 several operators with high trust in each other. Except for some 1277 types of accesses, the operator is in full control, and no packages 1278 are routed over the Internet. Nodes in the core network offer 1279 services such as voice mail, interworking with legacy systems (PSTN, 1280 GSM, and 3G), and transcoding. End-points are authenticated during 1281 the SIP registration using either IMS-AKA (using SIM credentials) or 1282 SIP Digest (using password). 1284 In IMS media security [T3GPP.33.328], end-to-end encryption is 1285 therefore not seen as needed or desired as it would hinder for 1286 example interworking and transcoding, making calls between 1287 incompatible terminals impossible. Because of this IMS media 1288 security mostly uses end-to-access-edge security where SRTP is 1289 terminated in the first node in the core network. As the SIP 1290 signaling is trusted and encrypted (with TLS or IPsec), security 1291 descriptions [RFC4568] is considered to give good protection against 1292 eavesdropping over the accesses that are not already encrypted (GSM, 1293 3G, LTE). Media source authentication is based on knowledge of the 1294 SRTP session key and trust in that the IMS network will only forward 1295 media from the correct end-point. 1297 For enterprises and government agencies, which might have weaker 1298 trust in the IMS core network and can be assumed to have compatible 1299 terminals, end-to-end security can be achieved by deploying their own 1300 key management server. 1302 Work on Interworking with WebRTC is currently ongoing; the security 1303 will still be end-to-access-edge, but using DTLS-SRTP [RFC5763] 1304 instead of security descriptions. 1306 5.4. 3GPP Packet Based Streaming Service (PSS) 1308 The 3GPP Release 11 PSS specification of the Packet Based Streaming 1309 Service (PSS) [T3GPP.26.234R11] defines, in Annex R, a set of 1310 security mechanisms. These security mechanisms are concerned with 1311 protecting the content from being copied, i.e. Digital Rights 1312 Management. To meet these goals with the specified solution, the 1313 client implementation and the application platform are trusted to 1314 protect against access and modification by an attacker. 1316 PSS is RTSP 1.0 [RFC2326] controlled media streaming over RTP. Thus 1317 an RTSP client whose user wants to access a protected content will 1318 request a session description (SDP [RFC4566]) for the protected 1319 content. This SDP will indicate that the media is ISMACryp 2.0 1320 [ISMACryp2] protected media encoding application units (AUs). The 1321 key(s) used to protect the media are provided in either of two ways. 1322 If a single key is used then the client uses some DRM system to 1323 retrieve the key as indicated in the SDP. Commonly OMA DRM v2 1324 [OMADRMv2] will be used to retrieve the key. If multiple keys are to 1325 be used, then an additional RTSP stream for key-updates in parallel 1326 with the media streams is established, where key updates are sent to 1327 the client using Short Term Key Messages defined in the "Service and 1328 Content Protection for Mobile Broadcast Services" section of the OMA 1329 Mobile Broadcast Services [OMABCAST]. 1331 Worth noting is that this solution doesn't provide any integrity 1332 verification method for the RTP header and payload header 1333 information, only the encoded media AU is protected. 3GPP has not 1334 defined any requirement for supporting any solution that could 1335 provide that service. Thus, replay or insertion attacks are 1336 possible. Another property is that the media content can be 1337 protected by the ones providing the media, so that the operators of 1338 the RTSP server has no access to unprotected content. Instead all 1339 that want to access the media is supposed to contact the DRM keying 1340 server and if the device is acceptable they will be given the key to 1341 decrypt the media. 1343 To protect the signalling, RTSP 1.0 supports the usage of TLS. This 1344 is, however, not explicitly discussed in the PSS specification. 1345 Usage of TLS can prevent both modification of the session description 1346 information and help maintain some privacy of what content the user 1347 is watching as all URLs would then be confidentiality protected. 1349 5.5. RTSP 2.0 1351 Real-time Streaming Protocol 2.0 [I-D.ietf-mmusic-rfc2326bis] offers 1352 an interesting comparison to the PSS service (Section 5.4) that is 1353 based on RTSP 1.0 and service requirements perceived by mobile 1354 operators. A major difference between RTSP 1.0 and RTSP 2.0 is that 1355 2.0 is fully defined under the requirement to have mandatory to 1356 implement security mechanism. As it specifies how one transport 1357 media over RTP it is also defining security mechanisms for the RTP 1358 transported media streams. 1360 The security goals for RTP in RTSP 2.0 is to ensure that there is 1361 confidentiality, integrity and source authentication between the RTSP 1362 server and the client. This to prevent eavesdropping on what the 1363 user is watching for privacy reasons and to prevent replay or 1364 injection attacks on the media stream. To reach these goals, the 1365 signalling also has to be protected, requiring the use of TLS between 1366 the client and server. 1368 Using TLS-protected signalling the client and server agree on the 1369 media transport method when doing the SETUP request and response. 1370 The secured media transport is SRTP (SAVP/RTP) normally over UDP. 1371 The key management for SRTP is MIKEY using RSA-R mode. The RSA-R 1372 mode is selected as it allows the RTSP Server to select the key 1373 despite having the RTSP Client initiate the MIKEY exchange. It also 1374 enables the reuse of the RTSP servers TLS certificate when creating 1375 the MIKEY messages thus ensuring a binding between the RTSP server 1376 and the key exchange. Assuming the SETUP process works, this will 1377 establish a SRTP crypto context to be used between the RTSP Server 1378 and the Client for the RTP transported media streams. 1380 6. IANA Considerations 1382 This document makes no request of IANA. 1384 Note to RFC Editor: this section can be removed on publication as an 1385 RFC. 1387 7. Security Considerations 1389 This entire document is about security. Please read it. 1391 8. Acknowledgements 1393 We thank the IESG for their careful review of 1394 [I-D.ietf-avt-srtp-not-mandatory] which led to the writing of this 1395 memo. John Mattsson has contributed the IMS Media Security example 1396 (Section 5.3). 1398 The authors wished to thank Christian Correll, Dan Wing, Kevin Gross, 1399 Alan Johnston, Michael Peck, Ole Jacobsen, Spencer Dawkins, Stephen 1400 Farrell, John Mattsson, and Suresh Krishnan for review and proposals 1401 for improvements of the text. 1403 9. Informative References 1405 [I-D.ietf-avt-srtp-not-mandatory] 1406 Perkins, C. and M. Westerlund, "Securing the RTP Protocol 1407 Framework: Why RTP Does Not Mandate a Single Media 1408 Security Solution", draft-ietf-avt-srtp-not-mandatory-14 1409 (work in progress), October 2013. 1411 [I-D.ietf-avtcore-aria-srtp] 1412 Kim, W., Lee, J., Kim, D., Park, J., and D. Kwon, "The 1413 ARIA Algorithm and Its Use with the Secure Real-time 1414 Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-06 1415 (work in progress), November 2013. 1417 [I-D.ietf-avtcore-srtp-aes-gcm] 1418 McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated 1419 Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp- 1420 aes-gcm-10 (work in progress), September 2013. 1422 [I-D.ietf-avtcore-srtp-ekt] 1423 McGrew, D. and D. Wing, "Encrypted Key Transport for 1424 Secure RTP", draft-ietf-avtcore-srtp-ekt-01 (work in 1425 progress), October 2013. 1427 [I-D.ietf-mmusic-rfc2326bis] 1428 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1429 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1430 (RTSP)", draft-ietf-mmusic-rfc2326bis-38 (work in 1431 progress), October 2013. 1433 [I-D.ietf-rtcweb-overview] 1434 Alvestrand, H., "Overview: Real Time Protocols for Brower- 1435 based Applications", draft-ietf-rtcweb-overview-08 (work 1436 in progress), September 2013. 1438 [I-D.ietf-rtcweb-security-arch] 1439 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 1440 rtcweb-security-arch-07 (work in progress), July 2013. 1442 [ISMACryp2] 1443 Internet Streaming Media Alliance (ISMA), "ISMA Encryption 1444 and Authentication, Version 2.0 release version", November 1445 2007. 1447 [OMABCAST] 1448 Open Mobile Alliance, "OMA Mobile Broadcast Services 1449 V1.0", February 2009. 1451 [OMADRMv2] 1452 Open Mobile Alliance, "OMA Digital Rights Management 1453 V2.0", July 2008. 1455 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1456 RFC 1112, August 1989. 1458 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1459 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1461 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 1462 Engineering Task Force Standard Protocols", BCP 61, RFC 1463 3365, August 2002. 1465 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1466 Jacobson, "RTP: A Transport Protocol for Real-Time 1467 Applications", STD 64, RFC 3550, July 2003. 1469 [RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., 1470 and P. Gentric, "RTP Payload Format for Transport of 1471 MPEG-4 Elementary Streams", RFC 3640, November 2003. 1473 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1474 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1475 RFC 3711, March 2004. 1477 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1478 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1479 August 2004. 1481 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1482 Key Management", BCP 107, RFC 4107, June 2005. 1484 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1485 Internet Protocol", RFC 4301, December 2005. 1487 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 1488 Stream Loss-Tolerant Authentication (TESLA) in the Secure 1489 Real-time Transport Protocol (SRTP)", RFC 4383, February 1490 2006. 1492 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1493 Authenticated Identity Management in the Session 1494 Initiation Protocol (SIP)", RFC 4474, August 2006. 1496 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1497 Description Protocol", RFC 4566, July 2006. 1499 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 1500 Carrara, "Key Management Extensions for Session 1501 Description Protocol (SDP) and Real Time Streaming 1502 Protocol (RTSP)", RFC 4567, July 2006. 1504 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1505 Description Protocol (SDP) Security Descriptions for Media 1506 Streams", RFC 4568, July 2006. 1508 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1509 and RTP Control Protocol (RTCP) Packets over Connection- 1510 Oriented Transport", RFC 4571, July 2006. 1512 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1513 Transport Layer Security (TLS) Protocol in the Session 1514 Description Protocol (SDP)", RFC 4572, July 2006. 1516 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1517 IP", RFC 4607, August 2006. 1519 [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for 1520 Multimedia Internet KEYing (MIKEY)", RFC 4650, September 1521 2006. 1523 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 1524 RSA-R: An Additional Mode of Key Distribution in 1525 Multimedia Internet KEYing (MIKEY)", RFC 4738, November 1526 2006. 1528 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1529 Transform Carrying Roll-Over Counter for the Secure Real- 1530 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1532 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 1533 4949, August 2007. 1535 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 1536 January 2008. 1538 [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of 1539 Various Multimedia Internet KEYing (MIKEY) Modes and 1540 Extensions", RFC 5197, June 2008. 1542 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1543 (ICE): A Protocol for Network Address Translator (NAT) 1544 Traversal for Offer/Answer Protocols", RFC 5245, April 1545 2010. 1547 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1548 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1550 [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 1551 "Requirements and Analysis of Media Security Management 1552 Protocols", RFC 5479, April 2009. 1554 [RFC5669] Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The 1555 SEED Cipher Algorithm and Its Use with the Secure Real- 1556 Time Transport Protocol (SRTP)", RFC 5669, August 2010. 1558 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1559 Protocol (RTCP) Extensions for Single-Source Multicast 1560 Sessions with Unicast Feedback", RFC 5760, February 2010. 1562 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1563 for Establishing a Secure Real-time Transport Protocol 1564 (SRTP) Security Context Using Datagram Transport Layer 1565 Security (DTLS)", RFC 5763, May 2010. 1567 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1568 Security (DTLS) Extension to Establish Keys for the Secure 1569 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1571 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1572 Relays around NAT (TURN): Relay Extensions to Session 1573 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1575 [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based 1576 Modes of Key Distribution in Multimedia Internet KEYing 1577 (MIKEY)", RFC 6043, March 2011. 1579 [RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure 1580 RTP", RFC 6188, March 2011. 1582 [RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 1583 Path Key Agreement for Unicast Secure RTP", RFC 6189, 1584 April 2011. 1586 [RFC6267] Cakulev, V. and G. Sundaram, "MIKEY-IBAKE: Identity-Based 1587 Authenticated Key Exchange (IBAKE) Mode of Key 1588 Distribution in Multimedia Internet KEYing (MIKEY)", RFC 1589 6267, June 2011. 1591 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1592 Security Version 1.2", RFC 6347, January 2012. 1594 [RFC6509] Groves, M., "MIKEY-SAKKE: Sakai-Kasahara Key Encryption in 1595 Multimedia Internet KEYing (MIKEY)", RFC 6509, February 1596 2012. 1598 [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of 1599 Variable Bit Rate Audio with Secure RTP", RFC 6562, March 1600 2012. 1602 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 1603 Real-time Transport Protocol (SRTP)", RFC 6904, April 1604 2013. 1606 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 1607 "Guidelines for Choosing RTP Control Protocol (RTCP) 1608 Canonical Names (CNAMEs)", RFC 7022, September 2013. 1610 [T3GPP.26.234R11] 1611 3GPP, "Technical Specification Group Services and System 1612 Aspects; Transparent end-to-end Packet-switched Streaming 1613 Service (PSS); Protocols and codecs", 3GPP TS 26.234 1614 11.1.0, September 2012. 1616 [T3GPP.26.234R8] 1617 3GPP, "Technical Specification Group Services and System 1618 Aspects; Transparent end-to-end Packet-switched Streaming 1619 Service (PSS); Protocols and codecs", 3GPP TS 26.234 1620 8.4.0, September 2009. 1622 [T3GPP.26.346] 1623 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 1624 Protocols and codecs", 3GPP TS 26.346 10.7.0, March 2013. 1626 [T3GPP.33.246] 1627 3GPP, "3G Security; Security of Multimedia Broadcast/ 1628 Multicast Service (MBMS)", 3GPP TS 33.246 12.1.0, December 1629 2012. 1631 [T3GPP.33.328] 1632 3GPP, "IP Multimedia Subsystem (IMS) media plane 1633 security", 3GPP TS 33.328 12.1.0, December 2012. 1635 Authors' Addresses 1637 Magnus Westerlund 1638 Ericsson 1639 Farogatan 6 1640 SE-164 80 Kista 1641 Sweden 1643 Phone: +46 10 714 82 87 1644 Email: magnus.westerlund@ericsson.com 1646 Colin Perkins 1647 University of Glasgow 1648 School of Computing Science 1649 Glasgow G12 8QQ 1650 United Kingdom 1652 Email: csp@csperkins.org 1653 URI: http://csperkins.org/