idnits 2.17.1 draft-ietf-avtcore-rtp-security-options-03.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 (May 06, 2013) is 4005 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-12 == Outdated reference: A later version (-06) exists of draft-ietf-avtcore-6222bis-03 == Outdated reference: A later version (-11) exists of draft-ietf-avtcore-aria-srtp-01 == Outdated reference: A later version (-17) exists of draft-ietf-avtcore-srtp-aes-gcm-05 == Outdated reference: A later version (-03) exists of draft-ietf-avtcore-srtp-ekt-00 == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-34 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-06 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-06 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- 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 (~~), 9 warnings (==), 6 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: November 07, 2013 University of Glasgow 6 May 06, 2013 8 Options for Securing RTP Sessions 9 draft-ietf-avtcore-rtp-security-options-03 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 November 07, 2013. 41 Copyright Notice 43 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . 21 87 4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 22 88 4.2. Application Structure . . . . . . . . . . . . . . . . . . 22 89 4.3. Interoperability . . . . . . . . . . . . . . . . . . . . 22 90 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 5.1. Media Security for SIP-established Sessions using DTLS- 92 SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 24 94 5.3. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 25 95 5.4. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 26 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 98 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 99 9. Informative References . . . . . . . . . . . . . . . . . . . 27 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 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. It also 121 attempts to provide indication of actual and intended usage at time 122 of writing as additional input to help with considerations such as 123 interoperability, availability of implementations etc. The guidance 124 provided is not exhaustive, and this memo does not provide normative 125 recommendations. 127 It is important that application developers consider the security 128 goals and requirements for their application. The IETF considers it 129 important that protocols implement, and makes available to the user, 130 secure modes of operation [RFC3365]. Because of the heterogeneity of 131 RTP applications and use cases, however, a single security solution 132 cannot be mandated. Instead, application developers need to select 133 mechanisms that provide appropriate security for their environment. 134 It is strongly encouraged that common mechanisms are used by related 135 applications in common environments. The IETF publishes guidelines 136 for specific classes of applications, so it worth searching for such 137 guidelines. 139 The remainder of this document is structured as follows. Section 2 140 provides additional background. Section 3 outlines the available 141 security mechanisms at the time of this writing, and lists their key 142 security properties and constraints. That is followed by guidelines 143 and important aspects to consider when securing an RTP application in 144 Section 4. Finally, we give some examples of application domains 145 where guidelines for security exist in Section 5. 147 2. Background 149 RTP can be used in a wide variety of topologies, and combinations of 150 topologies, due to it's support for unicast, multicast groups, and 151 broadcast topologies, and the existence of different types of RTP 152 middleboxes. In the following we review the different topologies 153 supported by RTP to understand their implications for the security 154 properties and trust relations that can exist in RTP sessions. 156 2.1. Point to Point Sessions 158 The most basic use case is two directly connected end-points, shown 159 in Figure 1, where A has established an RTP session with B. In this 160 case the RTP security is primarily about ensuring that any third 161 party can't compromise the confidentiality and integrity of the media 162 communication. This requires confidentiality protection of the RTP 163 session, integrity protection of the RTP/RTCP packets, and source 164 authentication of all the packets to ensure no man-in-the-middle 165 attack is taking place. 167 The source authentication can also be tied to a user or an end-points 168 verifiable identity to ensure that the peer knows who they are 169 communicating with. Here the combination of the security protocol 170 protecting the RTP session and its RTP and RTCP traffic and the key- 171 management protocol becomes important in which security statements 172 one can do. 174 +---+ +---+ 175 | A |<------->| B | 176 +---+ +---+ 178 Figure 1: Point to Point Topology 180 2.2. Sessions Using an RTP Mixer 182 An RTP mixer is an RTP session level middlebox that one can build an 183 multi-party RTP based conference around. The RTP mixer might 184 actually perform media mixing, like mixing audio or compositing video 185 images into a new media stream being sent from the mixer to a given 186 participant; or it might provide a conceptual stream, for example the 187 video of the current active speaker. From a security point of view, 188 the important features of an RTP mixer is that it generates a new 189 media stream, and has its own source identifier, and does not simply 190 forward the original media. 192 An RTP session using a mixer might have a topology like that in 193 Figure 2. In this examples, participants A-D each send unicast RTP 194 traffic between themselves and the RTP mixer, and receive a RTP 195 stream from the mixer, comprising a mixture of the streams from the 196 other participants. 198 +---+ +------------+ +---+ 199 | A |<---->| |<---->| B | 200 +---+ | | +---+ 201 | Mixer | 202 +---+ | | +---+ 203 | C |<---->| |<---->| D | 204 +---+ +------------+ +---+ 206 Figure 2: Example RTP Mixer topology 208 A consequence of an RTP mixer having its own source identifier, and 209 acting as an active participant towards the other end-points, is that 210 the RTP mixer needs to be a trusted device that is part of the 211 security context(s) established. The RTP mixer can also become a 212 security enforcing entity. For example, a common approach to secure 213 the topology in Figure 2 is to establish a security context between 214 the mixer and each participant independently, and have the mixer 215 source authenticate each peer. The mixer then ensures that one 216 participant cannot impersonate another. 218 2.3. Sessions Using an RTP Translator 220 RTP translators are middleboxes that provide various levels of in- 221 network media translation and transcoding. Their security properties 222 vary widely, depending on which type of operations they attempt to 223 perform. We identify three different categories of RTP translator: 224 transport translators, gateways, and media transcoders. We discuss 225 each in turn. 227 2.3.1. Transport Translator (Relay) 229 A transport translator [RFC5117] operates on a level below RTP and 230 RTCP. It relays the RTP/RTCP traffic from one end-point to one or 231 more other addresses. This can be done based only on IP addresses 232 and transport protocol ports, with each receive port on the 233 translator can have a very basic list of where to forward traffic. 234 Transport translators also need to implement ingress filtering to 235 prevent random traffic from being forwarded that isn't coming from a 236 participant in the conference. 238 Figure 3 shows an example transport translator, where traffic from 239 any one of the four participants will be forwarded to the other three 240 participants unchanged. The resulting topology is very similar to 241 Any source Multicast (ASM) session (as discussed in Section 2.4), but 242 implemented at the application layer. 244 +---+ +------------+ +---+ 245 | A |<---->| |<---->| B | 246 +---+ | Relay | +---+ 247 | Translator | 248 +---+ | | +---+ 249 | C |<---->| |<---->| D | 250 +---+ +------------+ +---+ 252 Figure 3: RTP relay translator topology 254 A transport translator can often operate without needing to be in the 255 security context, as long as the security mechanism does not provide 256 protection over the transport-layer information. A transport 257 translator does, however, make the group communication visible, and 258 so can complicate keying and source authentication mechanisms. This 259 is further discussed in Section 2.4. 261 2.3.2. Gateway 263 Gateways are deployed when the endpoints are not fully compatible. 264 Figure 4 shows an example topology. The functions a gateway provides 265 can be diverse, and range from transport layer relaying between two 266 domains not allowing direct communication, via transport or media 267 protocol function initiation or termination, to protocol or media 268 encoding translation. The supported security protocol might even be 269 one of the reasons a gateway is needed. 271 +---+ +-----------+ +---+ 272 | A |<---->| Gateway |<---->| B | 273 +---+ +-----------+ +---+ 275 Figure 4: RTP Gateway Topology 277 The choice of security protocol and the details of the gateway 278 function will determine if the gateway needs to be a trusted part of 279 the application security context or not. Many gateways need to be 280 trusted by all peers to perform the translation; in other cases some 281 or all peers might not be aware of the presence of the gateway. The 282 security protocols have different properties depending on the degree 283 of trust and visibility needed. Ensuring communication is possible 284 without trusting the gateway can be strong incentive for accepting 285 different security properties. Some security solutions will be able 286 to detect the gateways as manipulating the media stream, unless the 287 gateway is a trusted device. 289 2.3.3. Media Transcoder 291 A Media transcoder is a special type of gateway device that changes 292 the encoding of the media being transported by RTP. The discussion 293 in Section 2.3.2 applies. A media transcoder alters the media data, 294 and thus needs to be trusted device that is part of the security 295 context. 297 2.4. Any Source Multicast 299 Any Source Multicast [RFC1112] is the original multicast model where 300 any multicast group participant can send to the multicast group, and 301 get their packets delivered to all group members (see Figure 5). 302 This form of communication has interesting security properties, due 303 to the many-to-many nature of the group. Source authentication is 304 important, but all participants in the group security context will 305 have access to the necessary secrets to decrypt and verify integrity 306 of the traffic. Thus use of any symmetric security functions fails 307 if the goal is to separate individual sources within the security 308 context; alternate solutions are needed. 310 +-----+ 311 +---+ / \ +---+ 312 | A |----/ \---| B | 313 +---+ / Multi- \ +---+ 314 + Cast + 315 +---+ \ Network / +---+ 316 | C |----\ /---| D | 317 +---+ \ / +---+ 318 +-----+ 320 Figure 5: Any Source Multicast Group 322 In addition the potential large size of multicast groups creates some 323 considerations for the scalability of the solution and how the key- 324 management is handled. 326 2.5. Source-Specific Multicast 328 Source Specific Multicast [RFC4607] allows only a specific end-point 329 to send traffic to the multicast group. That end-point is labelled 330 the Distribution Source in Figure 6. It distributes traffic from a 331 number of RTP media sources, MS1 to MSm. Figure 6 also depicts the 332 feedback part of the SSM RTP session using unicast feedback [RFC5760] 333 from a number of receivers R1..Rn that sends feedback to a Feedback 334 Target (FT) and eventually aggregated and distributed to the group. 336 The use of SSM makes it more difficult to inject traffic into the 337 multicast group, but not impossible. Source authentication 338 requirements apply for SSM sessions too, and a non-symmetric 339 verification of who sent the RTP and RTCP packets is needed. 341 The SSM communication channel needs to be securely established and 342 keyed. In addition one also have the individual unicast feedback 343 that also needs to be secured. 345 +-----+ +-----+ +-----+ 346 | MS1 | | MS2 | .... | MSm | 347 +-----+ +-----+ +-----+ 348 ^ ^ ^ 349 | | | 350 V V V 351 +---------------------------------+ 352 | Distribution Source | 353 +--------+ | 354 | FT Agg | | 355 +--------+------------------------+ 356 ^ ^ | 357 : . | 358 : +...................+ 359 : | . 360 : / \ . 361 +------+ / \ +-----+ 362 | FT1 |<----+ +----->| FT2 | 363 +------+ / \ +-----+ 364 ^ ^ / \ ^ ^ 365 : : / \ : : 366 : : / \ : : 367 : : / \ : : 368 : ./\ /\. : 369 : /. \ / .\ : 370 : V . V V . V : 371 +----+ +----+ +----+ +----+ 372 | R1 | | R2 | ... |Rn-1| | Rn | 373 +----+ +----+ +----+ +----+ 375 Figure 6: SSM-based RTP session with Unicast Feedback 377 3. Security Options 379 This section provides an overview of a number of currently defined 380 security mechanisms that can be used with RTP. This section will use 381 a number of different security related terms, if they are unknown to 382 the reader, please consult the "Internet Security Glossary, Version 383 2" [RFC4949]. 385 Part of this discussion will be indication of known deployments or at 386 least requirements in specification to support particular security 387 solutions. This will most certainly not be a complete picture and 388 also become obsolete as time progress since the time of writing this 389 document. The goal with including such information is to help the 390 designer, given multiple potential solutions that meets the security 391 design goals one can consider values such as interoperability, 392 maturity of implementations or experiences with solution components. 394 3.1. Secure RTP 396 The Secure RTP (SRTP) protocol [RFC3711] is one of the most commonly 397 used mechanisms to provide confidentiality, integrity protection, 398 source authentication and replay protection for RTP. SRTP was 399 developed with RTP header compression and third party monitors in 400 mind. Thus the RTP header is not encrypted in RTP data packets, and 401 the first 8 bytes of the first RTCP packet header in each compound 402 RTCP packet are not encrypted. The entirety of RTP packets and 403 compound RTCP packets are integrity protected. This allows RTP 404 header compression to work, and lets third party monitors determine 405 what RTP traffic flows exist based on the SSRC fields, but protects 406 the sensitive content. 408 The source authentication guarantees provided by SRTP are highly 409 dependent on the cryptographic transform and key-management scheme 410 used. In some cases all a receiver can determine is whether the 411 packets come from someone in the group security context, and not what 412 group member send the packets. Thus, the source authentication 413 guarantees depend also on the session topology. Some cryptographic 414 transform have stronger authentication properties which can guarantee 415 a given source, even over a multi-party session, e.g. those based on 416 TESLA [RFC4383]. 418 SRTP can easily be extended with additional cryptographic transforms. 419 At the time of this writing, the following transforms are defined or 420 under definition: 422 AES CM and HMAC-SHA-1: AES Counter Mode encryption with 128 bits 423 keys combined with 128 bits keyed HMAC-SHA1 using 80 or 32 bits 424 authentication tags are the default cryptographic transform which 425 need to be supported. Defined in SRTP [RFC3711]. 427 AES-f8 and HMAC-SHA-1: AES f8 mode encryption with 128 bits keys 428 combined with keyed HMAC-SHA1 using 80 or 32 bits authentication. 429 Defined in SRTP [RFC3711]. 431 TESLA: As a complement to the regular symmetric keyed authentication 432 transforms, like HMAC-SHA1. The TESLA based authentication scheme 433 can provide per-source authentication in some group communication 434 scenarios. The downside is need for buffering the packets for a 435 while before authenticity can be verified. The TESLA transform 436 for SRTP is defined in [RFC4383]. 438 SEED: An Korean national standard cryptographic transform that is 439 defined to be used with SRTP in [RFC5669]. It has three modes, 440 one using SHA-1 authentication, one using Counter with CBC-MAC, 441 and finally one using Galois Counter mode. 443 ARIA: An Korean block cipher [I-D.ietf-avtcore-aria-srtp], that 444 supports 128, 192 and 256 bits keys. It also has three modes, 445 Counter mode where combined with HMAC-SHA1 with 80 or 32 bits 446 authentication tags, Counter mode with CBC-MAC and Galois Counter 447 mode. It also defines a different key derivation function than 448 the AES based. 450 AES-192 and AES-256: cryptographic transforms for SRTP based on 451 AES-192 and AES-256 counter mode encryption and 160-bit keyed 452 HMAC-SHA1 with 80 and 32 bits authentication tags for 453 authentication. Thus providing 192 and 256 bits encryption keys 454 and NSA Suite B included cryptographic transforms. Defined in 455 [RFC6188]. 457 AES-GCM: There is also ongoing work to define AES-GCM (Galois 458 Counter Mode) and AES-CCM (Counter with CBC) authentication for 459 AES-128 and AES-256. This authentication is included in the 460 cipher text which becomes expanded with the length of the 461 authentication tag instead of using the SRTP authentication tag. 462 This is defined in [I-D.ietf-avtcore-srtp-aes-gcm]. 464 [RFC4771] defines a variant of the authentication tag that enables a 465 receiver to obtain the Roll over Counter for the RTP sequence number 466 that is part of the Initialization vector (IV) for many cryptographic 467 transforms. This enables quicker and easier options for joining a 468 long lived secure RTP group, for example a broadcast session. 470 RTP header extensions are in normally carried in the clear and only 471 integrity protected in SRTP. This can be problematic in some cases, 472 so [RFC6904] defines an extension to also encrypt selected header 473 extensions. 475 SRTP is specified and deployed in a number of RTP usage contexts; 476 Significant support in SIP established VoIP clients including IMS; 477 RTSP [I-D.ietf-mmusic-rfc2326bis] and RTP based media streaming. 478 Thus SRTP in general is widely deployed. When it comes to 479 cryptographic transforms the default (AES CM and HMAC-SHA1) is the 480 most common used. 482 SRTP does not contain an integrated key-management solution, and 483 instead relies on an external key management protocol. There are 484 several protocols that can be used. The following sections outline 485 some popular schemes. 487 3.1.1. Key Management for SRTP: DTLS-SRTP 489 A Datagram Transport Layer Security extension exists for establishing 490 SRTP keys [RFC5763][RFC5764]. This extension provides secure key- 491 exchange between two peers, enabling perfect forward secrecy and 492 binding strong identity verification to an end-point. The default 493 key generation will generate a key that contains material contributed 494 by both peers. The key-exchange happens in the media plane directly 495 between the peers. The common key-exchange procedures will take two 496 round trips assuming no losses. TLS resumption can be used when 497 establishing additional media streams with the same peer, used 498 reducing the set-up time to one RTT. 500 The actual security properties of an established SRTP session using 501 DTLS will depend on the cipher suits offered and used. For example 502 some provides perfect forward secrecy (PFS), while other do not. 503 When using DTLS the application designer needs to select which cipher 504 suits that DTLS-SRTP can offer and accept so that the desired 505 security properties are achieved. 507 DTLS-SRTP key management can use the signalling protocol in three 508 ways. First, to agree on using DTLS-SRTP for media security. 509 Secondly, to determine the network location (address and port) where 510 each side is running an DTLS listener to let the parts perform the 511 key-management handshakes that generate the keys used by SRTP. 512 Finally, to exchange hashes of each sides certificates to enable each 513 side to verify that they have connected to the by signalling 514 indicated port and not a man in the middle. That way enabling some 515 binding between the key-exchange and the signalling. This usage is 516 well defined for SIP/SDP in [RFC5763], and in most cases can be 517 adopted for use with other bi-directions signalling solutions. 519 DTLS-SRTP usage and inclusion in specification are clearly on the 520 rise. It is mandatory to support in WebRTC. It has a growing 521 support among SIP end-points, which is good considering that DTLS- 522 SRTP was primarily developed in IETF to meet security requirements 523 from SIP. 525 3.1.2. Key Management for SRTP: MIKEY 527 Multimedia Internet Keying (MIKEY) [RFC3830] is a keying protocol 528 that has several modes with different properties. MIKEY can be used 529 in point-to-point applications using SIP and RTSP (e.g., VoIP calls), 530 but is also suitable for use in broadcast and multicast applications, 531 and centralized group communications. 533 MIKEY can establish multiple security contexts or cryptographic 534 sessions with a single message. It is possible to use in scenarios 535 where one entity generates the key and needs to distribute the key to 536 a number of participants. The different modes and the resulting 537 properties are highly dependent on the cryptographic method used to 538 establish the Traffic Generation Key (TGK) that is used to derive the 539 keys actually used by the security protocol, like SRTP. 541 MIKEY has the following modes of operation: 543 Pre-Shared Key: Uses a pre-shared secret for symmetric key crypto 544 used to secure a keying message carrying the already generated 545 TGK. This system is the most efficient from the perspective of 546 having small messages and processing demands. The downside is 547 scalability, where usually the effort for the provisioning of pre- 548 shared keys is only manageable, if the number of endpoints is 549 small. 551 Public Key encryption: Uses a public key crypto to secure a keying 552 message carrying the already generated TGK. This is more resource 553 consuming but enables scalable systems. It does require a public 554 key infrastructure to enable verification. 556 Diffie-Hellman: Uses Diffie-Hellman key-agreement to generate the 557 TGK, thus providing perfect forward secrecy. The downside is 558 increased resource consumption in bandwidth and processing. This 559 method can't be used to establish group keys as each pair of peers 560 performing the MIKEY exchange will establish different keys. 562 HMAC-Authenticated Diffie-Hellman: [RFC4650] defines a variant of 563 the Diffie-Hellman exchange that uses a pre-shared key in a keyed 564 HMAC to verify authenticity of the keying material instead of a 565 digital signature as in the previous method. This method is still 566 restricted to point-to-point usage. 568 RSA-R: MIKEY-RSA in Reverse mode [RFC4738] is a variant of the 569 public key method which doesn't rely on the initiator of the key- 570 exchange knowing the responders certificate. This methods lets 571 both the initiator and the responder to specify the TGK material 572 depending on use case. Usage of this mode requires one round trip 573 time. 575 TICKET: [RFC6043] is a MIKEY extension using trusted centralized key 576 management service and tickets, like Kerberos. 578 IBAKE: [RFC6267] uses a key management services (KMS) infrastructure 579 but with lower demand on the KMS. Claims to provides both perfect 580 forward and backwards secrecy, the exact meaning is unclear (See 581 Perfect Forward Secrecy in [RFC4949]). 583 SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption in MIKEY. 584 Based on Identity based Public Key Cryptography and a KMS 585 infrastructure to establish a shared secret value and certificate 586 less signatures to provide source authentication. It features 587 include simplex transmission, scalability, low-latency call set- 588 up, and support for secure deferred delivery. 590 MIKEY messages has several different defined transports. [RFC4567] 591 defines how MIKEY messages can be embedded in general SDP for usage 592 with the signalling protocols SIP, SAP and RTSP. There also exist an 593 3GPP defined usage of MIKEY that sends MIKEY messages directly over 594 UDP to key the receivers of Multimedia Broadcast and Multicast 595 Service (MBMS) [T3GPP.33.246]. 597 Based on the many choices it is important to consider the properties 598 needed in ones solution and based on that evaluate which modes that 599 are candidates for ones usage. More information on the applicability 600 of the different MIKEY modes can be found in [RFC5197]. 602 MIKEY with pre-shared keys are used by 3GPP MBMS [T3GPP.33.246]. 603 While RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] specifies use of the 604 RSA-R mode. There are some SIP end-points that supports MIKEY and 605 which mode they use are unknown by the authors. 607 3.1.3. Key Management for SRTP: Security Descriptions 609 [RFC4568] provides a keying solution based on sending plain text keys 610 in SDP [RFC4566]. It is primarily used with SIP and SDP Offer/ 611 Answer, and is well-defined in point to point sessions where each 612 side declares its own unique key. Using Security Descriptions to 613 establish group keys is less well defined, and can have security 614 issues as the SSRC uniqueness property can't be guaranteed. 616 Since keys are transported in plain text in SDP, they can easily be 617 intercepted unless the SDP carrying protocol provides strong end-to- 618 end confidentiality and authentication guarantees. This is not the 619 common use of security descriptions with SIP, where instead hop by 620 hop security is provided between signalling nodes using TLS. This 621 still leaves the keying material sensitive to capture by the 622 traversed signalling nodes. Thus in most cases the security 623 properties of security descriptions are weak. The usage of security 624 descriptions usually requires additional security measures, e.g. the 625 signalling nodes be trusted and protected by strict access control. 626 Usage of security descriptions requires careful design in order to 627 ensure that the security goals can be met. 629 Security Descriptions is the most commonly deployed keying solution 630 for SIP-based end-points, where almost all that supports SRTP also 631 supports Security Descriptions. 633 3.1.4. Key Management for SRTP: Encrypted Key Transport 635 Encrypted Key Transport (EKT) [I-D.ietf-avtcore-srtp-ekt] is an SRTP 636 extension that enables group keying despite using a keying mechanism 637 that can't support group keys, like DTLS-SRTP. It is designed for 638 centralized conferencing, but can also be used in sessions where an 639 end-points connect to a conference bridge or a gateway, and need to 640 be provisioned with the keys each participant on the bridge or 641 gateway uses to avoid decryption encryption cycles on the bridge or 642 gateway. This can enable interworking between DTLS-SRTP and for 643 example security descriptions or other keying systems where either 644 part can set the key. 646 The mechanism is based on establishing an additional EKT key which 647 everyone uses to protect their actual session key. The actual 648 session key is sent in a expanded authentication tag to the other 649 session participants. This key are only sent occasionally or 650 periodically depending on use cases depending on what requirements 651 exist for timely delivery or notification on when the key is needed 652 by someone. 654 The only known deployment of EKT so far are in some Cisco Video 655 Conferencing products. 657 3.1.5. Key Management for SRTP: Other systems 659 The ZRTP [RFC6189] key-management system for SRTP was proposed as an 660 alternative to DTLS-SRTP. It wasn't adopted as an IETF standards 661 track protocol, but was instead published as an informational RFC. 663 Additional proprietary solutions are also known to exist. 665 3.2. RTP Legacy Confidentiality 667 Section 9 of the RTP standard [RFC3550] defines a DES or 3DES based 668 encryption of RTP and RTCP packets. This mechanism is keyed using 669 plain text keys in SDP [RFC4566] using the "k=" SDP field. This 670 method of providing confidentiality has extremely weak security 671 properties and is not to be used. 673 3.3. IPsec 675 IPsec [RFC4301] can be used independent of mode to protect RTP and 676 RTCP packets in transit from one network interface to another. This 677 can be sufficient when the network interfaces have a direct relation, 678 or in a secured environment where it can be controlled who can read 679 the packets from those interfaces. 681 The main concern with using IPsec to protect RTP traffic is that in 682 most cases using a VPN approach that terminates the security 683 association at some node prior to the RTP end-point leaves the 684 traffic vulnerable to attack between the VPN termination node and the 685 end-point. Thus usage of IPsec requires careful thought and design 686 of its usage so that it really meets the security goals. A important 687 question is how one ensure the IPsec terminating peer and the 688 ultimate destination is the same. 690 IPsec with RTP is more commonly used as security solution between 691 central nodes in an infrastructure that exchanges many RTP sessions 692 and media streams between the peers. The establishment of a secure 693 tunnel between these peers minimizes the key-management overhead 694 between these two boxes. 696 3.4. DTLS 698 Datagram Transport Layer Security (DTLS) [RFC6347] can provide point 699 to point security for RTP flows. The two peers would establish an 700 DTLS association between each other, including the possibility to do 701 certificate-based source authentication when establishing the 702 association. All RTP and RTCP packets flowing will be protected by 703 this DTLS association. 705 Note: using DTLS is different to using DTLS-SRTP key management. 706 DTLS-SRTP has the core key-management steps in common with DTLS, but 707 DTLS-SRTP uses SRTP for the per packet security operations, while 708 DTLS uses the normal datagram TLS data protection. When using DTLS, 709 RTP and RTCP packets are completely encrypted with no headers in the 710 clear, while DTLS-SRTP leaves the headers in the clear. 712 DTLS can use similar techniques to those available for DTLS-SRTP to 713 bind a signalling side agreement to communicate to the certificates 714 used by the end-point when doing the DTLS handshake. This enables 715 use without having a certificate based trust chain to a trusted 716 certificate root. 718 There appear to be no significant usage of RTP over DTLS. 720 3.5. TLS over TCP 722 When RTP is sent over TCP [RFC4571] it can also be sent over TLS over 723 TCP [RFC4572], using TLS to provide point to point security services. 724 The security properties TLS provides are confidentiality, integrity 725 protection and possible source authentication if the client or server 726 certificates are verified and provide a usable identity. When used 727 in multi-party scenarios using a central node for media distribution, 728 the security provide is only between then central node and the peers, 729 so the security properties for the whole session are dependent on 730 what trust one can place in the central node. 732 RTSP 1.0 [RFC2326] and 2.0 [I-D.ietf-mmusic-rfc2326bis] specifies the 733 usage of RTP over the same TLS/TCP connection that the RTSP messages 734 are sent over. It appears that RTP over TLS is also used in some 735 proprietary solutions that uses TLS to bypass firewalls. 737 3.6. Payload-only Security Mechanisms 739 Mechanisms have been defined that encrypt only the payload of the RTP 740 packets, and leave the RTP headers and RTCP in the clear. There are 741 several reasons why this might be appropriate, but a common rationale 742 is to ensure that the content stored in RTP hint tracks in RTSP 743 streaming servers has the media content in a protected format that 744 cannot be read by the streaming server (this is mostly done in the 745 context of Digital Rights Management). These approaches then uses a 746 key-management solution between the rights provider and the consuming 747 client to deliver the key used to protect the content, usually after 748 the appropriate method for charging has happened, and do not include 749 the media server in the security context. Such methods have several 750 security weaknesses such the fact that the same key is handed out to 751 a potentially large group of receiving clients, increasing the risk 752 of a leak. 754 Use of this type of solution can be of interest in environments that 755 allow middleboxes to rewrite the RTP headers and select what streams 756 that are delivered to an end-point (e.g., some types of centralised 757 video conference systems). The advantage of encrypting and possibly 758 integrity protecting the payload but not the headers is that the 759 middlebox can't eavesdrop on the media content, but can still provide 760 stream switching functionality. The downside of such a system is 761 that it likely needs two levels of security: the payload level 762 solution to provide confidentiality and source authentication, and a 763 second layer with additional transport security ensuring source 764 authentication and integrity of the RTP headers associated with the 765 encrypted payloads. This can also results in the need to have two 766 different key-management systems as the entity protecting the packets 767 and payloads are different with different set of keys. 769 The aspect of two tiers of security are present in ISMAcryp (see 770 Section 3.6.1) and the deprecated 3GPP Packet Based Streaming Service 771 Annex.K [T3GPP.26.234R8] solution. 773 3.6.1. ISMA Encryption and Authentication 775 The Internet Streaming Media Alliance (ISMA) has defined ISMA 776 Encryption and Authentication 2.0 [ISMACrypt2]. This specification 777 defines how one encrypts and packetizes the encrypted application 778 data units (ADUs) in an RTP payload using the MPEG-4 Generic payload 779 format [RFC3640]. The ADU types that are allowed are those that can 780 be stored as elementary streams in an ISO Media File format based 781 file. ISMAcryp uses SRTP for packet level integrity and source 782 authentication from a streaming server to the receiver. 784 Key-management for a ISMACryp based system can be achieved through 785 Open Mobile Alliance (OMA) Digital Rights Management 2.0 [OMADRMv2], 786 for example. 788 4. Securing RTP Applications 790 In the following we provide guidelines for how to choose appropriate 791 security mechanisms for RTP applications. 793 4.1. Application Requirements 795 This section discusses a number of application requirements that need 796 be considered. An application designer choosing security solutions 797 requires a good understanding of what level of security is needed and 798 what behaviour they strive to achieve. 800 4.1.1. Confidentiality 802 When it comes to confidentiality of an RTP session there are several 803 aspects to consider: 805 Probability of compromise: When using encryption to provide media 806 confidentiality, it is necessary to have some rough understanding 807 of the security goal and how long one expect the protected content 808 remain confidential. National or other regulations might provided 809 additional requirements on a particular usage of an RTP. From 810 that, one can determine what encryption algorithms are to be used 811 from the set of available transforms. 813 Potential for other leakage: RTP based security in most of its forms 814 simply wraps RTP and RTCP packets into cryptographic containers. 815 This commonly means that the size of the original RTP payload, and 816 details of the RTP and RTCP headers, are visible to observers of 817 the protected packet flow. This can provide information to those 818 observers. A well documented case is the risk with variable bit- 819 rate speech codecs that produce different sized packets based on 820 the speech input [RFC6562]. Potential threats such as these need 821 to be considered and, if they are significant, then restrictions 822 will be needed on mode choices in the codec, or additional padding 823 will need to be added to make all packets equal size and remove 824 the informational leakage. 826 Another case is RTP header extensions. If SRTP is used, header 827 extensions are normally not protected by the security mechanism 828 protecting the RTP payload. If the header extension carries 829 information that is considered sensitive, then the application 830 needs to be modified to ensure that mechanisms used to protect 831 against such information leakage are employed. 833 Who has access: When considering the confidentiality properties of a 834 system, it is important to consider where the media handled in the 835 clear. For example, if the system is based on an RTP mixer that 836 needs the keys to decrypt the media, process, and repacketize it, 837 then is the mixer providing the security guarantees expected by 838 the other parts of the system? Furthermore, it is important to 839 consider who has access to the keys, and are the keys stored or 840 kept somewhere? The policies for the handling of the keys, and 841 who can access the keys, need to be considered along with the 842 confidentiality goals. 844 As can be seen the actual confidentiality level has likely more to do 845 with the application's usage of centralized nodes, and the details of 846 the key-management solution chosen, than with the actual choice of 847 encryption algorithm (although, of course, the encryption algorithm 848 needs to be chosen appropriately for the desired security level). 850 4.1.2. Integrity 852 Protection against modification of content by a third party, or due 853 to errors in the network, is another factor to consider. The first 854 aspect that one consider is what resilience one has against 855 modifications to the content. This can affect what cryptographic 856 algorithm is used, and the length of the integrity tags. However 857 equally, important is to consider who is providing the integrity 858 assertion, what is the source of the integrity tag, and what are the 859 risks of modifications happening prior to that point where protection 860 is applied? RTP applications that rely on central nodes need to 861 consider if hop-by-hop integrity is acceptable, or if true end-to-end 862 integrity protection is needed? Is it important to be able to tell 863 if a middlebox has modified the data? There are some uses of RTP 864 that require trusted middleboxes that can modify the data in a way 865 that doesn't break integrity protection as seen by the receiver, for 866 example local advertisement insertion in IPTV systems; there are also 867 uses where it is essential that such in-network modification be 868 detectable. RTP can support both, with appropriate choices of 869 security mechanisms. 871 Integrity of the data is commonly closely tied to the question of 872 source authentication. That is, it becomes important to know who 873 makes an integrity assertion for the data. 875 4.1.3. Source Authentication 877 Source authentication is about determining who sent a particular RTP 878 or RTCP packet. It is normally closely tied with integrity, since 879 you also want to ensure that what you received is what the claimed 880 source really sent, so source authentication without integrity is not 881 particularly useful. In similar way, although not as definitive, is 882 that integrity without source authentication is also not particular 883 useful: you need to know who claims this packet wasn't changed. 885 Source authentication can be asserted in several different ways: 887 Base level: Using cryptographic mechanisms that give authentication 888 with some type of key-management provides an implicit method for 889 source authentication. Assuming that the mechanism has sufficient 890 strength to not be circumvented in the time frame when you would 891 accept the packet as valid, it is possible to assert a source 892 authenticated statement; this message is highly probably from 893 someone that has the cryptographic key(s) to this communication. 895 What that assertion actually means is highly dependent on the 896 application, and how it handles the keys. In an application where 897 the key-handling is limited to two peers, this can form a basis 898 for a trust relationship to the level that you can state as the 899 traffic is authenticated and matching this particular context. 900 Thus, it is coming either from me or from my peer (and I trust 901 that neither has shared the key with anyone else). However, in a 902 multi-party scenario where security contexts are shared among 903 participants, most base-level authentication solutions can't even 904 assert that this packet is from the same source as the previous 905 packet. 907 Binding the Source: A step up in the assertion that can be done in 908 base-level systems is to tie the signalling to the key-exchange. 909 Here, the goal is to be at least be able to assert that the sender 910 of the packets is the same entity that I have established the 911 session with. How feasible this is depends on the properties of 912 the key-management system used, the ability to tie the signalling 913 to a particular peer, and what trust you place on the different 914 nodes involved. 916 For example, consider a point to point communication system that 917 use DTLS-SRTP using self-signed certificates for key-management, 918 and SIP for signalling. In such a system the end-points for the 919 DTLS-SRTP handshake have securely established keys that are not 920 visible to the signalling nodes. However, as the certificates 921 used by DTLS is not bound to any PKI they can't be verified. 922 Instead, hashes over the certificate are sent over the signalling 923 path. If the signalling can be trusted not to collaborate on 924 performing a man in the middle attack by modifying the hashes, 925 then the end-points can verify that they have established keys 926 with the peer they are doing signalling with. 928 Systems where the key-exchange are done using the signalling 929 systems, such as Security Descriptions [RFC4568] or MIKEY embedded 930 in SDP [RFC4567], enables an direct binding between signalling and 931 key-exchange. Independent of DTLS-SRTP or MIKEY in SDP the actual 932 security depends on the trust one can place in the signalling 933 system to correctly associate the peer's identity with the key- 934 exchange. 936 Using Identities: If the applications have access to a system that 937 can provide verifiable identities, then the source authentication 938 can be bound to that identity. For example, in a point-to-point 939 communication even symmetric key crypto, where the key-management 940 can assert that the key has only been exchanged with a particular 941 identity, can provide a strong assertion about who is sending the 942 traffic. 944 Note that all levels of the system much have matching capability 945 to assert identity. Having the signalling assert that you include 946 a particular identity in a multi-party communication session where 947 the key-management systems establish keys in a way that one can 948 assert that only the given identity has gotten the key. Using a 949 authentication mechanism built on a group key that otherwise can't 950 provide any assertion who sent the traffic than anyone that got 951 the key, provides no strong assertion on the media level than: 953 Someone that has gotten the security context (key) sent this 954 traffic. 956 4.1.4. Identity 958 There exist many different types of identity systems with different 959 properties. But in the context of RTP applications the most 960 important property is the possibility to perform source 961 authentication and verify such assertions in relation to any claimed 962 identities. What an identity really are can also vary, but in the 963 context of communication, one of the most obvious is the identity of 964 the human user one communicates with. However, the human user can 965 also have additional identities in a particular role. For example, 966 the human Alice, can also be a police officer and in some cases her 967 identity as police officer will be more relevant then that she is 968 Alice. This is common in contact with organizations, where it is 969 important to prove the persons right to represent the organization. 971 Some examples of identity mechanisms that could be used: 973 Certificate based: A certificate is used to prove the identity, by 974 having access to the private part of the certificate one can 975 perform signing to assert ones identity. Any entity interested in 976 verifying the assertion then needs the public part of the 977 certificate. By having the certificate one can verify the signing 978 against the certificate. The next step is to determine if one 979 trusts the certificate's trust chain. Commonly by provisioning 980 the verifier with the public part of a root certificate, this 981 enables the verifier to verify a trust chain from the root 982 certificate down to the identity certificate. However, the trust 983 is based on that all steps in the certificate chain are verifiable 984 and can be trusted. Thus provisioning of root certificates, 985 having possibility to revoke compromised certificates are aspects 986 that will require infrastructure. 988 Online Identity Providers: An online identity provider (IdP) can 989 authenticate a user's right to use an identity, then perform 990 assertions on their behalf or provision the requester with short- 991 term credentials to assert their identity. The verifier can then 992 contact the IdP to request verification of a particular identity. 993 Here the trust is highly dependent on how much one trusts the IdP. 994 The system also becomes dependent on having access to the relevant 995 IdP. 997 In all of the above examples, an important part of the security 998 properties are related to the method for authenticating the access to 999 the identity. 1001 4.1.5. Privacy 1003 RTP applications need to consider what privacy goals they have. As 1004 RTP applications communicate directly between peers in many cases, 1005 the IP addresses of any communication peer will be available. The 1006 main privacy concern with IP addresses is related to geographical 1007 location and the possibility to track a user of an end-point. The 1008 main way of avoid such concerns is the introduction of relay or 1009 centralized media mixers or forwarders that hides the address of a 1010 peer from any other peer. The security and trust placed in these 1011 relays obviously needs to be carefully considered. 1013 RTP itself can contribute to enabling a particular user to be tracked 1014 between communication sessions if the CNAME is generated according to 1015 the RTP specification in the form of user@host. Such RTCP CNAMEs are 1016 likely long term stable over multiple sessions, allowing tracking of 1017 users. This can be desirable for long-term fault tracking and 1018 diagnosis, but clearly has privacy implications. Instead 1019 cryptographically random ones could be used as defined by Guidelines 1020 for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) 1021 [I-D.ietf-avtcore-6222bis]. 1023 If there exist privacy goals, these need to be considered, and the 1024 system designed with them in mind. In addition certain RTP features 1025 might have to be configured to safeguard privacy, or have 1026 requirements on how the implementation is done. 1028 4.2. Application Structure 1030 When it comes to RTP security, the most appropriate solution is often 1031 highly dependent on the topology of the communication session. The 1032 signalling also impacts what information can be provided, and if this 1033 can be instance specific, or common for a group. In the end the key- 1034 management system will highly affect the security properties achieved 1035 by the application. At the same time, the communication structure of 1036 the application limits what key management methods are applicable. 1037 As different key-management have different requirements on underlying 1038 infrastructure it is important to take that aspect into consideration 1039 early in the design. 1041 4.3. Interoperability 1042 Few RTP applications exist as independent applications that never 1043 interoperate with anything else. Rather, they enable communication 1044 with a potentially large number of other systems. To minimize the 1045 number of security mechanisms that need to be implemented, it is 1046 important to consider if one can use the same security mechanisms as 1047 other applications. This can also reduce the problems of determining 1048 what security level is actually negotiated in a particular session. 1050 The desire to be interoperable can in some cases be in conflict with 1051 the security requirements determined for an application. To meet the 1052 security goals, it might be necessary to sacrifice interoperability. 1053 Alternatively, one can implement multiple security mechanisms, but 1054 then end up with an issue of ensuring that the user understands what 1055 it means to use a particular security level. In addition, the 1056 application can then become vulnerable to bid-down attack. 1058 5. Examples 1060 In the following we describe a number of example security solutions 1061 for RTP using applications, services or frameworks. These examples 1062 are provided to show the choices that can be made. They are not 1063 normative recommendations for security. 1065 5.1. Media Security for SIP-established Sessions using DTLS-SRTP 1067 The IETF evaluated media security for RTP sessions established using 1068 point-to-point SIP sessions in 2009. A number of requirements were 1069 determined, and based on those, the existing solutions for media 1070 security and especially the keying methods were analysed, and the 1071 resulting requirements and analysis were published in [RFC5479]. 1072 Based on this analysis, and the working group discussion, DTLS-SRTP 1073 was determined to be the best solution, and the specifications were 1074 finalized. 1076 The security solution for SIP using DTLS-SRTP is defined in the 1077 Framework for Establishing a Secure Real-time Transport Protocol 1078 (SRTP) Security Context Using Datagram Transport Layer Security 1079 (DTLS) [RFC5763]. On a high level it uses SIP with SDP offer/answer 1080 procedures to exchange the network addresses where the server end- 1081 point will have a DTLS-SRTP enable server running. The SIP 1082 signalling is also used to exchange the fingerprints of the 1083 certificate each end-point will use in the DTLS establishment 1084 process. When the signalling is sufficiently completed the DTLS-SRTP 1085 client performs DTLS handshakes and establishes SRTP session keys. 1086 The clients also verify the fingerprints of the certificates to 1087 verify that no man in the middle has inserted themselves into the 1088 exchange. 1090 At the basic level DTLS has a number of good security properties. 1091 For example, to enable a man in the middle someone in the signalling 1092 path needs to perform an active action and modify the signalling 1093 message. There also exist a solution that enables the fingerprints 1094 to be bound to identities established by the first proxy for each 1095 user [RFC4916]. That reduces the number of nodes the connecting user 1096 User Agent has to trust to the first hop proxy, rather than the full 1097 signalling path. 1099 5.2. Media Security for WebRTC Sessions 1101 Web Real-Time Communication [I-D.ietf-rtcweb-overview] is solution 1102 providing web-application with real-time media directly between 1103 browsers. The RTP transported real-time media is protected using a 1104 mandatory to use application of SRTP. The default keying of SRTP is 1105 done using DTLS-SRTP. The security configuration is further defined 1106 in the WebRTC Security Architecture [I-D.ietf-rtcweb-security-arch]. 1108 The peers hash of their certificates are provided to a Javascript 1109 application that is part of a client server system providing 1110 rendezvous services for the ones a given peer wants to communicate 1111 with. Thus the handling of the hashes between the peers is not well 1112 defined. It becomes a matter of trust in the application. But 1113 unless the application and its server is intending to compromise the 1114 communication security they can provide a secure and integrity 1115 protected exchange of the certificate hashes thus preventing any man- 1116 in-the-middle (MITM) to insert itself in the key-exchange. 1118 The web application still have the possibility to insert a MITM. 1119 That unless one uses a Identity provider and the proposed identity 1120 solution [I-D.ietf-rtcweb-security-arch]. In this solution the 1121 Identity Provider which is a third party to the web-application signs 1122 the DTLS-SRTP hash combined with a statement on which user identity 1123 that has been used to sign the hash. The receiver of such a Identity 1124 assertion then independently verifies the user identity to ensure 1125 that it is the identity it intended to communicate and that the 1126 cryptographic assertion holds. That way a user can be certain that 1127 the application also can't perform an MITM and that way acquire the 1128 keys to the media communication. 1130 In the development of WebRTC there has also been high attention on 1131 privacy question. The main concerns that has been raised and are at 1132 all related to RTP are: 1134 Location Disclosure: As ICE negotiation provides IP addresses and 1135 ports for the browser, this leaks location information in the 1136 signalling to the peer. To prevent this one can block the usage 1137 of any ICE candidate that isn't a relay candidate, i.e. where the 1138 IP and port provided belong to the service providers media traffic 1139 relay. 1141 Prevent tracking between sessions: RTP CNAMEs and DTLS-SRTP 1142 certificates is information that could possibly be re-used between 1143 session instances. Thus to prevent tracking the same information 1144 can't be re-used between different communication sessions. 1146 Note: The above cases are focused on providing privacy towards other 1147 parties than the web service. 1149 5.3. 3GPP Packet Based Streaming Service (PSS) 1151 The 3GPP Release 11 PSS specification of the Packet Based Streaming 1152 Service (PSS) [T3GPP.26.234R11] defines in Annex R a set of security 1153 mechanisms. These security mechanisms are centred around protecting 1154 the content from being captured, i.e. Digital Rights Management. If 1155 these goals are to be meet with the specified solution there needs to 1156 exist trust in that neither the implementation of the client nor the 1157 platform the application runs can be accessed or modified by the 1158 attacker. 1160 PSS is RTSP 1.0 [RFC2326] controlled media streaming over RTP. Thus 1161 an RTSP client whose user wants to access a protected content will 1162 request a session description (SDP [RFC4566]) for the protected 1163 content. This SDP will indicate that the media are ISMA Crypt 2.0 1164 [ISMACrypt2] protected media encoding application units (AUs). The 1165 key(s) used to protect the media are provided in either of two ways. 1166 If a single key is used then the client uses some DRM system to 1167 retrieve the key as indicated in the SDP. Commonly OMA DRM v2 1168 [OMADRMv2] will be used to retrieve the key. If multiple keys are to 1169 be used, then using RTSP an additional stream for key-updates in 1170 parallel with the media streams are established, where key updates 1171 are sent to the client using Short Term Key Messages defined by 1172 "Service and Content Protection for Mobile Broadcast Services" part 1173 of the OMA Mobile Broadcast Services [OMABCAST]. 1175 Worth noting is that this solution doesn't provide any integrity 1176 verification method for the RTP header and payload header 1177 information, only the encoded media AU is protected. 3GPP has not 1178 defined any requirement for supporting SRTP or other solution that 1179 could provide that service. Thus, replay or insertion attacks are 1180 possible. Another property is that the media content can be 1181 protected by the ones providing the media, so that the operators of 1182 the RTSP server has no access to unprotected content. Instead all 1183 that want to access the media is supposed to contact the DRM keying 1184 server and if the device is acceptable they will be given the key to 1185 decrypt the media. 1187 To protect the signalling RTSP 1.0 supports the usage of TLS, this is 1188 however not explicitly discussed in the PSS specification. Usage of 1189 TLS can prevent both modification of the session description 1190 information and help maintain some privacy of what content the user 1191 is watching as all URLs would then be confidentiality protected. 1193 5.4. RTSP 2.0 1195 Real-time Streaming Protocol 2.0 [I-D.ietf-mmusic-rfc2326bis] can be 1196 an interesting comparison to the PSS service (Section 5.3) that is 1197 based on RTSP 1.0 and service requirements perceived by mobile 1198 operators. A major difference between RTSP 1.0 and RTSP 2.0 is that 1199 2.0 is fully defined under the requirement to have mandatory to 1200 implement security mechanism. As it specifies how one transport 1201 media over RTP it is also defining security mechanisms for the RTP 1202 transported media streams. 1204 The security goals for RTP in RTSP 2.0 is to ensure that there are 1205 confidentiality, integrity and source authentication between the RTSP 1206 server and the client. This to prevent eavesdropping on what the 1207 user is watching for privacy reasons and prevent replay or injection 1208 attacks on the media stream. To reach these goals also the 1209 signalling has to be protected, requiring the use of TLS between the 1210 client and server. 1212 Using TLS protected signalling the client and server agrees on the 1213 media transport method when doing the SETUP request and response. 1214 The secured media transport is SRTP (SAVP/RTP) normally over UDP. 1215 The key management for SRTP is MIKEY using RSA-R mode. The RSA-R 1216 mode is selected as it allows the RTSP Server to select the key, 1217 despite having the RTSP Client initiate the MIKEY exchange. It also 1218 enables the reuse of the RTSP servers TLS certificate when creating 1219 the MIKEY messages thus ensuring a binding between the RTSP server 1220 and the key-exchange. Assuming the SETUP process works, this will 1221 establish a SRTP crypto context to be used between the RTSP Server 1222 and the Client for the RTP transported media streams. 1224 6. IANA Considerations 1226 This document makes no request of IANA. 1228 Note to RFC Editor: this section can be removed on publication as an 1229 RFC. 1231 7. Security Considerations 1233 This entire document is about security. Please read it. 1235 8. Acknowledgements 1237 We thank the IESG for their careful review of 1238 [I-D.ietf-avt-srtp-not-mandatory] which led to the writing of this 1239 memo. 1241 The authors wished to thank Christian Correll for review and great 1242 proposals for improvements of the text. 1244 9. Informative References 1246 [I-D.ietf-avt-srtp-not-mandatory] 1247 Perkins, C. and M. Westerlund, "Securing the RTP Protocol 1248 Framework: Why RTP Does Not Mandate a Single Media 1249 Security Solution", draft-ietf-avt-srtp-not-mandatory-12 1250 (work in progress), February 2013. 1252 [I-D.ietf-avtcore-6222bis] 1253 Begen, A., Perkins, C., Wing, D., and E. Rescorla, 1254 "Guidelines for Choosing RTP Control Protocol (RTCP) 1255 Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-03 1256 (work in progress), April 2013. 1258 [I-D.ietf-avtcore-aria-srtp] 1259 Kim, W., Lee, J., Kim, D., Park, J., and D. Kwon, "The 1260 ARIA Algorithm and Its Use with the Secure Real-time 1261 Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-01 1262 (work in progress), December 2012. 1264 [I-D.ietf-avtcore-srtp-aes-gcm] 1265 McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated 1266 Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp- 1267 aes-gcm-05 (work in progress), February 2013. 1269 [I-D.ietf-avtcore-srtp-ekt] 1270 McGrew, D., Wing, D., and K. Fischer, "Encrypted Key 1271 Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00 1272 (work in progress), July 2012. 1274 [I-D.ietf-mmusic-rfc2326bis] 1275 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1276 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1277 (RTSP)", draft-ietf-mmusic-rfc2326bis-34 (work in 1278 progress), April 2013. 1280 [I-D.ietf-rtcweb-overview] 1281 Alvestrand, H., "Overview: Real Time Protocols for Brower- 1282 based Applications", draft-ietf-rtcweb-overview-06 (work 1283 in progress), February 2013. 1285 [I-D.ietf-rtcweb-security-arch] 1286 Rescorla, E., "RTCWEB Security Architecture", draft-ietf- 1287 rtcweb-security-arch-06 (work in progress), January 2013. 1289 [ISMACrypt2] 1290 , "ISMA Encryption and Authentication, Version 2.0 release 1291 version", November 2007. 1293 [OMABCAST] 1294 Open Mobile Alliance, "OMA Mobile Broadcast Services 1295 V1.0", February 2009. 1297 [OMADRMv2] 1298 Open Mobile Alliance, "OMA Digital Rights Management 1299 V2.0", July 2008. 1301 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1302 RFC 1112, August 1989. 1304 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1305 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1307 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 1308 Engineering Task Force Standard Protocols", BCP 61, RFC 1309 3365, August 2002. 1311 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1312 Jacobson, "RTP: A Transport Protocol for Real-Time 1313 Applications", STD 64, RFC 3550, July 2003. 1315 [RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., 1316 and P. Gentric, "RTP Payload Format for Transport of 1317 MPEG-4 Elementary Streams", RFC 3640, November 2003. 1319 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1320 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1321 RFC 3711, March 2004. 1323 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1324 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1325 August 2004. 1327 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1328 Internet Protocol", RFC 4301, December 2005. 1330 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 1331 Stream Loss-Tolerant Authentication (TESLA) in the Secure 1332 Real-time Transport Protocol (SRTP)", RFC 4383, February 1333 2006. 1335 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1336 Description Protocol", RFC 4566, July 2006. 1338 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 1339 Carrara, "Key Management Extensions for Session 1340 Description Protocol (SDP) and Real Time Streaming 1341 Protocol (RTSP)", RFC 4567, July 2006. 1343 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1344 Description Protocol (SDP) Security Descriptions for Media 1345 Streams", RFC 4568, July 2006. 1347 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1348 and RTP Control Protocol (RTCP) Packets over Connection- 1349 Oriented Transport", RFC 4571, July 2006. 1351 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1352 Transport Layer Security (TLS) Protocol in the Session 1353 Description Protocol (SDP)", RFC 4572, July 2006. 1355 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1356 IP", RFC 4607, August 2006. 1358 [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for 1359 Multimedia Internet KEYing (MIKEY)", RFC 4650, September 1360 2006. 1362 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 1363 RSA-R: An Additional Mode of Key Distribution in 1364 Multimedia Internet KEYing (MIKEY)", RFC 4738, November 1365 2006. 1367 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1368 Transform Carrying Roll-Over Counter for the Secure Real- 1369 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1371 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 1372 Protocol (SIP)", RFC 4916, June 2007. 1374 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 1375 4949, August 2007. 1377 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 1378 January 2008. 1380 [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of 1381 Various Multimedia Internet KEYing (MIKEY) Modes and 1382 Extensions", RFC 5197, June 2008. 1384 [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 1385 "Requirements and Analysis of Media Security Management 1386 Protocols", RFC 5479, April 2009. 1388 [RFC5669] Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The 1389 SEED Cipher Algorithm and Its Use with the Secure Real- 1390 Time Transport Protocol (SRTP)", RFC 5669, August 2010. 1392 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1393 Protocol (RTCP) Extensions for Single-Source Multicast 1394 Sessions with Unicast Feedback", RFC 5760, February 2010. 1396 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1397 for Establishing a Secure Real-time Transport Protocol 1398 (SRTP) Security Context Using Datagram Transport Layer 1399 Security (DTLS)", RFC 5763, May 2010. 1401 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1402 Security (DTLS) Extension to Establish Keys for the Secure 1403 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1405 [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based 1406 Modes of Key Distribution in Multimedia Internet KEYing 1407 (MIKEY)", RFC 6043, March 2011. 1409 [RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure 1410 RTP", RFC 6188, March 2011. 1412 [RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 1413 Path Key Agreement for Unicast Secure RTP", RFC 6189, 1414 April 2011. 1416 [RFC6267] Cakulev, V. and G. Sundaram, "MIKEY-IBAKE: Identity-Based 1417 Authenticated Key Exchange (IBAKE) Mode of Key 1418 Distribution in Multimedia Internet KEYing (MIKEY)", RFC 1419 6267, June 2011. 1421 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1422 Security Version 1.2", RFC 6347, January 2012. 1424 [RFC6509] Groves, M., "MIKEY-SAKKE: Sakai-Kasahara Key Encryption in 1425 Multimedia Internet KEYing (MIKEY)", RFC 6509, February 1426 2012. 1428 [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of 1429 Variable Bit Rate Audio with Secure RTP", RFC 6562, March 1430 2012. 1432 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 1433 Real-time Transport Protocol (SRTP)", RFC 6904, April 1434 2013. 1436 [T3GPP.26.234R11] 1437 3GPP, "Technical Specification Group Services and System 1438 Aspects; Transparent end-to-end Packet-switched Streaming 1439 Service (PSS); Protocols and codecs", 3GPP TS 26.234 1440 11.1.0, September 2012. 1442 [T3GPP.26.234R8] 1443 3GPP, "Technical Specification Group Services and System 1444 Aspects; Transparent end-to-end Packet-switched Streaming 1445 Service (PSS); Protocols and codecs", 3GPP TS 26.234 1446 8.4.0, September 2009. 1448 [T3GPP.26.346] 1449 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 1450 Protocols and codecs", 3GPP TS 26.346 10.7.0, March 2013. 1452 [T3GPP.33.246] 1453 3GPP, "3G Security; Security of Multimedia Broadcast/ 1454 Multicast Service (MBMS)", 3GPP TS 33.246 10.1.0, December 1455 2012. 1457 Authors' Addresses 1459 Magnus Westerlund 1460 Ericsson 1461 Farogatan 6 1462 SE-164 80 Kista 1463 Sweden 1465 Phone: +46 10 714 82 87 1466 Email: magnus.westerlund@ericsson.com 1467 Colin Perkins 1468 University of Glasgow 1469 School of Computing Science 1470 Glasgow G12 8QQ 1471 United Kingdom 1473 Email: csp@csperkins.org