idnits 2.17.1 draft-ietf-avtcore-rtp-security-options-01.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 (October 22, 2012) is 4202 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-10 == Outdated reference: A later version (-11) exists of draft-ietf-avtcore-aria-srtp-00 == Outdated reference: A later version (-17) exists of draft-ietf-avtcore-srtp-aes-gcm-03 == Outdated reference: A later version (-03) exists of draft-ietf-avtcore-srtp-ekt-00 == Outdated reference: A later version (-05) exists of draft-ietf-avtcore-srtp-encrypted-header-ext-02 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-04 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-03 -- 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 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 5 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: April 25, 2013 University of Glasgow 6 October 22, 2012 8 Options for Securing RTP Sessions 9 draft-ietf-avtcore-rtp-security-options-01 11 Abstract 13 The Real-time Transport Protocol (RTP) is used in a large number of 14 different application domains and environments. This hetrogeneity 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 April 25, 2013. 41 Copyright Notice 43 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Point to Point Sessions . . . . . . . . . . . . . . . . . 5 61 2.2. Sessions Using an RTP Mixer . . . . . . . . . . . . . . . 5 62 2.3. Sessions Using an RTP Translator . . . . . . . . . . . . . 6 63 2.3.1. Transport Translator (Relay) . . . . . . . . . . . . . 6 64 2.3.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . 7 65 2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . . 8 66 2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . . 8 67 2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 8 68 3. Security Options . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . . 10 70 3.1.1. Key Management for SRTP: DTLS-SRTP . . . . . . . . . . 11 71 3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . . 12 72 3.1.3. Key Management for SRTP: Security Descriptions . . . . 13 73 3.1.4. Key Management for SRTP: Encrypted Key Transport . . . 14 74 3.1.5. Key Management for SRTP: Other systems . . . . . . . . 14 75 3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . . 14 76 3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 3.4. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 3.5. TLS over TCP . . . . . . . . . . . . . . . . . . . . . . . 16 79 3.6. Payload-only Security Mechanisms . . . . . . . . . . . . . 16 80 3.6.1. ISMA Encryption and Authentication . . . . . . . . . . 17 81 4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 17 82 4.1. Application Requirements . . . . . . . . . . . . . . . . . 17 83 4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 17 84 4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 18 85 4.1.3. Source Authentication . . . . . . . . . . . . . . . . 19 86 4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . . 20 87 4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 20 88 4.2. Application Structure . . . . . . . . . . . . . . . . . . 21 89 4.3. Interoperability . . . . . . . . . . . . . . . . . . . . . 21 90 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 5.1. Media Security for SIP-established Sessions using 92 DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . . 22 93 5.2. Media Security for WebRTC Sessions . . . . . . . . . . . . 22 94 5.3. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 23 95 5.4. IPTV . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 98 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 99 9. Informative References . . . . . . . . . . . . . . . . . . . . 24 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 102 1. Introduction 104 Real-time Transport Protocol (RTP) [RFC3550] is widely used in a 105 large variety of multimedia applications, including Voice over IP 106 (VoIP), centralized multimedia conferencing, sensor data transport, 107 and Internet television (IPTV) services. These applications can 108 range from point-to-point phone calls, through centralised group 109 teleconferences, to large-scale television distribution services. 110 The types of media can vary significantly, as can the signalling 111 methods used to establish the RTP sessions. 113 This multi-dimensional heterogeneity has so far prevented development 114 of a single security solution that meets the needs of the different 115 applications. Instead significant number of different solutions have 116 been developed to meet different sets of security goals. This makes 117 it difficult for application developers to know what solutions exist, 118 and whether their properties are appropriate. This memo gives an 119 overview of the available RTP solutions, and provides guidance on 120 their applicability for different application domains. The guidance 121 provided is not exhaustive, and this memo does not provide normative 122 recommendations. 124 It is important that application developers consider the security 125 goals and requirements for their application. The IETF considers it 126 important that protocols implement, and makes available to the user, 127 secure modes of operation [RFC3365]. Because of the heterogeneity of 128 RTP applications and use cases, however, a single security solution 129 cannot be mandated. Instead, application developers need to select 130 mechanisms that provide appropriate security for their environment. 131 It is strongly encouraged that common mechanisms are used by related 132 applications in common environments. The IETF publishes guidelines 133 for specific classes of applications, so it worth searching for such 134 guidelines. 136 The remainder of this document is structured as follows. Section 2 137 provides additional background. Section 3 outlines the available 138 security mechanisms at the time of this writing, and lists their key 139 security properties and constraints. That is followed by guidelines 140 and important aspects to consider when securing an RTP application in 141 Section 4. Finally, we give some examples of application domains 142 where guidelines for security exist in Section 5. 144 2. Background 146 RTP can be used in a wide variety of topologies, and combinations of 147 topologies, due to it's support for unicast, multicast groups, and 148 broadcast topologies, and the existence of different types of RTP 149 middleboxes. In the following we review the different topologies 150 supported by RTP to understand their implications for the security 151 properties and trust relations that can exist in RTP sessions. 153 2.1. Point to Point Sessions 155 The most basic use case is two directly connected end-points, shown 156 in Figure 1, where A has established an RTP session with B. In this 157 case the RTP security is primarily about ensuring that any third 158 party can't compromise the confidentiality and integrity of the media 159 communication. This requires confidentiality protection of the RTP 160 session, integrity protection of the RTP/RTCP packets, and source 161 authentication of all the packets to ensure no man-in-the-middle 162 attack is taking place. 164 The source authentication can also be tied to a user or an end-points 165 verifiable identity to ensure that the peer knows who they are 166 communicating with. Here the combination of the security protocol 167 protecting the RTP session and its RTP and RTCP traffic and the key- 168 management protocol becomes important in which security statements 169 one can do. 170 +---+ +---+ 171 | A |<------->| B | 172 +---+ +---+ 174 Figure 1: Point to Point Topology 176 2.2. Sessions Using an RTP Mixer 178 An RTP mixer is a an RTP session level middlebox that one can build 179 an multi-party RTP based conference around. The RTP mixer might 180 actually perform media mixing, like mixing audio or compositing video 181 images into a new media stream being sent from the mixer to a given 182 participant; or it might provide a conceptual stream, for example the 183 video of the current active speaker. From a security point of view, 184 the important featurs of an RTP mixer is that it generates a new 185 media stream, and has its own source identifier, and does not simply 186 forward the original media. 188 An RTP session using a mixer might have a topology like that in 189 Figure 2. In this examples, participants A-D each send unicast RTP 190 traffic between themselves and the RTP mixer, and receive a RTP 191 stream from the mixer, comprising a mixture of the streams from the 192 other participants. 194 +---+ +------------+ +---+ 195 | A |<---->| |<---->| B | 196 +---+ | | +---+ 197 | Mixer | 198 +---+ | | +---+ 199 | C |<---->| |<---->| D | 200 +---+ +------------+ +---+ 202 Figure 2: Example RTP Mixer topology 204 A consequence of an RTP mixer having its own source identifier, and 205 acting as an active participant towards the other end-points, is that 206 the RTP mixer needs to be a trusted device that is part of the 207 security context(s) established. The RTP mixer can also become a 208 security enforcing entity. For example, a common approach to secure 209 the topology in Figure 2 is to establish a security context between 210 the mixer and each participant independently, and have the mixer 211 source authenticate each peer. The mixer then ensures that one 212 participant cannot impersonsate another. 214 2.3. Sessions Using an RTP Translator 216 RTP translators are middleboxes that provide various levels of in- 217 network media translation and transcoding. Their security properties 218 vary widely, depending on which type of operations they attempt to 219 perform. We identify three different categories of RTP translator: 220 transport translators, gateways, and media transcoders. We discuss 221 each in turn. 223 2.3.1. Transport Translator (Relay) 225 A transport translator [RFC5117] operates on a level below RTP and 226 RTCP. It relays the RTP/RTCP traffic from one end-point to one or 227 more other addresses. This can be done based only on IP addresses 228 and transport protocol ports, with each receive port on the 229 translator can have a very basic list of where to forward traffic. 230 Transport translators should also implement ingress filtering to 231 prevent random traffic from being forwarded that isn't coming from a 232 participant in the conference. 234 Figure 3 shows an example transport translator, where traffic from 235 any one of the four participants will be forwarded to the other three 236 participants unchanged. The resulting topology is very similar to 237 Any source Multicast (ASM) session (as discussed in Section 2.4), but 238 implemented at the application layer. 240 +---+ +------------+ +---+ 241 | A |<---->| |<---->| B | 242 +---+ | Relay | +---+ 243 | Translator | 244 +---+ | | +---+ 245 | C |<---->| |<---->| D | 246 +---+ +------------+ +---+ 248 Figure 3: RTP relay translator topology 250 A transport translator can often operate without needing to be in the 251 security context, as long as the security mechanism does not provide 252 protection over the transport-layer information. A transport 253 translator does, however, make the group communication visible, and 254 so can complicate keying and source authentication mechanisms. This 255 is further discussed in Section 2.4. 257 2.3.2. Gateway 259 Gateways are deployed when the endpoints are not fully compatible. 260 Figure 4 shows an example topology. The functions a gateway provides 261 can be diverse, and range from transport layer relaying between two 262 domains not allowing direct communication, via transport or media 263 protocol function initiation or termination, to protocol or media 264 encoding translation. The supported security protocol might even be 265 one of the reasons a gateway is needed. 267 +---+ +-----------+ +---+ 268 | A |<---->| Gateway |<---->| B | 269 +---+ +-----------+ +---+ 271 Figure 4: RTP Gateway Topology 273 The choice of security protocol and the details of the gateway 274 function will determine if the gateway needs to be a trusted part of 275 the application security context or not. Many gateways need to be 276 trusted by all peers to perform the translation; in other cases some 277 or all peers might not be aware of the presence of the gateway. The 278 security protocols have different properties depending on the degree 279 of trust and visibility needed. Ensuring communication is possible 280 without trusting the gateway can be strong incentive for accepting 281 different security properties. Some security solutions will be able 282 to detect the gateways as manipulating the media stream, unless the 283 gateway is a trusted device. 285 2.3.3. Media Transcoder 287 A Media transcoder is a special type of gateway device that changes 288 the encoding of the media being transported by RTP. The discussion 289 in Section 2.3.2 applies. A media transcoder alters the media data, 290 and so almost certainly needs to be trusted device that is part of 291 the security context. 293 2.4. Any Source Multicast 295 Any Source Multicast [RFC1112] is the original multicast model where 296 any multicast group participant can send to the multicast group, and 297 get their packets delivered to all group members (see Figure 5). 298 This form of communication has interesting security properties, due 299 to the many-to-many nature of the group. Source authentication is 300 important, but all participants in the group security context will 301 have access to the necessary secrets to decrypt and verify integrity 302 of the traffic. Thus use of any symmetric security functions fails 303 if the goal is to separate individual sources within the security 304 context; alternate solutions are needed. 306 +-----+ 307 +---+ / \ +---+ 308 | A |----/ \---| B | 309 +---+ / Multi- \ +---+ 310 + Cast + 311 +---+ \ Network / +---+ 312 | C |----\ /---| D | 313 +---+ \ / +---+ 314 +-----+ 316 Figure 5: Any Source Multicast Group 318 In addition the potential large size of multicast groups creates some 319 considerations for the scalability of the solution and how the key- 320 management is handled. 322 2.5. Source-Specific Multicast 324 Source Specific Multicast [RFC4607] allows only a specific end-point 325 to send traffic to the multicast group. That end-point is labelled 326 the Distribution Source in Figure 6. It distributes traffic from a 327 number of RTP media sources, MS1 to MSm. Figure 6 also depicts the 328 feedback part of the SSM RTP session using unicast feedback [RFC5760] 329 from a number of receivers R1..Rn that sends feedback to a Feedback 330 Target (FT) and eventually aggregated and distributed to the group. 332 The use of SSM makes it more difficult to inject traffic into the 333 multicast group, but not impossible. Source authentication 334 requirements apply for SSM sessions too, and a non-symmetric 335 verification of who sent the RTP and RTCP packets is needed. 337 The SSM communication channel needs to be securely established and 338 keyed. In addition one also have the individual unicast feedback 339 that also needs to be secured. 341 +-----+ +-----+ +-----+ 342 | MS1 | | MS2 | .... | MSm | 343 +-----+ +-----+ +-----+ 344 ^ ^ ^ 345 | | | 346 V V V 347 +---------------------------------+ 348 | Distribution Source | 349 +--------+ | 350 | FT Agg | | 351 +--------+------------------------+ 352 ^ ^ | 353 : . | 354 : +...................+ 355 : | . 356 : / \ . 357 +------+ / \ +-----+ 358 | FT1 |<----+ +----->| FT2 | 359 +------+ / \ +-----+ 360 ^ ^ / \ ^ ^ 361 : : / \ : : 362 : : / \ : : 363 : : / \ : : 364 : ./\ /\. : 365 : /. \ / .\ : 366 : V . V V . V : 367 +----+ +----+ +----+ +----+ 368 | R1 | | R2 | ... |Rn-1| | Rn | 369 +----+ +----+ +----+ +----+ 371 Figure 6: SSM-based RTP session with Unicast Feedback 373 3. Security Options 375 This section provides an overview of a number of currently defined 376 security mechanisms that can be used with RTP. 378 3.1. Secure RTP 380 The Secure RTP (SRTP) protocol [RFC3711] is one of the most commonly 381 used mechanisms to provide confidentiality, integrity protection and 382 source authentication for RTP. SRTP was developed with RTP header 383 compression and third party monitors in mind. Thus the RTP header is 384 not encrypted in RTP data packets, and the first 8 bytes of the first 385 RTCP packet header in each compound RTCP packet are not encrypted. 386 The entirity of RTP packets and compound RTCP packets are integrity 387 protected. This allows RTP header compression to work, and lets 388 third party monitors determine what RTP traffic flows exist based on 389 the SSRC fields, but protects the sensitive content. 391 The source authentication guarantees provided by SRTP are highly 392 dependent on the cryptographic transform and key-management scheme 393 used. In some cases all a receiver can determine is whether the 394 packets come from someone in the group security context, and not what 395 group member send the packets. Thus, the source authentication 396 guarantees depend also on the session topology. Some cryptographic 397 transform have stronger authentication properties which can guarantee 398 a given source, even over a multi-party session, e.g. those based on 399 TESLA [RFC4383]. 401 SRTP can easily be extended with additional cryptographic transforms. 402 At the time of this writing, the following transforms are defined or 403 under definition: 405 AES CM and HMAC-SHA-1: AES Counter Mode encryption with 128 bits 406 keys combined with 128 bits keyed HMAC-SHA1 using 80 or 32 bits 407 authentication tags are the default cryptographic transform which 408 need to be supported. Defined in SRTP [RFC3711]. 410 AES-f8 and HMAC-SHA-1: AES f8 mode encryption with 128 bits keys 411 combined with keyed HMAC-SHA1 using 80 or 32 bits authentication. 412 Defined in SRTP [RFC3711]. 414 TESLA: As a complement to the regular symmetric keyed authentication 415 transforms, like HMAC-SHA1. The TESLA based authentication scheme 416 can provide per-source authentication in some group communication 417 scenarios. The downside is need for buffering the packets for a 418 while before authenticity can be verified. The TESLA transform 419 for SRTP is defined in [RFC4383]. 421 SEED: An Korean national standard cryptographic transform that is 422 defined to be used with SRTP in [RFC5669]. It has three modes, 423 one using SHA-1 authentication, one using Counter with CBC-MAC, 424 and finally one using Galois Counter mode. 426 ARIA: An Korean block cipher [I-D.ietf-avtcore-aria-srtp], that 427 supports 128, 192 and 256 bits keys. It also has three modes, 428 Counter mode where combined with HMAC-SHA1 with 80 or 32 bits 429 authentication tags, Counter mode with CBC-MAC and Galois Counter 430 mode. It also defines a different key derivation function than 431 the AES based. 433 AES-192 and AES-256: cryptographic transforms for SRTP based on AES- 434 192 and AES-256 counter mode encryption and 160-bit keyed HMAC- 435 SHA1 with 80 and 32 bits authentication tags for authentication. 436 Thus providing 192 and 256 bits encryption keys and NSA Suite B 437 included cryptographic transforms. Defined in [RFC6188]. 439 AES-GCM: There is also ongoing work to define AES-GCM (Galois 440 Counter Mode) and AES-CCM (Counter with CBC) authentication for 441 AES-128 and AES-256. This authentication is included in the 442 cipher text which becomes expanded with the length of the 443 authentication tag instead of using the SRTP authentication tag. 444 This is defined in [I-D.ietf-avtcore-srtp-aes-gcm]. 446 [RFC4771] defines a variant of the authentication tag that enables a 447 receiver to obtain the Roll over Counter for the RTP sequence number 448 that is part of the Initialization vector (IV) for many cryptographic 449 transforms. This enables quicker and easier options for joining a 450 long lived secure RTP group, for example a broadcast session. 452 RTP header extensions are in normally carried in the clear and only 453 integrity protected in SRTP. This can be problematic in some cases, 454 so [I-D.ietf-avtcore-srtp-encrypted-header-ext] defines an extension 455 to also encrypt selected header extensions. 457 SRTP does not contain an integrated key-management solution, and 458 instead relies on an external key management protocol. There are 459 several protocols that can be used. The following sections outline 460 some popular schemes. 462 3.1.1. Key Management for SRTP: DTLS-SRTP 464 A Datagram Transport Layer Security extension exists for establishing 465 SRTP keys [RFC5763][RFC5764]. This extension provides secure key- 466 exchange between two peers, including perfect forward secrecy and 467 enabling binding strong identity verification to an end-point. The 468 default key generation will generate a key that contains material 469 contributed by both peers. The key-exchange happens in the media 470 plane directly between the peers. The common key-exchange procedures 471 will take two round trips assuming no losses. TLS resumption can be 472 used when establishing additional media streams with the same peer, 473 used reducing the setup time to one RTT. 475 DTLS-SRTP key management can use the signalling protocol in three 476 ways. First, to agree on using DTLS-SRTP for media security. 477 Secondly, to determine the network location (address and port) where 478 each side is running an DTLS listener to let the parts perform the 479 key-management handshakes that generate the keys used by SRTP. 480 Finally, to exchange hashes of each sides certificates to enable each 481 side to verify that they have connected to the by signalling 482 indicated port and not a man in the middle. That way enabling some 483 binding between the key-exchange and the signalling. This usage is 484 well defined for SIP/SDP in [RFC5763], and in most cases can be 485 adopted for use with other bi-directions signalling solutions. 487 3.1.2. Key Management for SRTP: MIKEY 489 Multimedia Internet Keying (MIKEY) [RFC3830] is a keying protocol 490 that has several modes with different properties. MIKEY can be used 491 in point-to-point applications using SIP and RTSP (e.g., VoIP calls), 492 but is also suitable for use in broadcast and multicast applications, 493 and centralized group communications. 495 MIKEY can establish multiple security contexts or cryptographic 496 sessions with a single message. It is possible to use in scenarios 497 where one entity generates the key and needs to distribute the key to 498 a number of participants. The different modes and the resulting 499 properties are highly dependent on the cryptographic method used to 500 establish the Traffic Generation Key (TGK) that is used to derive the 501 keys actually used by the security protocol, like SRTP. 503 MIKEY has the following modes of operation: 505 Pre-Shared Key: Uses a pre-shared secret for symmetric key crypto 506 used to secure a keying message carrying the already generated 507 TGK. This system is the most efficient from the perspective of 508 having small messages and processing demands. 510 Public Key encryption: Uses a public key crypto to secure a keying 511 message carrying the already generated TGK. This is more resource 512 consuming but enables scalable systems. It does require a public 513 key infrastructure to enable verification. 515 Diffie-Hellman: Uses Diffie-Hellman key-agreement to generate the 516 TGK, thus providing perfect forward secrecy. The downside is 517 increased resource consumption in bandwidth and processing. This 518 method can't be used to establish group keys as each pair of peers 519 performing the MIKEY exchange will establish different keys. 521 HMAC-Authenticated Diffie-Hellman: [RFC4650] defines a variant of 522 the Diffie-Hellman exchange that uses a pre-shared key in a keyed 523 HMAC to verify authenticity of the keying material instead of a 524 digital signature as in the previous method. This method is still 525 restricted to point-to-point usage. 527 RSA-R: MIKEY-RSA in Reverse mode [RFC4738] is a variant of the 528 public key method which doesn't rely on the initiator of the key- 529 exchange knowing the responders certificate. This methods lets 530 both the initiator and the responder to specify the TGK material 531 depending on use case. Usage of this mode requires one round trip 532 time. 534 TICKET: [RFC6043] is a MIKEY extension using trusted centralized key 535 management service and tickets, like Kerberos. 537 IBAKE: [RFC6267] uses a key management services (KMS) but with lower 538 demand on the KMS. If provides both perfect forward and backwards 539 secrecy. 541 SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption in MIKEY. 542 Based on Identity based Public Key Cryptography to establish a 543 shared secret value and certificate less signatures to provide 544 source authentication. It features include simplex transmission, 545 scalability, low-latency call setup, and support for secure 546 deferred delivery. 548 MIKEY messages has several different defined transports. [RFC4567] 549 defines how MIKEY messages can be embedded in general SDP for usage 550 with the signalling protocols SIP, SAP and RTSP. There also exist an 551 3GPP defined usage of MIKEY that sends MIKEY messages directly over 552 UDP to key the receivers of Multimedia Broadcast and Multicast 553 Service (MBMS) [3GPP.33.246]. 555 Based on the many choices it is important to consider the properties 556 needed in ones solution and based on that evaluate which modes that 557 are candidates for ones usage. More information on the applicability 558 of the different MIKEY modes can be found in [RFC5197]. 560 3.1.3. Key Management for SRTP: Security Descriptions 562 [RFC4568] provides a keying solution based on sending plain text keys 563 in SDP [RFC4566]. It is primarily used with SIP and SDP Offer/ 564 Answer, and is well-defined in point to point sessions where each 565 side declares its own unique key. Using Security Descriptions to 566 establish group keys is less well defined, and can have security 567 issues as the SSRC uniqurness property can't be guaranteed. 569 Since keys are transported in plain text in SDP, they can easily be 570 intercepted unless the SDP carrying protocol provides strong end-to- 571 end confidentiality and authentication guarantees. This is not the 572 common use of security descriptions with SIP, where instead hop by 573 hop security is provided between signalling nodes using TLS. This 574 still leaves the keying material sensitive to capture by the 575 traversed signalling nodes. Thus in most cases the security 576 properties of security description are weak. 578 3.1.4. Key Management for SRTP: Encrypted Key Transport 580 Encrypted Key Transport (EKT) [I-D.ietf-avtcore-srtp-ekt] is an SRTP 581 extension that enables group keying despite using a keying mechanism 582 that can't support group keys, like DTLS-SRTP. It is designed for 583 centralized conferencing, but can also be used in sessions where an 584 end-points connect to a conference bridge or a gateway, and need to 585 be provisioned with the keys each participant on the bridge or 586 gateway uses to avoid decryption encryption cycles on the bridge or 587 gateway. 589 The mechanism is based on establishing an additional EKT key which 590 everyone uses to protect their actual session key. The actual 591 session key is sent in a expanded authentication tag to the other 592 session participants. This key are only sent occasionally or 593 periodically depending on use cases depending on what requirements 594 exist for timely delivery or notification on when the key is needed 595 by someone. 597 3.1.5. Key Management for SRTP: Other systems 599 There exist at least one additional SRTP key-management system, 600 namely ZRTP [RFC6189]. This was a candidate for IETF standardization 601 that wasn't chosen, and was published for information instead. Its 602 properties are somewhat similar to DTLS. 604 There might exist additional non-IETF defined solutions. 606 3.2. RTP Legacy Confidentiality 608 Section 9 of the RTP standard [RFC3550] defines a DES or 3DES based 609 encryption of RTP and RTCP packets. This mechanism is keyed using 610 plain text keys in SDP [RFC4566] using the "k=" SDP field. This 611 method of providing confidentiality has extremely weak security 612 properties and is not to be used. 614 3.3. IPsec 616 IPsec [RFC4301] can be used independent of mode to protect RTP and 617 RTCP packets in transit from one network interface to another. This 618 can be sufficient when the network interfaces have a direct relation, 619 or in a secured environment where it can be controlled who can read 620 the packets from those interfaces. 622 The main concern with using IPsec to protect RTP traffic is that in 623 most cases using a VPN approach that terminates the security 624 association at some node prior to the RTP end-point leaves the 625 traffic vulnerable to attack between the VPN termination node and the 626 end-point. Thus usage of IPsec requires careful thought and design 627 of its usage so that it really meets the security goals. A important 628 question is how one ensure the IPsec terminating peer and the 629 ultimate destination is the same. 631 IPsec with RTP is more commonly used as security solution between 632 central nodes in an infrastructure that exchanges many RTP sessions 633 and media streams between the peers. The establishment of a secure 634 tunnel between these peers minimizes the key-management overhead 635 between these two boxes. 637 3.4. DTLS 639 Datagram Transport Layer Security (DTLS) [RFC6347] can provide point 640 to point security for RTP flows. The two peers would establish an 641 DTLS association between each other, including the possibility to do 642 certificate-based source authentication when establishing the 643 association. All RTP and RTCP packets flowing will be protected by 644 this DTLS association. 646 Note: using DTLS is different to using DTLS-SRTP key management. 647 DTLS-SRTP has the core key-management steps in common with DTLS, but 648 DTLS-SRTP uses SRTP for the per packet security operations, while 649 DTLS uses the normal datagram TLS data protection. When using DTLS, 650 RTP and RTCP packets are completely encrypted with no headers in the 651 clear, while DTLS-SRTP leaves the headers in the clear. 653 DTLS can use similar techniques to those available for DTLS-SRTP to 654 bind a signalling side agreement to communicate to the certificates 655 used by the end-point when doing the DTLS handshake. This enables 656 use without having a certificate based trust chain to a trusted 657 certificate root. 659 3.5. TLS over TCP 661 When RTP is sent over TCP [RFC4571] it can also be sent over TLS over 662 TCP [RFC4572], using TLS to provide point to point security services. 663 The security properties TLS provides are confidentiality, integrity 664 protection and possible source authentication if the client or server 665 certificates are verified and provide a usable identity. When used 666 in multi-party scenarios using a central node for media distribution, 667 the security provide is only between then central node and the peers, 668 so the security properties for the whole session are dependent on 669 what trust one can place in the central node. 671 3.6. Payload-only Security Mechanisms 673 Mechanisms have been defined that encrypt only the payload of the RTP 674 packets, and leave the RTP headers and RTCP in the clear. There are 675 several reasons why this might be appropriate, but a common rationale 676 is to ensure that the content stored in RTP hint tracks in RTSP 677 streaming servers has the media content in a protected format that 678 cannot be read by the streaming server (this is mostly done in the 679 context of Digital Rights Management). These approaches then uses a 680 key-management solution between the rights provider and the consuming 681 client to deliver the key used to protect the content, usually after 682 the appropriate method for charging has happened, and do not include 683 the media server in the security context. Such methods have several 684 security weaknesses such the fact that the same key is handed out to 685 a potentially large group of receiving clients, increasing the risk 686 of a leak. 688 Use of this type of solution can be of interest in environments that 689 allow middleboxes to rewrite the RTP headers and select what streams 690 that are delivered to an end-point (e.g., some types of centralised 691 video conference systems). The advantage of encrypting and possibly 692 integrity protecting the payload but not the headers is that the 693 middlebox can't eavesdrop on the media content, but can still provide 694 stream switching functionality. The downside of such a system is 695 that it likely needs two levels of security: the payload level 696 solution to provide confidentiality and source authentication, and a 697 second layer with additional transport security ensuring source 698 authentication and integrity of the RTP headers associated with the 699 encrypted payloads. This can also results in the need to have two 700 different key-management systems as the entity protecting the packets 701 and payloads are different with different set of keys. 703 The aspect of two tiers of security are present in ISMAcryp (see 704 Section 3.6.1) and the deprecated 3GPP Packet Based Streaming Service 705 Annex.K [3GPP.23.234] solution. 707 3.6.1. ISMA Encryption and Authentication 709 The Internet Streaming Media Alliance (ISMA) has defined ISMA 710 Encryption and Authentication 2.0 [ISMACrypt2]. This specification 711 defines how one encrypts and packetizes the encrypted application 712 data units (ADUs) in an RTP payload using the MPEG-4 Generic payload 713 format [RFC3640]. The ADU types that are allowed are those that can 714 be stored as elementary streams in an ISO Media File format based 715 file. ISMAcryp uses SRTP for packet level integrity and source 716 authentication from a streaming server to the receiver. 718 Key-management for a ISMACryp based system can be achieved through 719 Open Mobile Alliance (OMA) Digital Rights Management 2.0 [OMADRMv2], 720 for example. 722 4. Securing RTP Applications 724 In the following we provide guidelines for how to choose appropriate 725 security mechanisms for RTP applications. 727 4.1. Application Requirements 729 This section discusses a number of application requirements that need 730 be considered. An application designer choosing security solutions 731 requires a good understanding of what level of security is needed and 732 what behaviour they strive to achieve. 734 4.1.1. Confidentiality 736 When it comes to confidentiality of an RTP session there are several 737 aspects to consider: 739 Probability of compromise: When using encryption to provide media 740 confidentiality, it is necessary to have some rough understanding 741 of the security goal and how long one expect the protected content 742 remain confidential. From that, one can determine what encryption 743 algorithm is to be used from the set of available transforms. 745 Potential for other leakage: RTP based security in most of its forms 746 simply wraps RTP and RTCP packets into cryptographic containers. 747 This commonly means that the size of the original RTP payload, and 748 details of the RTP and RTCP headers, are visible to observers of 749 the protected packet flow. This can provide information to those 750 observers. A well documented case is the risk with variable bit- 751 rate speech codecs that produce different sized packets based on 752 the speech input [RFC6562]. Potential threats such as these need 753 to be considered and, if they are significant, then restrictions 754 will be needed on mode choices in the codec, or additional padding 755 will need to be added to make all packets equal size and remove 756 the informational leakage. 758 Another case is RTP header extensions. If SRTP is used, header 759 extensions are normally not protected by the security mechanism 760 protecting the RTP payload. If the header extension carries 761 information that is considered sensitive, then the application 762 needs to be modified to ensure that mechanisms used to protect 763 against such information leakage are employed. 765 Who has access: When considering the confidentiality properties of a 766 system, it is important to consider where the media handled in the 767 clear. For example, if the system is based on an RTP mixer that 768 needs the keys to decrypt the media, process, and repacketize it, 769 then is the mixer providing the security guarantees expected by 770 the other parts of the system? Furthermore, it is important to 771 consider who has access to the keys, and are the keys stored or 772 kept somewhere? The policies for the handling of the keys, and 773 who can access the keys, need to be considered along with the 774 confidentiality goals. 776 As can be seen the actual confidentiality level has likely more to do 777 with the application's usage of centralized nodes, and the details of 778 the key-management solution chosen, than with the actual choice of 779 encryption algorithm (although, of course, the encryption algorithm 780 needs to be chosen appropriately for the desired security level). 782 4.1.2. Integrity 784 Protection against modification of content by a third party, or due 785 to errors in the network, is another factor to consider. The first 786 aspect that one consider is what resilience one has against 787 modifications to the content. This can affect what cryptographic 788 algorithm is used, and the length of the integrity tags. However 789 equally, important is to consider who is providing the integrity 790 assertion, what is the source of the integrity tag, and what are the 791 risks of modifications happening prior to that point where protection 792 is applied? RTP applications that rely on central nodes need to 793 consider if hop-by-hop integrity is acceptable, or if true end-to-end 794 integrity protection is needed? Is it important to be able to tell 795 if a middlebox has modified the data? There are some uses of RTP 796 that require trusted middleboxes that can modify the data in a way 797 that doesn't break integrity protection as seen by the receiver, for 798 example local advertisment insertion in IPTV systems; there are also 799 uses where it is essential that such in-network modification be 800 detectable. RTP can support both, with appropriate choices of 801 security mechanisms. 803 Integrity of the data is commonly closely tied to the question of 804 source authentication. That is, it becomes important to know who 805 makes an integrity assertion for the data. 807 4.1.3. Source Authentication 809 Source authentication is about determining who sent a particular RTP 810 or RTCP packet. It is normally closely tied with integrity, since 811 you also want to ensure that what you received is what the claimed 812 source really sent, so source authentication without integrity is not 813 particularly useful. In similar way, although not as definitive, is 814 that integrity without source authentication is also not particular 815 useful: you need to know who claims this packet wasn't changed. 817 Source authentication can be asserted in several different ways: 819 Base level: Using cryptographic mechanisms that give authentication 820 with some type of key-management provides an implicit method for 821 source authentication. Assuming that the mechanism has sufficient 822 strength to not be circumvented in the time frame when you would 823 accept the packet as valid, it is possible that assert the source 824 authenticated statement that this message is most probably from 825 someone that has the cryptographic key to this communication. 827 What that assertion actually means is highly dependent on the 828 application, and how it handles the keys. In an application where 829 the key-handling is limited to two peers, this can form a basis 830 for a trust relationship to the level that you can state as the 831 traffic is authenticated and matching this particular context, it 832 is coming either from me or from my peer (and I trust that neither 833 has shared the key with anyone else). However, in a multi-party 834 scenario where security contexts are shared among participants, 835 most base-level authentication solution can't even assert that 836 this packet is from the same source as the previous packet. 838 Binding the Source: A step up in the assertion that can be done in 839 base-level systems is to tie the signalling to the key-exchange. 840 Here, the goal is to be at least be able to assert that the sender 841 of the packets is the same entity that I have established the 842 session with. How feasible this is depends on the properties of 843 the key-management system used, the ability to tie the signalling 844 to a particular peer, and what trust you place on the different 845 nodes involved. 847 For example, consider a point to point communication system that 848 use DTLS-SRTP using self-signed certificates for key-management, 849 and SIP for signalling. In such a system the end-points for the 850 DTLS-SRTP handshake have securely established keys that are not 851 visible to the signalling nodes. However, as the certificates 852 used by DTLS is not bound to any PKI they can't be verified. 853 Instead, hashes over the certificate are sent over the signalling 854 path. If the signalling can be trusted not to collaborate on 855 performaning a man in the middle attack by modifying the hashes, 856 then the end-points can verify that they have reached the peer 857 they are doing signalling with. 859 Using Identities: If the applications have access to a system that 860 can provide verifiable identities, then the source authentication 861 can be bound to that identity. For example, in a point-to-point 862 communication even symmetric key crypto, where the key-management 863 can assert that the key has only been exchanged with a particular 864 identity, can provide a strong assertion about who is sending the 865 traffic. 867 Note that all levels of the system much have matching capability 868 to assert identity. Having the signalling assert that you include 869 a particular identity in a multi-party communication session where 870 the key-management systems establish keys in a way that one can 871 assert that only the given identity has gotten the key. Using a 872 authentication mechanism build on a group key and otherwise can't 873 provide any assertion who sent the traffic than anyone that got 874 the key provides no strong assertability on the media level than: 875 Someone that has gotten the security context (key) sent this 876 traffic. 878 4.1.4. Identity 880 As seen in the previous section, having an identity provider system 881 can benefit the applications by enabling them to do strong assertion 882 between identity and the actual media source. Therefore, the need 883 for identity needs to be considered. However, having identity 884 systems might not be suitable for all types of application, since 885 they require trusted infrastructure. 887 4.1.5. Privacy 889 RTP applications need to consider what privacy goals they have. As 890 RTP applications communicate directly between peers in many cases, 891 the IP addresses of any communication peer will be available. The 892 main privacy concern with IP addresses is related to geographical 893 location and the possibility to track a user of an end-point. The 894 main way of avoid such concerns is the introduction of relay or 895 centralized media mixers or forwarders that hides the address of a 896 peer from any other peer. The security and trust placed in these 897 relays obviously needs to be carefully considered. 899 RTP itself can contribute to enabling a particular user to be tracked 900 between communication sessions if the CNAME is generated according to 901 the RTP specification in the form of user@host. Such RTCP CNAMEs are 902 likely long term stable over multiple sessions, allowing tracking of 903 users. This can be desirable for long-term fault tracking and 904 diagnosis, but clearly has privacy implications. Instead 905 cryptographically random ones could be used as defined by Random 906 algorithm for RTP CNAME generation 907 [I-D.rescorla-avtcore-random-cname]. 909 If there exist privacy goals, these need to be considered, and the 910 system designed with them in mind. In addition certain RTP features 911 might have to be configured to safeguard privacy, or have 912 requirements on how the implementation is done. 914 4.2. Application Structure 916 When it comes to RTP security, the most appropriate solution is often 917 highly dependent on the topology of the communication session. The 918 signalling also impacts what information can be provided, and if this 919 can be instance specific, or common for a group. In the end the key- 920 management system will highly affect the security properties achieved 921 by the application. At the same time, the communication structure of 922 the application limits what key management methods are applicable. 923 As different key-management have different requirements on underlying 924 infrastructure it is important to take that aspect into consideration 925 early in the design. 927 4.3. Interoperability 929 Few RTP applications exist as independent applications that never 930 interoperate with anything else. Rather, they enable communication 931 with a potentially large number of other systems. To minimize the 932 number of security mechanisms that need to be implemented, it is 933 important to consider if one can use the same security mechanisms as 934 other applications. This can also reduce the problems of determining 935 what security level is actually negotiated in a particular session. 937 The desire to be interoperable can in some cases be in conflict with 938 the security requirements determined for an application. To meet the 939 security goals, it might be necessary to sacrifice interoperability. 940 Alternatively, one can implement multiple security mechanisms, but 941 then end up with an issue of ensuring that the user understands what 942 it means to use a particular security level. In addition, the 943 application can then become vulnerable to bid-down attack. 945 5. Examples 947 In the following we describe a number of example security solutions 948 for RTP using applications, services or frameworks. These examples 949 are provided to show the choices that can be made. They are not 950 normative recommendations for security. 952 5.1. Media Security for SIP-established Sessions using DTLS-SRTP 954 The IETF evaluated media security for RTP sessions established using 955 point-to-point SIP sessions in 2009. A number of requirements were 956 determined, and based on those, the existing solutions for media 957 security and especially the keying methods were analysed, and the 958 resulting requirements and analysis were published in [RFC5479]. 959 Based on this analysis, and the working group discussion, DTLS-SRTP 960 was determined to be the best solution, and the specifications were 961 finalized. 963 The security solution for SIP using DTLS-SRTP is defined in the 964 Framework for Establishing a Secure Real-time Transport Protocol 965 (SRTP) Security Context Using Datagram Transport Layer Security 966 (DTLS) [RFC5763]. On a high level it uses SIP with SDP offer/answer 967 procedures to exchange the network addresses where the server end- 968 point will have a DTLS-SRTP enable server running. The SIP 969 signalling is also used to exchange the fingerprints of the 970 certificate each end-point will use in the DTLS establishment 971 process. When the signalling is sufficiently completed the DTLS-SRTP 972 client performs DTLS handshakes and establishes SRTP session keys. 973 The clients also verify the fingerprints of the certificates to 974 verify that no man in the middle has inserted themselves into the 975 exchange. 977 At the basic level DTLS has a number of good security properties. 978 For example, to enable a man in the middle someone in the signalling 979 path needs to perform an active action and modify the signalling 980 message. There also exist a solution that enables the fingerprints 981 to be bound to identities established by the first proxy for each 982 user [RFC4916]. That reduces the number of nodes the connecting user 983 UA has to trust to the first hop proxy, rather than the full 984 signalling path. 986 5.2. Media Security for WebRTC Sessions 988 Web Real-Time Communication [I-D.ietf-rtcweb-overview] is solution 989 providing web-application with real-time media directly between 990 browsers. The RTP transported real-time media is protected using a 991 mandatory to use application of SRTP. The keying of SRTP is done 992 using DTLS-SRTP. The security configuration is further defined in 993 the WebRTC Security Architecture [I-D.ietf-rtcweb-security-arch]. 995 The peers hash of their certificates are provided to a Javascript 996 application that is part of a client server system providing 997 rendezvous services for the ones a given peer wants to communicate 998 with. Thus the handling of the hashes between the peers is not well 999 defined. It becomes a matter of trust in the application. But 1000 unless the application and its server is intending to compromise the 1001 communication security they can provide a secure and integrity 1002 protected exchange of the certificate hashes thus preventing any man- 1003 in-the-middle (MITM) to insert itself in the key-exchange. 1005 The web application still have the possibility to insert a MITM. 1006 That unless one uses a Identity provider and the proposed identity 1007 solution [I-D.rescorla-rtcweb-generic-idp]. In this solution the 1008 Identity Provider which is a third party to the web-application signs 1009 the DTLS-SRTP hash combined with a statement on which user identity 1010 that has been used to sign the hash. The receiver of such a Identity 1011 assertion then independently verifies the user identity to ensure 1012 that it is the identity it intended to communicate and that the 1013 cryptographic assertion holds. That way a user can be certain that 1014 the application also can't perform an MITM and that way acquire the 1015 keys to the media communication. 1017 In the development of WebRTC there has also been high attention on 1018 privacy question. The main concerns that has been raised and are at 1019 all related to RTP are: 1021 Location Disclosure: As ICE negotiation provides IP addresses and 1022 ports for the browser, this leaks location information in the 1023 signalling to the peer. To prevent this one can block the usage 1024 of any ICE candidate that isn't a relay candidate, i.e. where the 1025 IP and port provided belong to the service providers media traffic 1026 relay. 1028 Prevent tracking between sessions: RTP CNAMEs and DTLS-SRTP 1029 certificates is information that could possibly be re-used between 1030 session instances. Thus to prevent tracking the same information 1031 can't be re-used between different communication sessions. 1033 Note: The above cases are focused on providing privacy towards other 1034 parties than the web service. 1036 5.3. 3GPP Packet Based Streaming Service (PSS) 1038 To be written: 1040 5.4. IPTV 1042 To be written: 1044 6. IANA Considerations 1046 This document makes no request of IANA. 1048 Note to RFC Editor: this section can be removed on publication as an 1049 RFC. 1051 7. Security Considerations 1053 This entire document is about security. Please read it. 1055 8. Acknowledgements 1057 We thank the IESG for their careful review of 1058 [I-D.ietf-avt-srtp-not-mandatory] which led to the writing of this 1059 memo. 1061 9. Informative References 1063 [3GPP.23.234] 1064 3GPP, "Technical Specification Group Services and System 1065 Aspects; Transparent end-to-end Packet-switched Streaming 1066 Service (PSS); Protocols and codecs", 3GPP TS 26.234 1067 8.4.0, September 2009. 1069 [3GPP.33.246] 1070 3GPP, "3G Security; Security of Multimedia Broadcast/ 1071 Multicast Service (MBMS)", 3GPP TS 33.246 10.0.0, 1072 December 2010. 1074 [I-D.ietf-avt-srtp-not-mandatory] 1075 Perkins, C. and M. Westerlund, "Why RTP Does Not Mandate a 1076 Single Security Mechanism", 1077 draft-ietf-avt-srtp-not-mandatory-10 (work in progress), 1078 July 2012. 1080 [I-D.ietf-avtcore-aria-srtp] 1081 Kim, W., Lee, J., Kim, D., Park, J., and D. Kwon, "The 1082 ARIA Algorithm and Its Use with the Secure Real-time 1083 Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-00 1084 (work in progress), May 2012. 1086 [I-D.ietf-avtcore-srtp-aes-gcm] 1087 McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated 1088 Encryption in Secure RTP (SRTP)", 1089 draft-ietf-avtcore-srtp-aes-gcm-03 (work in progress), 1090 September 2012. 1092 [I-D.ietf-avtcore-srtp-ekt] 1093 McGrew, D., Wing, D., and K. Fischer, "Encrypted Key 1094 Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00 1095 (work in progress), July 2012. 1097 [I-D.ietf-avtcore-srtp-encrypted-header-ext] 1098 Lennox, J., "Encryption of Header Extensions in the Secure 1099 Real-Time Transport Protocol (SRTP)", 1100 draft-ietf-avtcore-srtp-encrypted-header-ext-02 (work in 1101 progress), July 2012. 1103 [I-D.ietf-rtcweb-overview] 1104 Alvestrand, H., "Overview: Real Time Protocols for Brower- 1105 based Applications", draft-ietf-rtcweb-overview-04 (work 1106 in progress), June 2012. 1108 [I-D.ietf-rtcweb-security-arch] 1109 Rescorla, E., "RTCWEB Security Architecture", 1110 draft-ietf-rtcweb-security-arch-03 (work in progress), 1111 July 2012. 1113 [I-D.rescorla-avtcore-random-cname] 1114 Rescorla, E., "Random algorithm for RTP CNAME generation", 1115 draft-rescorla-avtcore-random-cname-00 (work in progress), 1116 July 2012. 1118 [I-D.rescorla-rtcweb-generic-idp] 1119 Rescorla, E., "RTCWEB Generic Identity Provider 1120 Interface", draft-rescorla-rtcweb-generic-idp-01 (work in 1121 progress), March 2012. 1123 [ISMACrypt2] 1124 "ISMA Encryption and Authentication, Version 2.0 release 1125 version", November 2007. 1127 [OMADRMv2] 1128 Open Mobile Alliance, "OMA Digital Rights Management 1129 V2.0", July 2008. 1131 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1132 RFC 1112, August 1989. 1134 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 1135 Engineering Task Force Standard Protocols", BCP 61, 1136 RFC 3365, August 2002. 1138 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1139 Jacobson, "RTP: A Transport Protocol for Real-Time 1140 Applications", STD 64, RFC 3550, July 2003. 1142 [RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., 1143 and P. Gentric, "RTP Payload Format for Transport of 1144 MPEG-4 Elementary Streams", RFC 3640, November 2003. 1146 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1147 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1148 RFC 3711, March 2004. 1150 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1151 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1152 August 2004. 1154 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1155 Internet Protocol", RFC 4301, December 2005. 1157 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 1158 Stream Loss-Tolerant Authentication (TESLA) in the Secure 1159 Real-time Transport Protocol (SRTP)", RFC 4383, 1160 February 2006. 1162 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1163 Description Protocol", RFC 4566, July 2006. 1165 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 1166 Carrara, "Key Management Extensions for Session 1167 Description Protocol (SDP) and Real Time Streaming 1168 Protocol (RTSP)", RFC 4567, July 2006. 1170 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1171 Description Protocol (SDP) Security Descriptions for Media 1172 Streams", RFC 4568, July 2006. 1174 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1175 and RTP Control Protocol (RTCP) Packets over Connection- 1176 Oriented Transport", RFC 4571, July 2006. 1178 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1179 Transport Layer Security (TLS) Protocol in the Session 1180 Description Protocol (SDP)", RFC 4572, July 2006. 1182 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1183 IP", RFC 4607, August 2006. 1185 [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for 1186 Multimedia Internet KEYing (MIKEY)", RFC 4650, 1187 September 2006. 1189 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 1190 RSA-R: An Additional Mode of Key Distribution in 1191 Multimedia Internet KEYing (MIKEY)", RFC 4738, 1192 November 2006. 1194 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1195 Transform Carrying Roll-Over Counter for the Secure Real- 1196 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1198 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 1199 Protocol (SIP)", RFC 4916, June 2007. 1201 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 1202 January 2008. 1204 [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of 1205 Various Multimedia Internet KEYing (MIKEY) Modes and 1206 Extensions", RFC 5197, June 2008. 1208 [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 1209 "Requirements and Analysis of Media Security Management 1210 Protocols", RFC 5479, April 2009. 1212 [RFC5669] Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The 1213 SEED Cipher Algorithm and Its Use with the Secure Real- 1214 Time Transport Protocol (SRTP)", RFC 5669, August 2010. 1216 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1217 Protocol (RTCP) Extensions for Single-Source Multicast 1218 Sessions with Unicast Feedback", RFC 5760, February 2010. 1220 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1221 for Establishing a Secure Real-time Transport Protocol 1222 (SRTP) Security Context Using Datagram Transport Layer 1223 Security (DTLS)", RFC 5763, May 2010. 1225 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1226 Security (DTLS) Extension to Establish Keys for the Secure 1227 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1229 [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based 1230 Modes of Key Distribution in Multimedia Internet KEYing 1231 (MIKEY)", RFC 6043, March 2011. 1233 [RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure 1234 RTP", RFC 6188, March 2011. 1236 [RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 1237 Path Key Agreement for Unicast Secure RTP", RFC 6189, 1238 April 2011. 1240 [RFC6267] Cakulev, V. and G. Sundaram, "MIKEY-IBAKE: Identity-Based 1241 Authenticated Key Exchange (IBAKE) Mode of Key 1242 Distribution in Multimedia Internet KEYing (MIKEY)", 1243 RFC 6267, June 2011. 1245 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1246 Security Version 1.2", RFC 6347, January 2012. 1248 [RFC6509] Groves, M., "MIKEY-SAKKE: Sakai-Kasahara Key Encryption in 1249 Multimedia Internet KEYing (MIKEY)", RFC 6509, 1250 February 2012. 1252 [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of 1253 Variable Bit Rate Audio with Secure RTP", RFC 6562, 1254 March 2012. 1256 Authors' Addresses 1258 Magnus Westerlund 1259 Ericsson 1260 Farogatan 6 1261 SE-164 80 Kista 1262 Sweden 1264 Phone: +46 10 714 82 87 1265 Email: magnus.westerlund@ericsson.com 1267 Colin Perkins 1268 University of Glasgow 1269 School of Computing Science 1270 Glasgow G12 8QQ 1271 United Kingdom 1273 Email: csp@csperkins.org