idnits 2.17.1 draft-ietf-avtcore-rtp-security-options-06.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 (August 30, 2013) is 3885 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-13 == Outdated reference: A later version (-11) exists of draft-ietf-avtcore-aria-srtp-04 == Outdated reference: A later version (-17) exists of draft-ietf-avtcore-srtp-aes-gcm-07 == 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-07 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-07 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 9 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. S. Perkins 5 Expires: March 03, 2014 University of Glasgow 6 August 30, 2013 8 Options for Securing RTP Sessions 9 draft-ietf-avtcore-rtp-security-options-06 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 March 03, 2014. 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 . . . . . . . . . . . 11 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 for RTP and RTCP . . . . . . . . . . . . . . . . . . 15 78 3.5. TLS over TCP . . . . . . . . . . . . . . . . . . . . . . 16 79 3.6. Media Content Security/Digital Rights Management . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . . . . 26 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 [I-D.ietf-avt-srtp-not-mandatory]. Instead, 133 application developers need to select mechanisms that provide 134 appropriate security for their environment. It is strongly 135 encouraged that common mechanisms are used by related applications in 136 common environments. The IETF publishes guidelines for specific 137 classes of applications, so it worth searching for such 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 due to its support 150 for point-to-point sessions, multicast groups, and other topologies 151 built around different types of RTP middleboxes. In the following we 152 review the different topologies supported by RTP to understand their 153 implications for the security properties and trust relations that can 154 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- 168 point's verifiable identity to ensure that the peer knows who they 169 are communicating with. Here the combination of the security 170 protocol protecting the RTP session and its RTP and RTCP traffic and 171 the key-management protocol becomes important in which security 172 statements 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 a 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 example, participants A through D each send 194 unicast RTP traffic to the RTP mixer, and receive an RTP stream from 195 the mixer, comprising a mixture of the streams from the other 196 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 has the individual unicast RTCP feedback 343 that 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 security requirements, and the 380 current RTP security mechanisms that implement those requirements. 381 This cannot be a complete survey, since new security mechanisms are 382 defined regularly. The goal is to help applications designer by 383 giving reviewing the types of solution that are available. This 384 section will use a number of different security related terms, 385 described in the Internet Security Glossary, Version 2 [RFC4949]. 387 3.1. Secure RTP 389 The Secure RTP (SRTP) protocol [RFC3711] is one of the most commonly 390 used mechanisms to provide confidentiality, integrity protection, 391 source authentication and replay protection for RTP. SRTP was 392 developed with RTP header compression and third party monitors in 393 mind. Thus the RTP header is not encrypted in RTP data packets, and 394 the first 8 bytes of the first RTCP packet header in each compound 395 RTCP packet are not encrypted. The entirety of RTP packets and 396 compound RTCP packets are integrity protected. This allows RTP 397 header compression to work, and lets third party monitors determine 398 what RTP traffic flows exist based on the SSRC fields, but protects 399 the sensitive content. 401 The source authentication guarantees provided by SRTP depend on the 402 cryptographic transform and key-management used. Some transforms, 403 e.g., those using TESLA [RFC4383], give strong source authentication 404 even in multiparty sessions; others give weaker guarantees and can 405 authenticate group membership by not sources. 407 SRTP can easily be extended with additional cryptographic transforms. 408 At the time of this writing, the following transforms are defined or 409 under definition: 411 AES CM and HMAC-SHA-1: AES Counter Mode encryption with 128 bits 412 keys combined with 128 bits keyed HMAC-SHA-1 using 80- or 32-bits 413 authentication tags. This is the default cryptographic transform 414 that needs to be supported. Defined in SRTP [RFC3711]. 416 AES-f8 and HMAC-SHA-1: AES f8 mode encryption with 128-bits keys 417 combined with keyed HMAC-SHA-1 using 80- or 32-bit authentication. 418 Defined in SRTP [RFC3711]. 420 TESLA: As a complement to the regular symmetric keyed authentication 421 transforms, like HMAC-SHA-1. The TESLA based authentication 422 scheme can provide per-source authentication in some group 423 communication scenarios. The downside is need for buffering the 424 packets for a while before authenticity can be verified. The 425 TESLA transform for SRTP is defined in [RFC4383]. 427 SEED: A Korean national standard cryptographic transform that is 428 defined to be used with SRTP in [RFC5669]. It has three modes, 429 one using SHA-1 authentication, one using Counter with CBC-MAC, 430 and finally one using Galois Counter mode. 432 ARIA: A Korean block cipher [I-D.ietf-avtcore-aria-srtp], that 433 supports 128-, 192- and 256- bit keys. It also has three modes, 434 Counter mode where combined with HMAC-SHA-1 with 80 or 32 bits 435 authentication tags, Counter mode with CBC-MAC and Galois Counter 436 mode. It also defines a different key derivation function than 437 the AES based systems. 439 AES-192 and AES-256: cryptographic transforms for SRTP based on 440 AES-192 and AES-256 counter mode encryption and 160-bit keyed 441 HMAC-SHA-1 with 80- and 32-bit authentication tags. Thus 442 providing 192 and 256 bits encryption keys and NSA Suite B 443 included cryptographic transforms. Defined in [RFC6188]. 445 AES-GCM: Galois Counter Mode and AES-CCM (Counter with CBC) 446 authentication for AES-128 and AES-256. This authentication is 447 included in the cipher text which becomes expanded with the length 448 of the authentication tag instead of using the SRTP authentication 449 tag. This is defined in [I-D.ietf-avtcore-srtp-aes-gcm]. 451 [RFC4771] defines a variant of the authentication tag that enables a 452 receiver to obtain the Roll over Counter for the RTP sequence number 453 that is part of the Initialization vector (IV) for many cryptographic 454 transforms. This enables quicker and easier options for joining a 455 long lived secure RTP group, for example a broadcast session. 457 RTP header extensions are normally carried in the clear and only 458 integrity protected in SRTP. This can be problematic in some cases, 459 so [RFC6904] defines an extension to also encrypt selected header 460 extensions. 462 SRTP is specified and deployed in a number of RTP usage contexts; 463 Significant support in SIP-established VoIP clients including IMS; 464 RTSP [I-D.ietf-mmusic-rfc2326bis] and RTP based media streaming. 465 Thus SRTP in general is widely deployed. When it comes to 466 cryptographic transforms the default (AES CM and HMAC-SHA-1) is the 467 most common used. 469 SRTP does not contain an integrated key-management solution, and 470 instead relies on an external key management protocol. There are 471 several protocols that can be used. The following sections outline 472 some popular schemes. 474 3.1.1. Key Management for SRTP: DTLS-SRTP 476 A Datagram Transport Layer Security extension exists for establishing 477 SRTP keys [RFC5763][RFC5764]. This extension provides secure key- 478 exchange between two peers, enabling perfect forward secrecy and 479 binding strong identity verification to an end-point. The default 480 key generation will generate a key that contains material contributed 481 by both peers. The key-exchange happens in the media plane directly 482 between the peers. The common key-exchange procedures will take two 483 round trips assuming no losses. TLS resumption can be used when 484 establishing additional media streams with the same peer, and reduces 485 the set-up time to one RTT for these streams (see [RFC5764] for a 486 discussion of TLS resumption in this context). 488 The actual security properties of an established SRTP session using 489 DTLS will depend on the cipher suites offered and used. For example 490 some provide perfect forward secrecy (PFS), while other do not. When 491 using DTLS, the application designer needs to select which cipher 492 suites DTLS-SRTP can offer and accept so that the desired security 493 properties are achieved. 495 DTLS-SRTP key management can use the signalling protocol in four 496 ways. First, to agree on using DTLS-SRTP for media security. 497 Secondly, to determine the network location (address and port) where 498 each side is running a DTLS listener to let the parts perform the 499 key-management handshakes that generate the keys used by SRTP. 500 Thirdly, to exchange hashes of each side's certificates to bind these 501 to the signalling, and ensure there is no man-in-the-middle attack. 502 Finally to provide an assertable identity, e.g. [RFC4474] that can 503 be used to prevent modification of the signalling and the exchange of 504 certificate hashes. That way enabling binding between the key- 505 exchange and the signalling. 507 This usage is well defined for SIP/SDP in [RFC5763], and in most 508 cases can be adopted for use with other bi-directional signalling 509 solutions. It is to be noted that there is work underway to revisit 510 the SIP Identity mechanism [RFC4474] in the IETF STIR working group. 512 DTLS-SRTP usage is clearly on the rise. It is mandatory to support 513 in WebRTC. It has growing support among SIP end-points. DTLS-SRTP 514 was developed in IETF primarily to meet security requirements for 515 SIP. 517 3.1.2. Key Management for SRTP: MIKEY 518 Multimedia Internet Keying (MIKEY) [RFC3830] is a keying protocol 519 that has several modes with different properties. MIKEY can be used 520 in point-to-point applications using SIP and RTSP (e.g., VoIP calls), 521 but is also suitable for use in broadcast and multicast applications, 522 and centralized group communications. 524 MIKEY can establish multiple security contexts or cryptographic 525 sessions with a single message. It is useable in scenarios where one 526 entity generates the key and needs to distribute the key to a number 527 of participants. The different modes and the resulting properties 528 are highly dependent on the cryptographic method used to establish 529 the Traffic Generation Key (TGK) that is used to derive the keys 530 actually used by the security protocol, like SRTP. 532 MIKEY has the following modes of operation: 534 Pre-Shared Key: Uses a pre-shared secret for symmetric key crypto 535 used to secure a keying message carrying the already generated 536 TGK. This system is the most efficient from the perspective of 537 having small messages and processing demands. The downside is 538 scalability, where usually the effort for the provisioning of pre- 539 shared keys is only manageable if the number of endpoints is 540 small. 542 Public Key encryption: Uses a public key crypto to secure a keying 543 message carrying the already-generated TGK. This is more resource 544 intensive but enables scalable systems. It does require a public 545 key infrastructure to enable verification. 547 Diffie-Hellman: Uses Diffie-Hellman key-agreement to generate the 548 TGK, thus providing perfect forward secrecy. The downside is high 549 resource consumption in bandwidth and processing during the MIKEY 550 exchange. This method can't be used to establish group keys as 551 each pair of peers performing the MIKEY exchange will establish 552 different keys. 554 HMAC-Authenticated Diffie-Hellman: [RFC4650] defines a variant of 555 the Diffie-Hellman exchange that uses a pre-shared key in a keyed 556 HMAC to verify authenticity of the keying material instead of a 557 digital signature as in the previous method. This method is still 558 restricted to point-to-point usage. 560 RSA-R: MIKEY-RSA in Reverse mode [RFC4738] is a variant of the 561 public key method which doesn't rely on the initiator of the key- 562 exchange knowing the responder's certificate. This method lets 563 both the initiator and the responder to specify the TGK material 564 depending on use case. Usage of this mode requires one round-trip 565 time. 567 TICKET: [RFC6043] is a MIKEY extension using trusted centralized key 568 management service and tickets, like Kerberos. 570 IBAKE: [RFC6267] uses a key management services (KMS) infrastructure 571 but with lower demand on the KMS. Claims to provides both perfect 572 forward and backwards secrecy, the exact meaning is unclear (See 573 Perfect Forward Secrecy in [RFC4949]). 575 SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption in MIKEY. 576 Based on Identity based Public Key Cryptography and a KMS 577 infrastructure to establish a shared secret value and certificate 578 less signatures to provide source authentication. It's features 579 include simplex transmission, scalability, low-latency call set- 580 up, and support for secure deferred delivery. 582 MIKEY messages have several different transports. [RFC4567] defines 583 how MIKEY messages can be embedded in general SDP for usage with the 584 signalling protocols SIP, SAP and RTSP. There also exist a 3GPP 585 defined usage of MIKEY that sends MIKEY messages directly over UDP to 586 key the receivers of Multimedia Broadcast and Multicast Service 587 (MBMS) [T3GPP.33.246]. 589 Based on the many choices it is important to consider the properties 590 needed in ones solution and based on that evaluate which modes that 591 are candidates for ones usage. More information on the applicability 592 of the different MIKEY modes can be found in [RFC5197]. 594 MIKEY with pre-shared keys are used by 3GPP MBMS [T3GPP.33.246]. 595 While RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] specifies use of the 596 RSA-R mode. There are some SIP end-points that support MIKEY. The 597 modes they use are unknown to the authors. 599 3.1.3. Key Management for SRTP: Security Descriptions 601 [RFC4568] provides a keying solution based on sending plain text keys 602 in SDP [RFC4566]. It is primarily used with SIP and the SDP Offer/ 603 Answer model, and is well-defined in point-to-point sessions where 604 each side declares its own unique key. Using Security Descriptions 605 to establish group keys is less well defined, and can have security 606 issues since it's difficult to guarantee unique SSRCs (as needed to 607 avoid a "two-time pad" attack - see Section 9 of [RFC3711]). 609 Since keys are transported in plain text in SDP, they can easily be 610 intercepted unless the SDP carrying protocol provides strong end-to- 611 end confidentiality and authentication guarantees. This is not 612 normally the case, where instead hop-by-hop security is provided 613 between signalling nodes using TLS. This leaves the keying material 614 sensitive to capture by the traversed signalling nodes. Thus, in 615 most cases, the security properties of security descriptions are 616 weak. The usage of security descriptions usually requires additional 617 security measures, e.g. the signalling nodes be trusted and 618 protected by strict access control. Usage of security descriptions 619 requires careful design in order to ensure that the security goals 620 can be met. 622 Security Descriptions is the most commonly deployed keying solution 623 for SIP-based end-points, where almost all end-points that support 624 SRTP also support Security Descriptions. 626 3.1.4. Key Management for SRTP: Encrypted Key Transport 628 Encrypted Key Transport (EKT) [I-D.ietf-avtcore-srtp-ekt] is an SRTP 629 extension that enables group keying despite using a keying mechanism 630 like DTLS-SRTP that doesn't support group keys. It is designed for 631 centralized conferencing, but can also be used in sessions where end- 632 points connect to a conference bridge or a gateway, and need to be 633 provisioned with the keys each participant on the bridge or gateway 634 uses to avoid decryption and encryption cycles on the bridge or 635 gateway. This can enable interworking between DTLS-SRTP and other 636 keying systems where either party can set the key (e.g., interworking 637 with security descriptions). 639 The mechanism is based on establishing an additional EKT key which 640 everyone uses to protect their actual session key. The actual 641 session key is sent in a expanded authentication tag to the other 642 session participants. This key is only sent occasionally or 643 periodically depending on use cases and depending on what 644 requirements exist for timely delivery or notification. 646 The only known deployment of EKT so far are in some Cisco video 647 conferencing products. 649 3.1.5. Key Management for SRTP: Other systems 651 The ZRTP [RFC6189] key-management system for SRTP was proposed as an 652 alternative to DTLS-SRTP. ZRTP provides best effort encryption 653 independent of the signalling protocol and utilizes key continuity, 654 Short Authentication Strings, or a PKI for authentication. ZRTP 655 wasn't adopted as an IETF standards track protocol, but was instead 656 published as an informational RFC. Commercial implementations exist. 658 Additional proprietary solutions are also known to exist. 660 3.2. RTP Legacy Confidentiality 661 Section 9 of the RTP standard [RFC3550] defines a DES or 3DES based 662 encryption of RTP and RTCP packets. This mechanism is keyed using 663 plain text keys in SDP [RFC4566] using the "k=" SDP field. This 664 method can provide confidentiality but, as discussed in Section 9 of 665 [RFC3550], it has extremely weak security properties and is not to be 666 used. 668 3.3. IPsec 670 IPsec [RFC4301] can be used in either tunnel or transport mode to 671 protect RTP and RTCP packets in transit from one network interface to 672 another. This can be sufficient when the network interfaces have a 673 direct relation, or in a secured environment where it can be 674 controlled who can read the packets from those interfaces. 676 The main concern with using IPsec to protect RTP traffic is that in 677 most cases using a VPN approach that terminates the security 678 association at some node prior to the RTP end-point leaves the 679 traffic vulnerable to attack between the VPN termination node and the 680 end-point. Thus usage of IPsec requires careful thought and design 681 of its usage so that it meets the security goals. A important 682 question is how one ensures the IPsec terminating peer and the 683 ultimate destination are the same. 685 IPsec with RTP is more commonly used as a security solution between 686 infrastructure nodes that exchange many RTP sessions and media 687 streams. The establishment of a secure tunnel between such nodes 688 minimizes the key-management overhead. 690 3.4. DTLS for RTP and RTCP 692 Datagram Transport Layer Security (DTLS) [RFC6347] can provide point- 693 to-point security for RTP flows. The two peers establish an DTLS 694 association between each other, including the possibility to do 695 certificate-based source authentication when establishing the 696 association. All RTP and RTCP packets flowing will be protected by 697 this DTLS association. 699 Note that using DTLS for RTP flows is different to using DTLS-SRTP 700 key management. DTLS-SRTP uses the same key-management steps as 701 DTLS, but uses SRTP for the per packet security operations. Using 702 DTLS for RTP flows uses the normal datagram TLS data protection, 703 wrapping complete RTP packets. When using DTLS for RTP flows, the 704 RTP and RTCP packets are completely encrypted with no headers in the 705 clear; when using DTLS-SRTP, the RTP headers are in the clear and 706 only the payload data is encrypted. 708 DTLS can use similar techniques to those available for DTLS-SRTP to 709 bind a signalling-side agreement to communicate to the certificates 710 used by the end-point when doing the DTLS handshake. This enables 711 use without having a certificate-based trust chain to a trusted 712 certificate root. 714 There does not appear to be significant usage of DTLS for RTP. 716 3.5. TLS over TCP 718 When RTP is sent over TCP [RFC4571] it can also be sent over TLS over 719 TCP [RFC4572], using TLS to provide point to point security services. 720 The security properties TLS provides are confidentiality, integrity 721 protection and possible source authentication if the client or server 722 certificates are verified and provide a usable identity. When used 723 in multi-party scenarios using a central node for media distribution, 724 the security provide is only between the central node and the peers, 725 so the security properties for the whole session are dependent on 726 what trust one can place in the central node. 728 RTSP 1.0 [RFC2326] and 2.0 [I-D.ietf-mmusic-rfc2326bis] specifies the 729 usage of RTP over the same TLS/TCP connection that the RTSP messages 730 are sent over. It appears that RTP over TLS/TCP is also used in some 731 proprietary solutions that uses TLS to bypass firewalls. 733 3.6. Media Content Security/Digital Rights Management 735 Mechanisms have been defined that encrypt only the media content, 736 operating within the RTP payload data and leaving the RTP headers and 737 RTCP unaffected. There are several reasons why this might be 738 appropriate, but a common rationale is to ensure that the content 739 stored by RTSP streaming servers has the media content in a protected 740 format that cannot be read by the streaming server (this is mostly 741 done in the context of Digital Rights Management). These approaches 742 then use a key-management solution between the rights provider and 743 the consuming client to deliver the key used to protect the content 744 and do not include the media server in the security context. Such 745 methods have several security weaknesses such the fact that the same 746 key is handed out to a potentially large group of receiving clients, 747 increasing the risk of a leak. 749 Use of this type of solution can be of interest in environments that 750 allow middleboxes to rewrite the RTP headers and select which streams 751 are delivered to an end-point (e.g., some types of centralised video 752 conference systems). The advantage of encrypting and possibly 753 integrity protecting the payload but not the headers is that the 754 middlebox can't eavesdrop on the media content, but can still provide 755 stream switching functionality. The downside of such a system is 756 that it likely needs two levels of security: the payload level 757 solution to provide confidentiality and source authentication, and a 758 second layer with additional transport security ensuring source 759 authentication and integrity of the RTP headers associated with the 760 encrypted payloads. This can also results in the need to have two 761 different key-management systems as the entity protecting the packets 762 and payloads are different with different set of keys. 764 The aspect of two tiers of security are present in ISMAcryp (see 765 Section 3.6.1) and the deprecated 3GPP Packet Based Streaming Service 766 Annex.K [T3GPP.26.234R8] solution. 768 3.6.1. ISMA Encryption and Authentication 770 The Internet Streaming Media Alliance (ISMA) has defined ISMA 771 Encryption and Authentication 2.0 [ISMACrypt2]. This specification 772 defines how one encrypts and packetizes the encrypted application 773 data units (ADUs) in an RTP payload using the MPEG-4 Generic payload 774 format [RFC3640]. The ADU types that are allowed are those that can 775 be stored as elementary streams in an ISO Media File format based 776 file. ISMAcryp uses SRTP for packet level integrity and source 777 authentication from a streaming server to the receiver. 779 Key-management for a ISMACryp based system can be achieved through 780 Open Mobile Alliance (OMA) Digital Rights Management 2.0 [OMADRMv2], 781 for example. 783 4. Securing RTP Applications 785 In the following we provide guidelines for how to choose appropriate 786 security mechanisms for RTP applications. 788 4.1. Application Requirements 790 This section discusses a number of application requirements that need 791 be considered. An application designer choosing security solutions 792 requires a good understanding of what level of security is needed and 793 what behaviour they strive to achieve. 795 4.1.1. Confidentiality 797 When it comes to confidentiality of an RTP session there are several 798 aspects to consider: 800 Probability of compromise: When using encryption to provide media 801 confidentiality, it is necessary to have some rough understanding 802 of the security goal and how long one expect the protected content 803 to remain confidential. National or other regulations might 804 provide additional requirements on a particular usage of an RTP. 805 From that, one can determine which encryption algorithms are to be 806 used from the set of available transforms. 808 Potential for other leakage: RTP based security in most of its forms 809 simply wraps RTP and RTCP packets into cryptographic containers. 810 This commonly means that the size of the original RTP payload is 811 visible to observers of the protected packet flow. This can 812 provide information to those observers. A well-documented case is 813 the risk with variable bit-rate speech codecs that produce 814 different sized packets based on the speech input [RFC6562]. 815 Potential threats such as these need to be considered and, if they 816 are significant, then restrictions will be needed on mode choices 817 in the codec, or additional padding will need to be added to make 818 all packets equal size and remove the informational leakage. 820 Another case is RTP header extensions. If SRTP is used, header 821 extensions are normally not protected by the security mechanism 822 protecting the RTP payload. If the header extension carries 823 information that is considered sensitive, then the application 824 needs to be modified to ensure that mechanisms used to protect 825 against such information leakage are employed. 827 Who has access: When considering the confidentiality properties of a 828 system, it is important to consider where the media handled in the 829 clear. For example, if the system is based on an RTP mixer that 830 needs the keys to decrypt the media, process, and repacketize it, 831 then is the mixer providing the security guarantees expected by 832 the other parts of the system? Furthermore, it is important to 833 consider who has access to the keys. The policies for the 834 handling of the keys, and who can access the keys, need to be 835 considered along with the confidentiality goals. 837 As can be seen the actual confidentiality level has likely more to do 838 with the application's usage of centralized nodes, and the details of 839 the key-management solution chosen, than with the actual choice of 840 encryption algorithm (although, of course, the encryption algorithm 841 needs to be chosen appropriately for the desired security level). 843 4.1.2. Integrity 845 Protection against modification of content by a third party, or due 846 to errors in the network, is another factor to consider. The first 847 aspect that one considers is what resilience one has against 848 modifications to the content. Some media types are extremely 849 sensitive to network bit errors, whereas others might be able to 850 tolerate some degree of data corruption. Equally important is to 851 consider the sensitivity of the content, who is providing the 852 integrity assertion, what is the source of the integrity tag, and 853 what are the risks of modifications happening prior to that point 854 where protection is applied? These issues affect what cryptographic 855 algorithm is used, and the length of the integrity tags, and whether 856 the entire payload is protected. 858 RTP applications that rely on central nodes need to consider if hop- 859 by-hop integrity is acceptable, or if true end-to-end integrity 860 protection is needed? Is it important to be able to tell if a 861 middlebox has modified the data? There are some uses of RTP that 862 require trusted middleboxes that can modify the data in a way that 863 doesn't break integrity protection as seen by the receiver, for 864 example local advertisement insertion in IPTV systems; there are also 865 uses where it is essential that such in-network modification be 866 detectable. RTP can support both, with appropriate choices of 867 security mechanisms. 869 Integrity of the data is commonly closely tied to the question of 870 source authentication. That is, it becomes important to know who 871 makes an integrity assertion for the data. 873 4.1.3. Source Authentication 875 Source authentication is about determining who sent a particular RTP 876 or RTCP packet. It is normally closely tied with integrity, since a 877 receiver generally also wants to ensure that the data received is 878 what the source really sent, so source authentication without 879 integrity is not particularly useful. Similarly, integrity 880 protection without source authentication is also not particularly 881 useful; a claim that a packet is unchanged that cannot itself be 882 validated as from the source (or some from other known and trusted 883 party) is meaningless. 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 provide 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 likely from a source that 893 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. If only the two peers 897 have access to the keys, this can form a basis for a strong trust 898 relationship that traffic is authenticated coming from one of the 899 peers. However, in a multi-party scenario where security contexts 900 are shared among participants, most base-level authentication 901 solutions can't even assert that this packet is from the same 902 source as the previous packet. 904 Binding the source and the signalling: A step up in the assertion 905 that can be done in base-level systems is to tie the signalling to 906 the key-exchange. Here, the goal is to at least be able to assert 907 that the source of the packets is the same entity that the 908 receiver established the session with. How feasible this is 909 depends on the properties of the key-management system, the 910 ability to tie the signalling to a particular source, and the 911 degree of trust the receiver places on the different nodes 912 involved. 914 For example, systems where the key-exchange is done using the 915 signalling systems, such as Security Descriptions [RFC4568], 916 enable a direct binding between signalling and key-exchange. In 917 such systems, the actual security depends on the trust one can 918 place in the signalling system to correctly associate the peer's 919 identity with the key-exchange. 921 Using Identities: If the applications have access to a system that 922 can provide verifiable identities, then the source authentication 923 can be bound to that identity. For example, in a point-to-point 924 communication even symmetric key crypto, where the key-management 925 can assert that the key has only been exchanged with a particular 926 identity, can provide a strong assertion about the source of the 927 traffic. SIP identity [RFC4474] provides one example of how this 928 can be done, and could be used to bind DTLS-SRTP certificates to 929 the identity provider's public key to authenticate the source of a 930 DTLS-SRTP flow. 932 Note that all levels of the system need to have matching 933 capability to assert identity. If the signalling can assert that 934 only a given entity in a multiparty session has a key, then the 935 media layer might be able to provide guarantees about the identity 936 of the media sender. However, using an signalling authentication 937 mechanism built on a group key can limit the media layer to 938 asserting only group membership. 940 4.1.4. Identity 942 There exist many different types of identity systems with different 943 properties (e.g., SIP identity [RFC4474]). In the context of RTP 944 applications, the most important property is the possibility to 945 perform source authentication and verify such assertions in relation 946 to any claimed identities. What an identity really is can also vary 947 but, in the context of communication, one of the most obvious is the 948 identity of the human user one communicates with. However, the human 949 user can also have additional identities in a particular role. For 950 example, the human Alice, can also be a police officer and in some 951 cases her identity as police officer will be more relevant then that 952 she is Alice. This is common in contact with organizations, where it 953 is important to prove the persons right to represent the 954 organization. Some examples of identity mechanisms that can be used: 956 Certificate based: A certificate is used to prove the identity, by 957 having access to the private part of the certificate one can 958 perform signing to assert ones identity. Any entity interested in 959 verifying the assertion then needs the public part of the 960 certificate. By having the certificate, one can verify the 961 signature against the certificate. The next step is to determine 962 if one trusts the certificate's trust chain. Commonly by 963 provisioning the verifier with the public part of a root 964 certificate, this enables the verifier to verify a trust chain 965 from the root certificate down to the identity certificate. 966 However, the trust is based on all steps in the certificate chain 967 being verifiable and trusted. Thus provisioning of root 968 certificates and the ability to revoke compromised certificates 969 are aspects that will require infrastructure. 971 Online Identity Providers: An online identity provider (IdP) can 972 authenticate a user's right to use an identity, then perform 973 assertions on their behalf or provision the requester with short- 974 term credentials to assert their identity. The verifier can then 975 contact the IdP to request verification of a particular identity. 976 Here the trust is highly dependent on how much one trusts the IdP. 977 The system also becomes dependent on having access to the relevant 978 IdP. 980 In all of the above examples, an important part of the security 981 properties are related to the method for authenticating the access to 982 the identity. 984 4.1.5. Privacy 986 RTP applications need to consider what privacy goals they have. As 987 RTP applications communicate directly between peers in many cases, 988 the IP addresses of any communication peer will be available. The 989 main privacy concern with IP addresses is related to geographical 990 location and the possibility to track a user of an end-point. The 991 main way of avoid such concerns is the introduction of relay (e.g., a 992 TURN server [RFC5766]) or centralized media mixers or forwarders that 993 hides the address of a peer from any other peer. The security and 994 trust placed in these relays obviously needs to be carefully 995 considered. 997 RTP itself can contribute to enabling a particular user to be tracked 998 between communication sessions if the CNAME is generated according to 999 the RTP specification in the form of user@host. Such RTCP CNAMEs are 1000 likely long term stable over multiple sessions, allowing tracking of 1001 users. This can be desirable for long-term fault tracking and 1002 diagnosis, but clearly has privacy implications. Instead 1003 cryptographically random ones could be used as defined by Guidelines 1004 for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) 1005 [I-D.ietf-avtcore-6222bis]. 1007 If there exist privacy goals, these need to be considered, and the 1008 system designed with them in mind. In addition certain RTP features 1009 might have to be configured to safeguard privacy, or have 1010 requirements on how the implementation is done. 1012 4.2. Application Structure 1014 When it comes to RTP security, the most appropriate solution is often 1015 highly dependent on the topology of the communication session. The 1016 signalling also impacts what information can be provided, and if this 1017 can be instance specific, or common for a group. In the end the key- 1018 management system will highly affect the security properties achieved 1019 by the application. At the same time, the communication structure of 1020 the application limits what key management methods are applicable. 1021 As different key-management have different requirements on underlying 1022 infrastructure it is important to take that aspect into consideration 1023 early in the design. 1025 4.3. Interoperability 1027 Few RTP applications exist as independent applications that never 1028 interoperate with anything else. Rather, they enable communication 1029 with a potentially large number of other systems. To minimize the 1030 number of security mechanisms that need to be implemented, it is 1031 important to consider if one can use the same security mechanisms as 1032 other applications. This can also reduce problems of determining 1033 what security level is actually negotiated in a particular session. 1035 The desire to be interoperable can, in some cases, be in conflict 1036 with the security requirements of an application. To meet the 1037 security goals, it might be necessary to sacrifice interoperability. 1038 Alternatively, one can implement multiple security mechanisms, this 1039 however introduces the complication of ensuring that the user 1040 understands what it means to use a particular security system. In 1041 addition, the application can then become vulnerable to bid-down 1042 attack. 1044 5. Examples 1046 In the following we describe a number of example security solutions 1047 for applications using RTP services or frameworks. These examples 1048 are provided to illustrate the choices available. They are not 1049 normative recommendations for security. 1051 5.1. Media Security for SIP-established Sessions using DTLS-SRTP 1053 The IETF evaluated media security for RTP sessions established using 1054 point-to-point SIP sessions in 2009. A number of requirements were 1055 determined, and based on those, the existing solutions for media 1056 security and especially the keying methods were analysed. The 1057 resulting requirements and analysis were published in [RFC5479]. 1058 Based on this analysis and working group discussion, DTLS-SRTP was 1059 determined to be the best solution. 1061 The security solution for SIP using DTLS-SRTP is defined in the 1062 Framework for Establishing a Secure Real-time Transport Protocol 1063 (SRTP) Security Context Using Datagram Transport Layer Security 1064 (DTLS) [RFC5763]. On a high level the framework uses SIP with SDP 1065 offer/answer procedures to exchange the network addresses where the 1066 server end-point will have a DTLS-SRTP enable server running. The 1067 SIP signalling is also used to exchange the fingerprints of the 1068 certificate each end-point will use in the DTLS establishment 1069 process. When the signalling is sufficiently completed, the DTLS- 1070 SRTP client performs DTLS handshakes and establishes SRTP session 1071 keys. The clients also verify the fingerprints of the certificates 1072 to verify that no man in the middle has inserted themselves into the 1073 exchange. 1075 DTLS has a number of good security properties. For example, to 1076 enable a man in the middle someone in the signalling path needs to 1077 perform an active action and modify both the signalling message and 1078 the DTLS handshake. There also exists solutions that enables the 1079 fingerprints to be bound to identities. SIP Identity provides an 1080 identity established by the first proxy for each user [RFC4474]. 1081 This reduces the number of nodes the connecting user User Agent has 1082 to trust to include just the first hop proxy, rather than the full 1083 signalling path. 1085 5.2. Media Security for WebRTC Sessions 1087 Web Real-Time Communication (WebRTC) [I-D.ietf-rtcweb-overview] is a 1088 solution providing JavaScript web applications with real-time media 1089 directly between browsers. Media is transported using RTP protected 1090 using a mandatory application of SRTP [RFC3711], with keying done 1091 using DTLS-SRTP [RFC5764]. The security configuration is further 1092 defined in the WebRTC Security Architecture 1093 [I-D.ietf-rtcweb-security-arch]. 1095 A hash of the peer's certificate is provided to the JavaScript web 1096 application, allowing that web application to verify identity of the 1097 peer. There are several ways in which the certificate hashes can be 1098 verified. An approach identified in the WebRTC security architecture 1099 [I-D.ietf-rtcweb-security-arch] is to use an identity provider. In 1100 this solution the Identity Provider, which is a third party to the 1101 web application, signs the DTLS-SRTP hash combined with a statement 1102 on the validity of the user identity that has been used to sign the 1103 hash. The receiver of such an identity assertion can then 1104 independently verify the user identity to ensure that it is the 1105 identity that the receiver intended to communicate with, and that the 1106 cryptographic assertion holds; this way a user can be certain that 1107 the application also can't perform a MITM and acquire the keys to the 1108 media communication. Other ways of verifying the certificate hashes 1109 exist, for example they could be verified against a hash carried in 1110 some out of band channel (e.g., compare with a hash printed on a 1111 business card), or using a verbal short authentication string (e.g., 1112 as in ZRTP [RFC6189]), or using hash continuity. 1114 In the development of WebRTC there has also been attention given to 1115 privacy considerations. The main RTP-related concerns that have been 1116 raised are: 1118 Location Disclosure: As ICE negotiation [RFC5245] provides IP 1119 addresses and ports for the browser, this leaks location 1120 information in the signalling to the peer. To prevent this one 1121 can block the usage of any ICE candidate that isn't a relay 1122 candidate, i.e. where the IP and port provided belong to the 1123 service providers media traffic relay. 1125 Prevent tracking between sessions: static RTP CNAMEs and DTLS-SRTP 1126 certificates provide information that is re-used between session 1127 instances. Thus to prevent tracking, such information is ought 1128 not be re-used between sessions, or the information ought not sent 1129 in the clear. 1131 Note: The above cases are focused on providing privacy from other 1132 parties, not on providing privacy from the web server that provides 1133 the WebRTC Javascript application. 1135 5.3. 3GPP Packet Based Streaming Service (PSS) 1137 The 3GPP Release 11 PSS specification of the Packet Based Streaming 1138 Service (PSS) [T3GPP.26.234R11] defines, in Annex R, a set of 1139 security mechanisms. These security mechanisms are concerned with 1140 protecting the content from being captured, i.e. Digital Rights 1141 Management. To meet these goals with the specified solution, the 1142 client implementation and the application platform are trusted to 1143 protect against access and modification by an attacker. 1145 PSS is RTSP 1.0 [RFC2326] controlled media streaming over RTP. Thus 1146 an RTSP client whose user wants to access a protected content will 1147 request a session description (SDP [RFC4566]) for the protected 1148 content. This SDP will indicate that the media is ISMA Crypt 2.0 1149 [ISMACrypt2] protected media encoding application units (AUs). The 1150 key(s) used to protect the media are provided in either of two ways. 1151 If a single key is used then the client uses some DRM system to 1152 retrieve the key as indicated in the SDP. Commonly OMA DRM v2 1153 [OMADRMv2] will be used to retrieve the key. If multiple keys are to 1154 be used, then an additional RTSP stream for key-updates in parallel 1155 with the media streams is established, where key updates are sent to 1156 the client using Short Term Key Messages defined in the "Service and 1157 Content Protection for Mobile Broadcast Services" section of the OMA 1158 Mobile Broadcast Services [OMABCAST]. 1160 Worth noting is that this solution doesn't provide any integrity 1161 verification method for the RTP header and payload header 1162 information, only the encoded media AU is protected. 3GPP has not 1163 defined any requirement for supporting any solution that could 1164 provide that service. Thus, replay or insertion attacks are 1165 possible. Another property is that the media content can be 1166 protected by the ones providing the media, so that the operators of 1167 the RTSP server has no access to unprotected content. Instead all 1168 that want to access the media is supposed to contact the DRM keying 1169 server and if the device is acceptable they will be given the key to 1170 decrypt the media. 1172 To protect the signalling, RTSP 1.0 supports the usage of TLS. This 1173 is, however, not explicitly discussed in the PSS specification. 1174 Usage of TLS can prevent both modification of the session description 1175 information and help maintain some privacy of what content the user 1176 is watching as all URLs would then be confidentiality protected. 1178 5.4. RTSP 2.0 1180 Real-time Streaming Protocol 2.0 [I-D.ietf-mmusic-rfc2326bis] offers 1181 an interesting comparison to the PSS service (Section 5.3) that is 1182 based on RTSP 1.0 and service requirements perceived by mobile 1183 operators. A major difference between RTSP 1.0 and RTSP 2.0 is that 1184 2.0 is fully defined under the requirement to have mandatory to 1185 implement security mechanism. As it specifies how one transport 1186 media over RTP it is also defining security mechanisms for the RTP 1187 transported media streams. 1189 The security goals for RTP in RTSP 2.0 is to ensure that there is 1190 confidentiality, integrity and source authentication between the RTSP 1191 server and the client. This to prevent eavesdropping on what the 1192 user is watching for privacy reasons and to prevent replay or 1193 injection attacks on the media stream. To reach these goals, the 1194 signalling also has to be protected, requiring the use of TLS between 1195 the client and server. 1197 Using TLS-protected signalling the client and server agree on the 1198 media transport method when doing the SETUP request and response. 1199 The secured media transport is SRTP (SAVP/RTP) normally over UDP. 1200 The key management for SRTP is MIKEY using RSA-R mode. The RSA-R 1201 mode is selected as it allows the RTSP Server to select the key 1202 despite having the RTSP Client initiate the MIKEY exchange. It also 1203 enables the reuse of the RTSP servers TLS certificate when creating 1204 the MIKEY messages thus ensuring a binding between the RTSP server 1205 and the key exchange. Assuming the SETUP process works, this will 1206 establish a SRTP crypto context to be used between the RTSP Server 1207 and the Client for the RTP transported media streams. 1209 6. IANA Considerations 1211 This document makes no request of IANA. 1213 Note to RFC Editor: this section can be removed on publication as an 1214 RFC. 1216 7. Security Considerations 1218 This entire document is about security. Please read it. 1220 8. Acknowledgements 1222 We thank the IESG for their careful review of 1223 [I-D.ietf-avt-srtp-not-mandatory] which led to the writing of this 1224 memo. 1226 The authors wished to thank Christian Correll, Dan Wing, Kevin Gross, 1227 Alan Johnston and Ole Jacobsen for review and proposals for 1228 improvements of the text. 1230 9. Informative References 1232 [I-D.ietf-avt-srtp-not-mandatory] 1233 Perkins, C. and M. Westerlund, "Securing the RTP Protocol 1234 Framework: Why RTP Does Not Mandate a Single Media 1235 Security Solution", draft-ietf-avt-srtp-not-mandatory-13 1236 (work in progress), May 2013. 1238 [I-D.ietf-avtcore-6222bis] 1239 Begen, A., Perkins, C., Wing, D., and E. Rescorla, 1240 "Guidelines for Choosing RTP Control Protocol (RTCP) 1241 Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06 1242 (work in progress), July 2013. 1244 [I-D.ietf-avtcore-aria-srtp] 1245 Kim, W., Lee, J., Kim, D., Park, J., and D. Kwon, "The 1246 ARIA Algorithm and Its Use with the Secure Real-time 1247 Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-04 1248 (work in progress), August 2013. 1250 [I-D.ietf-avtcore-srtp-aes-gcm] 1251 McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated 1252 Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp- 1253 aes-gcm-07 (work in progress), July 2013. 1255 [I-D.ietf-avtcore-srtp-ekt] 1256 McGrew, D., Wing, D., and K. Fischer, "Encrypted Key 1257 Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00 1258 (work in progress), July 2012. 1260 [I-D.ietf-mmusic-rfc2326bis] 1261 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1262 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1263 (RTSP)", draft-ietf-mmusic-rfc2326bis-34 (work in 1264 progress), April 2013. 1266 [I-D.ietf-rtcweb-overview] 1267 Alvestrand, H., "Overview: Real Time Protocols for Brower- 1268 based Applications", draft-ietf-rtcweb-overview-07 (work 1269 in progress), August 2013. 1271 [I-D.ietf-rtcweb-security-arch] 1272 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 1273 rtcweb-security-arch-07 (work in progress), July 2013. 1275 [ISMACrypt2] 1276 , "ISMA Encryption and Authentication, Version 2.0 release 1277 version", November 2007. 1279 [OMABCAST] 1280 Open Mobile Alliance, "OMA Mobile Broadcast Services 1281 V1.0", February 2009. 1283 [OMADRMv2] 1284 Open Mobile Alliance, "OMA Digital Rights Management 1285 V2.0", July 2008. 1287 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1288 RFC 1112, August 1989. 1290 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1291 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1293 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 1294 Engineering Task Force Standard Protocols", BCP 61, RFC 1295 3365, August 2002. 1297 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1298 Jacobson, "RTP: A Transport Protocol for Real-Time 1299 Applications", STD 64, RFC 3550, July 2003. 1301 [RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., 1302 and P. Gentric, "RTP Payload Format for Transport of 1303 MPEG-4 Elementary Streams", RFC 3640, November 2003. 1305 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1306 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1307 RFC 3711, March 2004. 1309 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1310 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1311 August 2004. 1313 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1314 Internet Protocol", RFC 4301, December 2005. 1316 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 1317 Stream Loss-Tolerant Authentication (TESLA) in the Secure 1318 Real-time Transport Protocol (SRTP)", RFC 4383, February 1319 2006. 1321 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1322 Authenticated Identity Management in the Session 1323 Initiation Protocol (SIP)", RFC 4474, August 2006. 1325 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1326 Description Protocol", RFC 4566, July 2006. 1328 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 1329 Carrara, "Key Management Extensions for Session 1330 Description Protocol (SDP) and Real Time Streaming 1331 Protocol (RTSP)", RFC 4567, July 2006. 1333 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1334 Description Protocol (SDP) Security Descriptions for Media 1335 Streams", RFC 4568, July 2006. 1337 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1338 and RTP Control Protocol (RTCP) Packets over Connection- 1339 Oriented Transport", RFC 4571, July 2006. 1341 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1342 Transport Layer Security (TLS) Protocol in the Session 1343 Description Protocol (SDP)", RFC 4572, July 2006. 1345 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1346 IP", RFC 4607, August 2006. 1348 [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for 1349 Multimedia Internet KEYing (MIKEY)", RFC 4650, September 1350 2006. 1352 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 1353 RSA-R: An Additional Mode of Key Distribution in 1354 Multimedia Internet KEYing (MIKEY)", RFC 4738, November 1355 2006. 1357 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1358 Transform Carrying Roll-Over Counter for the Secure Real- 1359 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1361 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 1362 4949, August 2007. 1364 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 1365 January 2008. 1367 [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of 1368 Various Multimedia Internet KEYing (MIKEY) Modes and 1369 Extensions", RFC 5197, June 2008. 1371 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1372 (ICE): A Protocol for Network Address Translator (NAT) 1373 Traversal for Offer/Answer Protocols", RFC 5245, April 1374 2010. 1376 [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 1377 "Requirements and Analysis of Media Security Management 1378 Protocols", RFC 5479, April 2009. 1380 [RFC5669] Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The 1381 SEED Cipher Algorithm and Its Use with the Secure Real- 1382 Time Transport Protocol (SRTP)", RFC 5669, August 2010. 1384 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1385 Protocol (RTCP) Extensions for Single-Source Multicast 1386 Sessions with Unicast Feedback", RFC 5760, February 2010. 1388 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1389 for Establishing a Secure Real-time Transport Protocol 1390 (SRTP) Security Context Using Datagram Transport Layer 1391 Security (DTLS)", RFC 5763, May 2010. 1393 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1394 Security (DTLS) Extension to Establish Keys for the Secure 1395 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1397 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1398 Relays around NAT (TURN): Relay Extensions to Session 1399 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1401 [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based 1402 Modes of Key Distribution in Multimedia Internet KEYing 1403 (MIKEY)", RFC 6043, March 2011. 1405 [RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure 1406 RTP", RFC 6188, March 2011. 1408 [RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 1409 Path Key Agreement for Unicast Secure RTP", RFC 6189, 1410 April 2011. 1412 [RFC6267] Cakulev, V. and G. Sundaram, "MIKEY-IBAKE: Identity-Based 1413 Authenticated Key Exchange (IBAKE) Mode of Key 1414 Distribution in Multimedia Internet KEYing (MIKEY)", RFC 1415 6267, June 2011. 1417 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1418 Security Version 1.2", RFC 6347, January 2012. 1420 [RFC6509] Groves, M., "MIKEY-SAKKE: Sakai-Kasahara Key Encryption in 1421 Multimedia Internet KEYing (MIKEY)", RFC 6509, February 1422 2012. 1424 [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of 1425 Variable Bit Rate Audio with Secure RTP", RFC 6562, March 1426 2012. 1428 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 1429 Real-time Transport Protocol (SRTP)", RFC 6904, April 1430 2013. 1432 [T3GPP.26.234R11] 1433 3GPP, "Technical Specification Group Services and System 1434 Aspects; Transparent end-to-end Packet-switched Streaming 1435 Service (PSS); Protocols and codecs", 3GPP TS 26.234 1436 11.1.0, September 2012. 1438 [T3GPP.26.234R8] 1439 3GPP, "Technical Specification Group Services and System 1440 Aspects; Transparent end-to-end Packet-switched Streaming 1441 Service (PSS); Protocols and codecs", 3GPP TS 26.234 1442 8.4.0, September 2009. 1444 [T3GPP.26.346] 1445 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 1446 Protocols and codecs", 3GPP TS 26.346 10.7.0, March 2013. 1448 [T3GPP.33.246] 1449 3GPP, "3G Security; Security of Multimedia Broadcast/ 1450 Multicast Service (MBMS)", 3GPP TS 33.246 10.1.0, December 1451 2012. 1453 Authors' Addresses 1454 Magnus Westerlund 1455 Ericsson 1456 Farogatan 6 1457 SE-164 80 Kista 1458 Sweden 1460 Phone: +46 10 714 82 87 1461 Email: magnus.westerlund@ericsson.com 1463 Colin Perkins 1464 University of Glasgow 1465 School of Computing Science 1466 Glasgow G12 8QQ 1467 United Kingdom 1469 Email: csp@csperkins.org