RFC 7201
Options for Securing RTP Sessions
RFC 7201: Options for Securing RTP Sessions 🎀
okay bestie, this one is an IETF doc (Internet Engineering Task Force) by M. Westerlund from Ericsson and C. Perkins from the University of Glasgow 🌸. It came out in April 2014 and it's Informational, so it's published for information and isn't a Standards Track spec 💅. Its ISSN is 2070-1721. It doesn't list anything it obsoletes or updates, so there's no drama there ✨.
Abstract
okay so RTP (the Real-time Transport Protocol) is everywhere, in a huge range of apps and environments 🌈. That means there isn't one security mechanism that fits everything. You need different tools for confidentiality, integrity, and source authentication of RTP and RTCP (the RTP Control Protocol) packets, depending on where you're using them 🔥. With that many options, it's honestly hard for RTP app devs to pick the right one. This doc gives an overview of a bunch of RTP security solutions and gives devs guidance on how to choose the right one 💖.
Status of This Memo
not a standards-track spec, it's just published for info 📝. It's still an IETF product, which means it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 🫶. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🙈.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7201 🦋.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 💜.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully because they spell out your rights and restrictions for this doc 📜. Any Code Components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🧚.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Point-to-Point Sessions . . . . . . . . . . . . . . . . . 5
2.2. Sessions Using an RTP Mixer . . . . . . . . . . . . . . . 5
2.3. Sessions Using an RTP Translator . . . . . . . . . . . . 6
2.3.1. Transport Translator (Relay) . . . . . . . . . . . . 6
2.3.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 8
2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 8
2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 8
3. Security Options . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1. Key Management for SRTP: DTLS-SRTP . . . . . . . . . 12
3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . 14
3.1.3. Key Management for SRTP: Security Descriptions . . . 15
3.1.4. Key Management for SRTP: Encrypted Key Transport . . 16
3.1.5. Key Management for SRTP: ZRTP and Other Solutions . . 17
3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 17
3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4. RTP over TLS over TCP . . . . . . . . . . . . . . . . . . 18
3.5. RTP over Datagram TLS (DTLS) . . . . . . . . . . . . . . 18
3.6. Media Content Security/Digital Rights Management . . . . 19
3.6.1. ISMA Encryption and Authentication . . . . . . . . . 19
4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 20
4.1. Application Requirements . . . . . . . . . . . . . . . . 20
4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 20
4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 21
4.1.3. Source Authentication . . . . . . . . . . . . . . . . 22
4.1.4. Identifiers and Identity . . . . . . . . . . . . . . 23
4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 24
4.2. Application Structure . . . . . . . . . . . . . . . . . . 25
4.3. Automatic Key Management . . . . . . . . . . . . . . . . 25
4.4. End-to-End Security vs. Tunnels . . . . . . . . . . . . . 25
4.5. Plaintext Keys . . . . . . . . . . . . . . . . . . . . . 26
4.6. Interoperability . . . . . . . . . . . . . . . . . . . . 26
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. Media Security for SIP-Established Sessions Using
DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 27
5.3. IP Multimedia Subsystem (IMS) Media Security . . . . . . 28
5.4. 3GPP Packet-Switched Streaming Service (PSS) . . . . . . 29
5.5. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
8. Informative References . . . . . . . . . . . . . . . . . . . 311. Introduction ✨
okay so RTP [RFC3550] is used in a ton of multimedia apps 🎀. That includes VoIP, centralized multimedia conferencing, sensor data transport, and IPTV 📺. These apps go all over the place, from one-on-one phone calls to group teleconferences to huge TV distribution services 🌸. The media types can differ a lot, and so can the signaling methods used to set up the RTP sessions 🦋.
This multidimensional heterogeneity has been a blocker for building one single security solution that works for all these apps 🙈. So instead, a bunch of different solutions were built, each aimed at a different set of security goals. That makes it hard for app devs to know what's out there and whether a given solution's properties actually fit their needs 😭. This memo gives an overview of the available RTP solutions and guidance on where each one applies. It also tries to show what's actually being used and planned at the time of writing, to help with stuff like interoperability and whether implementations are available 💜. The guidance isn't exhaustive, and this memo doesn't give normative recommendations 🌈.
it's important that app devs think about their own security goals and requirements 💅. The IETF thinks protocols should have secure modes of operation and make them available to users [RFC3365]. But since RTP apps and use cases are so varied, a single security solution can't be mandated [RFC7202] 💖. So app devs need to pick mechanisms that give them the right level of security for their setup ✨. It's strongly encouraged that related apps use common mechanisms in common environments 🫶. The IETF also publishes guidelines for specific classes of apps, so it's worth searching for those 🔥.
The rest of this doc is laid out like this. Section 2 gives extra background 📚. Section 3 goes over the security mechanisms available at the time of writing and lists their key security properties and constraints 🔐. Section 4 has guidelines and important things to think about when securing an RTP app 🧚. Finally, Section 5 gives examples of app domains where security guidelines exist 👑.
2. Background 🌸
RTP can be used in a wide range of topologies because it supports point-to-point sessions, multicast groups, and other topologies built around different types of RTP middleboxes 🦋. In the sections below, we look at the different topologies RTP supports, so we can understand what they mean for the security properties and trust relations that can exist in RTP sessions 💅.
2.1. Point-to-Point Sessions 💖
the most basic setup is two directly connected endpoints, shown in Figure 1, where A has set up an RTP session with B 🎀. In this case, RTP security is mostly about making sure no third party can mess with the confidentiality and integrity of the media 🔥. That means you need confidentiality protection for the RTP session, integrity protection for RTP/RTCP packets, and source authentication for all the packets, so there's no man-in-the-middle (MITM) attack going on 😭.
Source authentication can also be tied to a user's or endpoint's verifiable identity, so the peer knows exactly who they're talking to 🫶. Here, the security protocol protecting the RTP session (and therefore the RTP and RTCP traffic) and the key management protocol both matter for figuring out what security claims you can actually make 🧚.
+---+ +---+
| A |<------->| B |
+---+ +---+
Figure 1: Point-to-Point Topology2.2. Sessions Using an RTP Mixer 🌈
An RTP mixer is a session-level middlebox you can build a multiparty RTP conference around 👑. The mixer might actually do media mixing, like mixing audio or compositing video images into a new media stream sent from the mixer to a participant. Or it might just provide a conceptual stream, like the video of the current active speaker 🎤. From a security point of view, the important things about an RTP mixer are that it generates a new media stream, has its own source identifier, and doesn't just forward the original media 🔍.
An RTP session using a mixer might look like Figure 2. In this example, participants A through D each send unicast RTP traffic to the mixer, and each gets an RTP stream back from the mixer that combines the streams from the other participants 💜.
+---+ +------------+ +---+
| A |<---->| |<---->| B |
+---+ | | +---+
| Mixer |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
Figure 2: Example RTP Mixer TopologyBecause the mixer has its own source identifier and acts as an active participant towards the other endpoints, it needs to be a trusted device that has access to the security context(s) that were set up 🙈. The mixer can also become a security-enforcing entity 💅. For example, a common way to secure the Figure 2 topology is to set up a security context between the mixer and each participant separately, and have the mixer source authenticate each peer. That way the mixer makes sure one participant can't impersonate another 🦋✨.
part 1 of 9 done bestie 💖 more parts are coming, so don't you dare leave me on read 🫶
2.3. Sessions Using an RTP Translator 🎀
RTP translators are middleboxes that do various levels of in-network media translation and transcoding 💅. Their security properties vary wildly depending on which operations they try to pull off 🙈. We're looking at three categories: transport translators, gateways, and media transcoders ✨.
2.3.1. Transport Translator (Relay) 🦋
A transport translator [RFC5117] operates on a level below RTP and RTCP 🫶. It relays the RTP/RTCP traffic from one endpoint to one or more other addresses. It can do this based only on IP addresses and transport protocol ports, and each receive port on the translator can have a very basic list of where to forward traffic. Transport translators also need to implement ingress filtering so random traffic that isn't coming from a participant in the conference doesn't get forwarded 🚫.
Figure 3 shows an example transport translator, where traffic from any one of the four participants gets forwarded to the other three participants unchanged. The topology is very giving Any Source Multicast (ASM) session (as discussed in Section 2.4), but it's implemented at the application layer 💜.
+---+ +------------+ +---+
| A |<---->| |<---->| B |
+---+ | Relay | +---+
| Translator |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
Figure 3: RTP Relay Translator TopologyA transport translator can often operate without needing access to the security context, as long as the security mechanism doesn't provide protection over the transport-layer information 🌸. Still, a transport translator does make the group communication visible, so it can complicate keying and source authentication mechanisms 👀. This is further discussed in Section 2.4 ✨.
2.3.2. Gateway 🌈
Gateways get deployed when the endpoints aren't fully compatible 🥺. Figure 4 shows an example topology. The functions a gateway provides can be super diverse and range from transport-layer relaying between two domains that aren't allowed to communicate directly, to transport or media protocol function initiation or termination, all the way to protocol- or media-encoding translation 🧚. The supported security protocol might even be one of the reasons a gateway is needed 💀.
+---+ +-----------+ +---+
| A |<---->| Gateway |<---->| B |
+---+ +-----------+ +---+
Figure 4: RTP Gateway TopologyThe choice of security protocol and the details of the gateway function will determine if the gateway needs to be trusted with access to the application security context 🔐. Many gateways need to be trusted by all peers to do the translation. In other cases, some or all peers might not even be aware the gateway is there 👻. The security protocols have different properties depending on the degree of trust and visibility needed. Making sure communication is possible without trusting the gateway can be a strong incentive for accepting different security properties 💅. Some security solutions will be able to detect gateways as manipulating the media stream, unless the gateway is a trusted device 🚨.
2.3.3. Media Transcoder 🍓
A media transcoder is a special type of gateway device that changes the encoding of the media being transported by RTP 🎬. The discussion in Section 2.3.2 applies ✨. A media transcoder alters the media data and, thus, needs to be trusted with access to the security context, no cap 🫶.
2.4. Any Source Multicast 🌊
Any Source Multicast [RFC1112] is the original multicast model, where any multicast group participant can send to the multicast group and get their packets delivered to all group members (see Figure 5) 💖. This form of communication has interesting security properties because of the many-to-many nature of the group 🤯. Source authentication is important, but all participants with access to the group security context will have the necessary secrets to decrypt and verify the integrity of the traffic. So using any group security context fails if the goal is to separate individual sources, and alternate solutions are needed 😭.
+-----+
+---+ / \ +---+
| A |----/ \---| B |
+---+ / \ +---+
+ Multicast +
+---+ \ Network / +---+
| C |----\ /---| D |
+---+ \ / +---+
+-----+
Figure 5: Any Source Multicast (ASM) GroupOn top of that, the potentially large size of multicast groups creates some considerations for the scalability of the solution and for how key management is handled 📈.
2.5. Source-Specific Multicast 🦢
Source-Specific Multicast (SSM) [RFC4607] allows only a specific endpoint to send traffic to the multicast group, no matter how many RTP media sources there are 👑. That endpoint is known as the media distribution source. For the RTP session to function correctly with RTCP over an SSM session, extensions have been defined in [RFC5760] 🛠️. Figure 6 shows a sample SSM-based RTP session where several media sources, MS1...MSm, all send media to a distribution source. The distribution source then forwards the media data to the SSM group for delivery to the receivers, R1...Rn, and the feedback targets, FT1...FTn 📦. RTCP reception quality feedback is sent unicast from each receiver to one of the feedback targets. The feedback targets aggregate reception quality feedback and forward it upstream towards the distribution source. The distribution source forwards (possibly aggregated and summarized) reception feedback to the SSM group and back to the original media sources 🔁. The feedback targets are also members of the SSM group and receive the media data, so they can send unicast repair data to the receivers in response to feedback if appropriate 🩹.
+-----+ +-----+ +-----+
| MS1 | | MS2 | .... | MSm |
+-----+ +-----+ +-----+
^ ^ ^
| | |
V V V
+---------------------------------+
| Distribution Source |
+--------+ |
| FT Agg | |
+--------+------------------------+
^ ^ |
: . |
: +...................+
: | .
: / \ .
+------+ / \ +-----+
| FT1 |<----+ +----->| FT2 |
+------+ / \ +-----+
^ ^ / \ ^ ^
: : / \ : :
: : / \ : :
: : / \ : :
: ./\ /\. :
: /. \ / .\ :
: V . V V . V :
+----+ +----+ +----+ +----+
| R1 | | R2 | ... |Rn-1| | Rn |
+----+ +----+ +----+ +----+
Figure 6: Example SSM-Based RTP Session with Two Feedback TargetsThe use of SSM makes it harder to inject traffic into the multicast group, but not impossible 🕵️. Source authentication requirements apply to SSM sessions too. An individual verification of who sent the RTP and RTCP packets is needed 🪪. An RTP session using SSM will have a group security context that includes the media sources, distribution source, feedback targets, and the receivers. Each has a different role and will be trusted to perform different actions 🎭. For example, the distribution source will need to authenticate the media sources to prevent unwanted traffic from being distributed via the SSM group 🚧. Similarly, the receivers need to authenticate both the distribution source and their feedback target, to prevent injection attacks from malicious devices claiming to be feedback targets 😤. An understanding of the trust relationships and group security context is needed between all components of the system 🧠.
3. Security Options 🛡️
This section gives an overview of security requirements and the current RTP security mechanisms that implement those requirements ✨. It can't be a complete survey, since new security mechanisms get defined all the time 🌈. The goal is to help application designers by reviewing the types of solutions that are available 💖. This section uses a number of security-related terms, as described in the Internet Security Glossary, Version 2 [RFC4949] 📚.
3.1. Secure RTP ✨
Okay bestie, so SRTP (the Secure Real-time Transport Protocol [RFC3711]) is basically the most popular way to get confidentiality, integrity protection, source authentication, and replay protection for RTP 🔐💖 It was designed with RTP header compression and third-party monitors in mind 👀 So the RTP header is not encrypted in RTP data packets, and the first 8 bytes of the first RTCP packet header in each compound RTCP packet are not encrypted either. Everything in RTP packets and compound RTCP packets is integrity protected though 🛡️ That means header compression still works, and third-party monitors can see which RTP flows exist by looking at the synchronization source (SSRC) fields, but the sensitive content stays locked up 🔒 Iconic balance honestly 💅
SRTP works with transforms, where you can mix and match an encryption algorithm, an authentication algorithm, and a pseudorandom function, and the authentication tag length can be set to any value 🧩 It's also easy to extend with more cryptographic transforms ✨ That's super flexible, but it means the application developer needs to know a lot about security 😭 So to make life easier, Session Description Protocol (SDP) security descriptions (see Section 3.1.3) and Datagram Transport Layer Security Extension for SRTP (DTLS-SRTP) (see Section 3.1.1) use predefined bundles of transforms called SRTP crypto suites and SRTP protection profiles 🎀 Easier to use, but less flexible. The Multimedia Internet Keying (MIKEY) protocol (see Section 3.1.2) gives you the flexibility to negotiate the full selection of transforms 🦋 At the time of writing, these transforms, SRTP crypto suites, and SRTP protection profiles are defined or being defined:
- AES-CM and HMAC-SHA-1: AES Counter Mode encryption with 128-bit keys, combined with 160-bit keyed HMAC-SHA-1 with an 80-bit authentication tag. This is the default cryptographic transform that needs to be supported 👑 The transforms are defined in SRTP [RFC3711], with the corresponding SRTP crypto suite defined in [RFC4568] and SRTP protection profile defined in [RFC5764].
- AES-f8 and HMAC-SHA-1: AES f8-mode encryption using 128-bit keys, combined with keyed HMAC-SHA-1 using 80-bit authentication. The transforms are defined in [RFC3711], with the corresponding SRTP crypto suite defined in [RFC4568]. The corresponding SRTP protection profile is not defined 🙈
- SEED: A Korean national standard cryptographic transform that is defined to be used with SRTP in [RFC5669] 🇰🇷 Three options are defined: one using SHA-1 authentication, one using Counter Mode with Cipher Block Chaining Message Authentication Code (CBC-MAC), and one using Galois Counter Mode 🌸
- ARIA: A Korean block cipher [ARIA-SRTP] that supports 128-, 192-, and 256-bit keys ✨ It also defines three options: Counter Mode combined with HMAC-SHA-1 with 80- or 32-bit authentication tags, Counter Mode with CBC-MAC, and Galois Counter Mode. It also defines a different key derivation function than the AES-based systems 🧚
- AES-192-CM and AES-256-CM: Cryptographic transforms for SRTP based on AES-192 and AES-256 Counter Mode encryption, plus 160-bit keyed HMAC-SHA-1 with 80- and 32-bit authentication tags 🍓 These provide 192- and 256-bit encryption keys, but otherwise match the default 128-bit AES-CM transform. The transforms are defined in [RFC3711] and [RFC6188], and the SRTP crypto suites are defined in [RFC6188].
- AES-GCM and AES-CCM: AES Galois Counter Mode and AES Counter Mode with CBC-MAC for AES-128 and AES-256 💜 This authentication is included in the cipher text, which gets expanded by the length of the authentication tag instead of using the SRTP authentication tag. This is defined in [AES-GCM].
- NULL: SRTP [RFC3711] also provides a NULL cipher that can be used when no confidentiality for RTP/RTCP is requested. The corresponding SRTP protection profile is defined in [RFC5764] 🫶
The source authentication guarantees SRTP gives you depend on the cryptographic transform and key management you use 🔍 Some transforms give strong source authentication even in multiparty sessions, while others give weaker guarantees and can only authenticate group membership, not individual sources 😬 Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4383] is a complement to the regular symmetric keyed authentication transforms, like HMAC-SHA-1, and it can provide per-source authentication in some group communication scenarios 🌈 The catch is that packets need to be buffered for a while before their authenticity can be verified ⏳
[RFC4771] defines a variant of the authentication tag that lets a receiver get the Roll over Counter for the RTP sequence number, which is part of the Initialization Vector (IV) for many cryptographic transforms ✨ That makes it quicker and easier to join a long-lived RTP group, like a broadcast session 📡
RTP header extensions are normally sent in the clear and are only integrity protected in SRTP, which can be a problem in some cases 🙃 So [RFC6904] defines an extension that also encrypts selected header extensions 🔐
SRTP is specified and deployed in a bunch of RTP usage contexts 🎉 There's solid support in SIP-established VoIP clients, including IP Multimedia Subsystems (IMS), and in the Real Time Streaming Protocol (RTSP) [RTSP] and RTP-based media streaming, so SRTP in general is widely deployed 🚀 For cryptographic transforms, the default (AES-CM and HMAC-SHA-1) is the most commonly used one, but AES-GCM, AES-192-CM, and AES-256-CM are expected to gain usage in the future, especially because of the AES- and GCM-specific instructions in new CPUs 🧠⚡
SRTP doesn't have an integrated key management solution 🙅♀️ Instead, it relies on an external key management protocol, and there are several that can be used. The following sections outline some popular schemes 💅
3.1.1. Key Management for SRTP: DTLS-SRTP 🔑
Okay so there's a Datagram Transport Layer Security (DTLS) extension for establishing SRTP keys [RFC5763][RFC5764] 🗝️ This extension gives you secure key exchange between two peers, enabling Perfect Forward Secrecy (PFS) and binding strong identity verification to an endpoint 💖 PFS is a property of the key agreement protocol that makes sure a session key derived from a set of long-term keys won't be compromised if one of those long-term keys gets compromised later on 🌸 The default key generation creates a key with material contributed by both peers 🤝 The key exchange happens in the media plane, directly between the peers. The common key exchange procedures take two round trips, assuming no losses ⏱️ Transport Layer Security (TLS) resumption can be used when setting up additional media streams with the same peer, and it cuts the setup time down to one RTT for those streams (see [RFC5764] for a discussion of TLS resumption in this context) ⚡
The actual security properties of an established SRTP session using DTLS depend on the cipher suites offered and used, plus the mechanism for identifying the endpoints of the handshake 🧐 For example, some cipher suites provide PFS and others don't. When using DTLS, the application designer needs to pick which cipher suites DTLS-SRTP can offer and accept so the desired security properties are achieved 🎯 The next choice is how to verify the peer endpoint's identity. One option is to rely on certificates and use a PKI to verify them and make an identity assertion. However, that isn't the most common way 🙈 Instead, self-signed certificates are commonly used to establish trust through signaling or other third-party solutions 🦋
DTLS-SRTP key management can use the signaling protocol in four ways 💅 First, to agree on using DTLS-SRTP for media security. Second, to determine the network location (address and port) where each side is running a DTLS listener, so the parties can perform the key management handshakes that generate the keys used by SRTP 📍 Third, to exchange hashes of each side's certificates, binding them to the signaling and making sure there is no MITM attack. This assumes you can trust the signaling solution to resist modification and not collaborate with an attacker 🕵️♀️ Finally, to provide an asserted identity, e.g., [RFC4474], which can be used to prevent modification of the signaling and the exchange of certificate hashes. That way, it enables binding between the key exchange and the signaling 🫶
This usage is well defined for SIP/SDP in [RFC5763] and, in most cases, can be adopted for use with other bidirectional signaling solutions ✨ Also, be aware that there's work underway to revisit the SIP Identity mechanism [RFC4474] in the IETF STIR working group 👀
The main question about DTLS-SRTP's security properties is how you verify any peer identity, or at least prevent MITM attacks 😤 This does require trusting some external parties: either a PKI, a signaling system, or some identity provider 🔐
DTLS-SRTP usage is clearly on the rise 📈 It is mandatory to support in Web Real-Time Communication (WebRTC), and it has growing support among SIP endpoints 🔥 DTLS-SRTP was developed in the IETF primarily to meet security requirements for RTP-based media established using SIP 💜 The requirements considered can be reviewed in "Requirements and Analysis of Media Security Management Protocols" [RFC5479] 🌈
3.1.2. Key Management for SRTP: MIKEY ✨
okay so MIKEY, which is short for Multimedia Internet Keying [RFC3830], is a keying protocol with several modes, and each mode has its own vibe 🦋 It works for point-to-point stuff using SIP and RTSP (think VoIP calls), but it's also giving broadcast, multicast, and centralized group calls 📞
MIKEY can set up multiple security contexts, or cryptographic sessions, with a single message 💜 It's perfect when one entity makes the key and then needs to hand it out to a bunch of participants. Which mode you pick and what you get out of it depends a lot on the cryptographic method used to establish the session keys that the security protocol actually uses, like SRTP. Main character energy in the choosing process, fr 💅
MIKEY has the following modes of operation:
Pre-Shared Key: This one uses a pre-shared secret for symmetric key crypto, and that secret protects a keying message carrying the session key that was already generated. It's the most efficient option, with small messages and low processing demands 🍓 The catch is scalability. Setting up pre-shared keys is usually only manageable when the number of endpoints is small 🙈
Public Key Encryption: This mode uses public key crypto to protect a keying message carrying the session key that was already generated. It's more resource intensive, but it enables scalable systems ✨ It does require a public key infrastructure to enable verification.
Diffie-Hellman: This mode uses Diffie-Hellman key agreement to generate the session key, which gives you perfect forward secrecy 🔥 The downside is high resource consumption, both in bandwidth and in processing, during the MIKEY exchange. It can't be used to establish group keys, because each pair of peers doing the MIKEY exchange ends up with different keys 💀
HMAC-Authenticated Diffie-Hellman: [RFC4650] defines a variant of the Diffie-Hellman exchange. Instead of a digital signature like in the previous method, it uses a pre-shared key inside a keyed Hashed Message Authentication Code (HMAC) to verify that the keying material is authentic 🌸 This method is still limited to point-to-point usage.
RSA-R: MIKEY-RSA in Reverse mode [RFC4738] is a variant of the public key method, and it's iconic because it doesn't rely on the initiator of the key exchange knowing the responder's certificate 👑 Both the initiator and the responder can specify the session keying material, depending on the use case. Using this mode requires one round-trip time.
TICKET: Ticket Payload (TICKET) [RFC6043] is a MIKEY extension that uses a trusted centralized key management service (KMS) 🎀 The initiator and responder don't share any credentials. Instead, they both trust a third party, the KMS, which they either already have or can establish shared credentials with.
IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) [RFC6267] also uses a KMS infrastructure, but it puts less demand on the KMS 🧚 It claims to provide both perfect forward and backwards secrecy.
SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption (SAKKE) in MIKEY 🦋 It's based on Identity-based Public Key Cryptography and a KMS infrastructure, and it uses that to establish a shared secret value, plus certificateless signatures for source authentication. Its features include simplex transmission, scalability, low-latency call setup, and support for secure deferred delivery.
MIKEY messages can travel over several different transports 🌈 [RFC4567] defines how MIKEY messages can be embedded in general SDP, for use with the signaling protocols SIP, Session Announcement Protocol (SAP), and RTSP. There's also a usage of MIKEY defined by the Third Generation Partnership Project (3GPP), which sends MIKEY messages directly over UDP [T3GPP.33.246] to key the receivers of Multimedia Broadcast and Multicast Service (MBMS) [T3GPP.26.346]. And [RFC3830] defines the application/mikey media type, so MIKEY can be used in, e.g., email and HTTP 💌
Since there are so many choices, it's important to think about the properties your solution actually needs, and then evaluate which modes are candidates for use based on that 🧠 More information on the applicability of the different MIKEY modes can be found in [RFC5197].
MIKEY with pre-shared keys is used by 3GPP MBMS [T3GPP.33.246], and IMS media security [T3GPP.33.328] specifies the use of the TICKET mode transported over SIP and HTTP 📞 RTSP 2.0 [RTSP] specifies use of the RSA-R mode. There are some SIP endpoints that support MIKEY, but the modes they use are unknown to the authors 🤷♀️
3.1.3. Key Management for SRTP: Security Descriptions
okay, security descriptions. [RFC4568] provides a keying solution that sends plaintext keys inside SDP [RFC4566] 😭 It's mainly used with SIP and the SDP Offer/Answer model, and it's well defined for point-to-point sessions where each side declares its own unique key 💖 Using security descriptions to establish group keys is way less well defined, though, and it can have security issues, because it's hard to guarantee unique SSRCs (which you need to avoid a "two-time pad" attack; see Section 9 of [RFC3711]) 🙈
Since the keys travel in plaintext in SDP, they can be intercepted really easily, unless the SDP carrying protocol gives strong end-to-end confidentiality and authentication guarantees. That usually isn't the case. Instead, hop-by-hop security is provided between signaling nodes using TLS, and that leaves the keying material open to capture by every signaling node it passes through 💀 So in most cases, the security properties of security descriptions are weak. Using them usually calls for extra security measures, like trusting the signaling nodes and protecting them with strict access control. Security descriptions need careful design so the security goals can actually be met 🫶
Security descriptions are the most commonly deployed keying solution for SIP-based endpoints. Almost all endpoints that support SRTP also support security descriptions 🔥 They're also used for access protection in IMS Media Security [T3GPP.33.328].
3.1.4. Key Management for SRTP: Encrypted Key Transport
Encrypted Key Transport (EKT) [EKT] is an SRTP extension that makes group keying possible even though you're using a keying mechanism like DTLS-SRTP, which doesn't support group keys 👑 It's designed for centralized conferencing, but it can also be used in sessions where endpoints connect to a conference bridge or a gateway and need to be provisioned with the keys that each participant on the bridge or gateway uses, so they can skip decryption and encryption cycles ✨ This can enable interworking between DTLS-SRTP and other keying systems where either party can set the key, like interworking with security descriptions.
The mechanism is based on setting up an additional EKT key, and everyone uses it to protect their actual session key 🎀 The actual session key gets sent in an expanded authentication tag to the other session participants. The key is only sent occasionally or periodically, depending on the use case and on what requirements exist for timely delivery or notification.
The only known deployment of EKT so far is in some Cisco video conferencing products 📹
3.1.5. Key Management for SRTP: ZRTP and Other Solutions
The ZRTP [RFC6189] key management system for SRTP was proposed as an alternative to DTLS-SRTP 🦋 ZRTP provides best effort encryption, independent of the signaling protocol, and it uses key continuity, Short Authentication Strings, or a PKI for authentication. ZRTP wasn't adopted as an IETF Standards Track protocol. It was published as an Informational RFC in the IETF stream instead 📚 Commercial implementations do exist.
Additional proprietary solutions are also known to exist 🤫
3.2. RTP Legacy Confidentiality
Section 9 of the RTP standard [RFC3550] defines a Data Encryption Standard (DES) or 3DES-based encryption of RTP and RTCP packets 🙃 This mechanism is keyed using plaintext keys in SDP [RFC4566] through the k= SDP field. It can provide confidentiality, but as discussed in Section 9 of [RFC3550], it has extremely weak security properties, and it is not to be used 🚫💀
3.3. IPsec
IPsec [RFC4301] can be used in either tunnel or transport mode to protect RTP and RTCP packets in transit from one network interface to another 🛡️ This can be sufficient when the network interfaces have a direct relation, or in a secured environment where it can be controlled who can read the packets from those interfaces.
The main concern with using IPsec to protect RTP traffic is that, in most cases, using a VPN approach that terminates the security association at some node before the RTP endpoint leaves the traffic open to attack between the VPN termination node and the endpoint 😱 So using IPsec needs careful thought and design so it meets the security goals. An important question is how you make sure the IPsec terminating peer and the ultimate destination are the same. Applications can also run into issues with existing APIs, both when figuring out whether IPsec is being used and when working out who the authenticated peer entity is 🙈
IPsec with RTP is more commonly used as a security solution between infrastructure nodes that exchange lots of RTP sessions and media streams 🏢 Setting up a secure tunnel between those nodes keeps the key management overhead low ✨
3.4. RTP over TLS over TCP
Just as RTP can be sent over TCP [RFC4571], it can also be sent over TLS over TCP [RFC4572], with TLS providing point-to-point security services 🔐 The security properties TLS gives you are confidentiality, integrity protection, and possible source authentication, if the client or server certificates are verified and provide a usable identity. In multiparty scenarios that use a central node for media distribution, the security is only between the central node and the peers. So the security properties for the whole session depend on how much trust you can place in the central node 🧐
RTSP 1.0 [RFC2326] and 2.0 [RTSP] specify the usage of RTP over the same TLS/TCP connection that the RTSP messages are sent over 🎬 It also appears that RTP over TLS/TCP is used in some proprietary solutions that use TLS to bypass firewalls 👀
3.5. RTP over Datagram TLS (DTLS) 🦋
okay so DTLS [RFC6347] is basically TLS [RFC5246] but make it work on a datagram transport, so it doesn't need the reliable byte-stream stuff from the transport underneath. 🌊 That means it can give point-to-point security for RTP flows, like TLS does, but over something like UDP. The two peers set up a DTLS association with each other, and they can even do certificate-based source authentication while they're setting it up. ✨ Every RTP and RTCP packet that flows over it gets protected by that DTLS association. Iconic.
Now, using DTLS for RTP flows is NOT the same thing as DTLS-SRTP key management, so don't mix them up, bestie 🙈 DTLS-SRTP uses the same key management steps as DTLS, but it uses SRTP for the per-packet security stuff. Using DTLS for RTP flows uses normal datagram TLS data protection and wraps complete RTP packets. So with DTLS for RTP, the RTP and RTCP packets are completely encrypted and no headers are left in the clear 🔒 With DTLS-SRTP, the RTP headers stay in the clear and only the payload data gets encrypted. Two very different vibes.
DTLS can also use similar techniques to the ones DTLS-SRTP has to tie a signaling-side agreement to the certificates the endpoints use during the DTLS handshake. 💅 That means you can use it without needing a certificate-based trust chain up to a trusted certificate root. Lowkey a big deal.
There does not appear to be significant usage of DTLS for RTP. 🥲
3.6. Media Content Security/Digital Rights Management 🔐
There are mechanisms that encrypt only the media content inside the RTP payload data and leave the RTP headers and RTCP alone. 🎀 There are a few reasons you'd want this, but the common one is making sure the content stored by RTSP streaming servers is in a protected format the streaming server itself can't read. This is mostly a Digital Rights Management thing. These approaches use a key management solution between the rights provider and the client doing the consuming, so the key gets delivered and the media server never gets access to the security context. 🙅♀️ The catch is that these methods have some security weaknesses. For example, the same key gets handed out to a potentially huge group of receiving clients, which makes a leak way more likely. 😬
This kind of solution can be useful in environments where middleboxes are allowed to rewrite RTP headers and pick which streams get delivered to an endpoint (like some centralized video conference systems 📹). The good part about encrypting and maybe integrity-protecting the payload but not the headers is that the middlebox can't eavesdrop on the media content, but it can still do stream switching. ✨ The downside is that this setup probably needs two levels of security. First there's the payload-level solution, which gives confidentiality and source authentication. Then there's a second layer with extra transport security that ensures source authentication and integrity of the RTP headers that go with the encrypted payloads. 🧩 This can also mean you need two different key management systems, because the entity protecting the packets and the entity protecting the payloads are different, and they have different sets of keys. Chaotic, but that's the tea.
The two-tier security thing shows up in ISMACryp (see Section 3.6.1) and in the deprecated 3GPP Packet-switched Streaming Service solution; see Annex K of [T3GPP.26.234R8]. 🌸
3.6.1. ISMA Encryption and Authentication 🎞️
The Internet Streaming Media Alliance (ISMA) has defined ISMA Encryption and Authentication 2.0 [ISMACryp2]. This spec explains how you encrypt and packetize the encrypted application data units (ADUs) in an RTP payload, using the MPEG-4 generic payload format [RFC3640]. The ADU types that are allowed are the ones that can be stored as elementary streams in an ISO Media File format-based file. 📼 ISMACryp uses SRTP for packet-level integrity and source authentication going from a streaming server to the receiver.
Key management for an ISMACryp-based system can be done through Open Mobile Alliance (OMA) Digital Rights Management 2.0 [OMADRMv2], for example. 🔑
4. Securing RTP Applications 🛡️
In the following, we give guidelines for how to pick the right security mechanisms for RTP applications. 💖
4.1. Application Requirements 📝
This section talks through a bunch of application requirements you need to think about. An application designer choosing security solutions needs a good understanding of what level of security is needed and what behavior they're aiming for. Main character planning energy 👑
4.1.1. Confidentiality 🤫
When it comes to confidentiality of an RTP session, there are several things to consider:
- Probability of compromise: When you use encryption to provide media confidentiality, you need a rough idea of the security goal and how long you can expect the protected content to stay confidential. National or other regulations might add extra requirements for a particular RTP usage. From that, you can figure out which encryption algorithms to use from the set of available transforms. 🧮
- Potential for other leakage: RTP-based security in most of its forms just wraps RTP and RTCP packets into cryptographic containers. This usually means the size of the original RTP payload is visible to anyone observing the protected packet flow, and that can hand those observers information. A well-documented case is the risk with variable bitrate speech codecs that make different sized packets based on the speech input [RFC6562]. 🎙️ Threats like these need to be considered. If they're significant, you'll need restrictions on mode choices in the codec, or extra padding to make all packets equal size and remove the informational leakage. 🫣
Another case is RTP header extensions. If SRTP is used, header extensions are normally NOT protected by the security mechanism that protects the RTP payload. If the header extension carries information that's considered sensitive, then the application needs to be modified so that mechanisms protecting against that leakage are used. 🚨
- Who has access: When you're thinking about the confidentiality properties of a system, it's important to consider where the media is handled in the clear. For example, if the system is based on an RTP mixer that needs the keys to decrypt the media, process it, and repacketize it, then is the mixer providing the security guarantees the other parts of the system expect? 🤔 It's also important to consider who has access to the keys. The policies for handling the keys, and for who can access them, need to be considered alongside the confidentiality goals. 🗝️
As you can see, the actual confidentiality level likely has more to do with the application's use of centralized nodes, and the details of the chosen key management solution, than with the actual choice of encryption algorithm. (Of course, the encryption algorithm still needs to be picked appropriately for the level of security you want.) 💅
4.1.2. Integrity 🧷
Protection against content being modified by a third party, or due to errors in the network, is another factor to consider. The first thing you assess is how resilient you are to modifications of the content. Some media types are extremely sensitive to network bit errors, while others can handle some degree of data corruption. Just as important is considering how sensitive the content is, who is providing the integrity assertion, what the source of the integrity tag is, and what the risks are of modifications happening before the point where protection gets applied. 🔍 These issues affect which cryptographic algorithm gets used, how long the integrity tags are, and whether the entire payload is protected.
RTP applications that rely on central nodes need to consider whether hop-by-hop integrity is acceptable or whether true end-to-end integrity protection is needed. Is it important to be able to tell if a middlebox has modified the data? 🕵️♀️ Some uses of RTP require trusted middleboxes that can modify the data in a way that doesn't break integrity protection as seen by the receiver. Local advertisement insertion in IPTV systems is one example. There are also uses where it's essential that such in-network modification can be detected. RTP can support both, with the right choice of security mechanisms. 🌈
Integrity of the data is commonly tied closely to the question of source authentication. That is, it becomes important to know who makes an integrity assertion for the data. 🫶
4.1.3. Source Authentication 🕵️♀️
okay so source authentication is all about figuring out who actually sent a particular RTP or RTCP packet 📮 it's usually joined at the hip with integrity, bestie, because a receiver wants to know the data is what the source really sent. source auth without integrity? not that useful 🙃 and integrity without source auth is also kinda useless. like, a claim that "this packet is unchanged" means nothing if you can't even prove it came from the source (or some other known, trusted party) 💅
there are a few different ways to assert source authentication, and they're giving levels 🪜
Base level: cryptographic mechanisms that provide authentication, paired with some type of key management, give you an implicit way to authenticate the source ✨ as long as the mechanism is strong enough that nobody can get around it during the time window when you'd accept the packet as valid, you can make a source-authenticated statement. basically: "this message is probably from whoever has the crypto keys for this call" 🔑
what that actually means depends heavily on the app and how it handles the keys 🤔 if only the two peers have the keys, that can be a super solid trust relationship that the traffic is coming from one of them 💖 but in a multiparty situation where security contexts are shared among everyone, most base-level auth solutions can't even tell you whether this packet came from the same source as the last one. not even close 😭
Binding the source and the signaling: one step up from base level is tying the signaling to the key exchange 🧵 the goal here is to at least be able to say the packet source is the same entity the receiver set up the session with. how doable this is depends on the properties of the key management system, whether the signaling can be tied to a specific source, and how much the receiver trusts all the different nodes involved 🌸
for example, when the key exchange happens through the signaling system (like security descriptions [RFC4568]), you get a direct binding between the signaling and the key exchange 🎀 in that setup, the actual security depends on how much you trust the signaling system to correctly link the peer's identifier to the key exchange. so trust the signaling, bestie 🫶
Using identifiers: if the apps can get their hands on a system that provides verifiable identifiers, then source auth can be bound to that identifier 🪪 for example, in a point-to-point call, even symmetric key crypto can give you a strong assertion about who's sending the traffic, as long as the key management can prove the key was only ever exchanged with one particular identifier 🦋 SIP Identity [RFC4474] is one example of how this can be done, and it could be used to bind the DTLS-SRTP certificates an endpoint uses to the identity provider's public key, so you can authenticate the source of a DTLS-SRTP flow 💜
also, all levels of the system need to have matching capability to assert identifiers 🧩 if the signaling can prove that only one specific entity in a multiparty session has a key, then the media layer might be able to guarantee the identifier used by the media sender 🎯 but if the signaling authentication is built on a group key, the media layer can only assert group membership. that's a bummer, babe 😔
4.1.4. Identifiers and Identity 🆔
there are lots of different systems that provide identifiers, each with different properties (SIP Identity [RFC4474] is one example) 🌈 for RTP apps, the most important property is being able to do source authentication and verify those assertions against whatever identifiers are being claimed ✅ what an identifier actually represents can vary, but in communication, one of the most obvious is the identifier for the human user you're talking to 🙋♀️
the thing is, a human user can have extra identifiers for specific roles too 👮♀️ like, Alice can be a police officer, and sometimes her police-officer identifier matters way more than the one that just says she's Alice 🚨 this comes up a lot with organizations, where it's important to prove the person has the right to represent that organization 💼 here are some identifier/identity mechanisms that can be used:
Certificate based: a certificate is used to assert the identifiers used to claim an identity 📜 if you have access to the private part of the certificate, you can sign things to assert your identity ✍️ anyone who wants to verify that assertion needs the public part of the certificate, and with it they can verify the signature against the certificate 🔍 the next step is deciding whether you trust the certificate's trust chain. usually the verifier gets the public part of a root certificate, which lets them verify a trust chain from the root certificate down to the identifier in the certificate 🌳 but the trust only holds if every step in the chain is verifiable and trusted. so provisioning root certificates and being able to revoke compromised certificates are things that will need some infrastructure behind them 🏗️
Online identity providers: an online identity provider (IdP) can check that a user has the right to use an identifier, and then either make assertions on their behalf or hand the requester short-term credentials to assert the identifiers themselves 🎟️ the verifier can then reach out to the IdP to ask it to verify a particular identifier 📞 here, the trust depends a LOT on how much you trust the IdP 🫠 and the whole system becomes dependent on having access to the relevant IdP, so no IdP, no vibes.
in all of the above, a big chunk of the security properties comes down to the method used to authenticate access to the identity 🔐 that part is so important, periodt 💅
4.1.5. Privacy 🤫
RTP apps need to think about what privacy goals they have 👀 since RTP apps often talk directly between peers, the IP address of every communication peer is going to be visible 🌍 the main privacy worry with IP addresses is geographical location and being able to track a user of an endpoint 📍 the main way to avoid that is to add a relay (like a Traversal Using Relay NAT (TURN) server [RFC5766]), or centralized media mixers or forwarders, which hide a peer's address from every other peer 🙈 but obviously, the security and trust you place in those relays needs to be looked at really carefully 🧐
RTP itself can also help people get tracked between communication sessions 😬 if the Canonical Name (CNAME) is generated according to the RTP spec in the form of user@host, those RTCP CNAMEs are likely to stay the same over multiple sessions, which lets people be tracked over time 🕵️♀️ that can be useful for long-term fault tracking and diagnosis, but it clearly has privacy implications 🥺 instead, cryptographically random CNAMEs could be used, as defined in "Guidelines for Choosing RTP Control Protocol (RTCP) CNAMEs" [RFC7022] 🎲
bottom line: if you have privacy goals, you need to consider them and design the system with them in mind 🧠 and certain RTP features might have to be configured to protect privacy, or have requirements on how the implementation is done 🛡️
4.2. Application Structure 🧱
when it comes to RTP security, the best solution is often super dependent on the topology of the communication session 🗺️ the signaling also affects what information can be provided, and whether that info can be instance-specific or shared across a group 👯 in the end, the key management system is going to hugely affect the security properties the app ends up with 🔑 at the same time, the app's communication structure limits which key management methods are even on the table 🙅♀️ since different key management methods have different requirements on the underlying infrastructure, you need to think about that early in the design, bestie, it's not an afterthought 📝
4.3. Automatic Key Management 🤖
the guidelines for Cryptographic Key Management [RFC4107] explain why automatic key management matters, and they strongly recommend using it 💖 most of the security solutions reviewed in this document provide or support automatic key management, at least for establishing session keys ✨ in some longer-term use cases, though, credentials might need to be deployed manually 🧰
for SRTP, a big deal is making sure two-time pads don't happen 🚫 that especially means preventing multiple endpoints from using the same session key and SSRC together 😱 automatic key management methods can depend HEAVILY on signaling features to work correctly 📡 if those dependencies can't be met, you might need extra usage constraints, like per-endpoint session keys, to avoid the problem 🧩
so when you're picking security mechanisms for an RTP app, look hard at the properties of the key management 👀 using key management that is both automatic and integrated means minimal interruption for the user, and it helps make sure security can stay on by default, which is the whole goal 🌟 iconic behavior 🏆
4.4. End-to-End Security vs. Tunnels 🚇
if the security mechanism only gives you a secured tunnel (like some common uses of IPsec, Section 3.3), it's important to think about the full end-to-end properties of the system 🔭 how do you make sure the path from the endpoint to the local tunnel ingress/egress is secure and trustworthy (and the same for the other end of the tunnel)? 🤨 how do you handle source authentication of the peer, when the security protocol only identifies the other end of the tunnel? 🙃 these are just some of the issues that come up when you go with a tunnel-based security protocol instead of an end-to-end one 😵💫
even if you have clear requirements and know you can still get the security properties with a tunnel-based solution, you ought to prefer end-to-end mechanisms, because they're much less likely to break assumptions about deployment 🫶 and those assumptions can be hard to verify automatically, so be careful, babe ⚠️
4.5. Plaintext Keys 🗝️
key management solutions that use plaintext keys, like SDP security descriptions (Section 3.1.3), need extra care to make sure the signaling messages carrying the plaintext keys are transported securely 📨 for plaintext keys, the security of the system depends on how securely those keys are protected end-to-end between the sender and the receiver(s) 🔒 you don't just need to look at the transport protection on the signaling message (keys included), you also need to think about how much you trust any intermediaries in the signaling 🧐 untrusted intermediaries can perform MITM attacks on the communication, or log the keys, which can compromise the encryption long after the actual communication happened 😱 chaos energy, fr fr 💀
4.6. Interoperability ✨
Okay so bestie, few RTP apps are loners 🥺 They literally talk to a huge pile of other systems, so it's giving teamwork. To keep the number of security mechanisms you have to build down, it's smart to ask if you can use the same ones as other apps 🧠 This can also help everyone figure out what security level actually got negotiated in a session, which is so important 💅
Lowkey, though, wanting to be interoperable can clash with your app's security goals 😭 To hit those goals you might have to give up some interop, and that's a real trade-off. Another option is to implement multiple security mechanisms, but ngl that's messy 🙈 Now the user has to understand what using each specific system actually means, and the app can become vulnerable to bid-down attacks 💀
5. Examples 🎀
Okay, now for the fun part 🦋 Here we walk through some example security solutions for apps that use RTP services or frameworks. They're here to show you the choices you've got, not to be the official rules for security 🫶
5.1. Media Security for SIP-Established Sessions Using DTLS-SRTP 📞
So in 2009 the IETF looked at media security for RTP sessions set up through point-to-point SIP sessions 👀 They worked out a bunch of requirements, then analysed the existing media security solutions, especially the keying methods, against them. All of that got published in [RFC5479] ✨ From that analysis and working group discussion, DTLS-SRTP was picked as the best solution 👑
The security solution for SIP using DTLS-SRTP is defined in "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)" [RFC5763] 💖 High level: the framework uses SIP with SDP offer/answer procedures to swap the network addresses where the server endpoint will have a DTLS-SRTP-enabled server running. SIP signaling is also used to exchange the fingerprints of the certificate each endpoint will use in the DTLS establishment process. Once the signaling is sufficiently done, the DTLS-SRTP client does DTLS handshakes and establishes SRTP session keys 🔥 The clients also verify the certificate fingerprints, so nobody sneaky (a man in the middle) has inserted themselves into the exchange 🙈
DTLS has a bunch of good security properties 🛡️ For example, to pull off a MITM, someone in the signaling path has to do an active action and modify both the signaling message and the DTLS handshake, which is a lot of work for an attacker 😤 Solutions also exist that let the fingerprints be bound to identities. SIP Identity gives an identity established by the first proxy for each user [RFC4474] 🧚 This shrinks the number of nodes the connecting User Agent has to trust down to just the first-hop proxy, instead of the entire signaling path 🎀 The biggest security weakness here is the dependency on the signaling 😬 SIP signaling passes through multiple nodes, and usually there's no message security deployed, just hop-by-hop transport security between the nodes, if any at all 💀
5.2. Media Security for WebRTC Sessions 🌸
Web Real-Time Communication (WebRTC) [WebRTC] is a solution that gives JavaScript web apps real-time media directly between browsers 🌈 Media is carried over RTP and protected with a mandatory application of SRTP [RFC3711], with keying done using DTLS-SRTP [RFC5764] 🔐 The security configuration is further defined in "WebRTC Security Architecture" [WebRTC-SEC] ✨
A hash of the peer's certificate gets handed to the JavaScript web app, so that app can verify the identity of the peer 🕵️♀️ There are a few ways to check those certificate hashes. The WebRTC security architecture [WebRTC-SEC] points to using an identity provider. In this setup, the identity provider (a third party to the web app) signs the DTLS-SRTP hash together with a statement on the validity of the user identity that was used to sign the hash 💅 The receiver of that identity assertion can independently verify the user identity, to make sure it's the one they meant to talk to, and that the cryptographic assertion holds up. This way a user can be certain the app also can't perform a MITM and grab the keys to the media call 🫶 Other ways to verify the certificate hashes exist too. For example, you could check them against a hash sent over an out-of-band channel (e.g., compare with a hash printed on a business card), or use a verbal short authentication string (e.g., as in ZRTP [RFC6189]), or use hash continuity 🦋
Privacy got attention during WebRTC's development too 🙈 The main RTP-related concerns that were raised are:
- Location disclosure: Interactive Connectivity Establishment (ICE) negotiation [RFC5245] provides IP addresses and ports for the browser, so this leaks location information in the signaling to the peer 😱 To stop that, you can block the use of any ICE candidate that isn't a relay candidate, i.e., one where the IP and port provided belong to the service provider's media traffic relay 🛑
- Prevent tracking between sessions: Static RTP CNAMEs and DTLS-SRTP certificates provide information that gets reused between session instances, so people can be tracked 👀 To prevent that, such information ought not be reused between sessions, or it ought not be sent in the clear 🧁 Heads up though: generating new certificates each time stops continuity in authentication. But WebRTC users are expected to use multiple devices to access the same communication service, so that continuity can't be expected anyway 🤷♀️ Instead, the identity mechanism described above has to be relied on 💜
Note: The above cases are focused on providing privacy from other parties, not on providing privacy from the web server that provides the WebRTC JavaScript application. 🙅♀️
5.3. IP Multimedia Subsystem (IMS) Media Security 📡
In IMS, the core network is controlled by a single operator, or by several operators who really trust each other 🤝 Except for some types of access, the operator is in full control, and no packages are routed over the Internet 🏠 The core network offers services like voice mail, interworking with legacy systems (Public Switched Telephone Network (PSTN), Global System for Mobile Communications (GSM), and 3G), and transcoding 🎙️ Endpoints get authenticated during SIP registration, either with IMS and Authentication and Key Agreement (AKA) (using Subscriber Identity Module (SIM) credentials) or with SIP Digest (using a password) 🔑
So for IMS media security [T3GPP.33.328], end-to-end encryption is not seen as needed or desired 🙅♀️ It would get in the way of things like interworking and transcoding, and it would make calls between incompatible terminals impossible 😭 Because of that, IMS media security mostly uses end-to-access-edge security, where SRTP gets terminated in the first node in the core network 🧚 Since the SIP signaling is trusted and encrypted (with TLS or IPsec), security descriptions [RFC4568] are considered to give good protection against eavesdropping over the accesses that aren't already encrypted (GSM, 3G, and Long Term Evolution (LTE)) 💅 Media source authentication is based on knowing the SRTP session key, plus trusting that the IMS network will only forward media from the correct endpoint 🫶
For enterprises and government agencies, who might have weaker trust in the IMS core network and can be assumed to have compatible terminals, end-to-end security can be achieved by deploying their own key management server 🏢✨
Work on interworking with WebRTC is ongoing right now 🌈 The security will still be end-to-access-edge, but it'll use DTLS-SRTP [RFC5763] instead of security descriptions 🦋
5.4. 3GPP Packet-Switched Streaming Service (PSS) 🎬
The 3GPP Release 11 PSS specification of the Packet-switched Streaming Service (PSS) [T3GPP.26.234R11] defines, in Annex R, a set of security mechanisms 🍿 These are all about stopping content from being copied, i.e., Digital Rights Management (DRM) 🔒 To meet those goals with the specified solution, the client implementation and the application platform are trusted to protect against access and modification by an attacker 👑
PSS media is controlled by RTSP 1.0 [RFC2326] streaming over RTP 📺 So an RTSP client whose user wants protected content will request a session description (SDP [RFC4566]) for that content. That SDP indicates the media is protected by ISMACryp 2.0 [ISMACryp2] encoding application units (AUs) 💖 The key(s) used to protect the media come in one of two ways. If a single key is used, the client uses some DRM system to retrieve the key, as indicated in the SDP. Commonly, OMA DRM v2 [OMADRMv2] is used to get the key 🔑 If multiple keys are going to be used, then an additional RTSP stream for key updates is set up in parallel with the media streams, and the key updates get sent to the client using Short Term Key Messages defined in the "Service and Content Protection for Mobile Broadcast Services" part [OMASCP] of the OMA Mobile Broadcast Services [OMABCAST] 🧠
Worth noting: this solution doesn't provide any integrity verification method for the RTP header and payload header information. Only the encoded media AU is protected 😬 3GPP hasn't defined any requirement for supporting a solution that could provide that, so replay or insertion attacks are possible 💀 Another property is that the media content can be protected by whoever provides the media, so the operators of the RTSP server have no access to unprotected content 🙌 Instead, everyone who wants to access the media is supposed to contact the DRM keying server, and if their device is acceptable, they'll be given the key to decrypt the media 🗝️
To protect the signaling, RTSP 1.0 supports the usage of TLS 🔐 This isn't explicitly discussed in the PSS specification, though 🤔 Using TLS can prevent both modification of the session description information, and it can help keep some privacy about what content the user is watching, since all URLs would then be confidentiality protected 🥹✨
5.5. RTSP 2.0 🎀
okay so RTSP 2.0 [RTSP] is giving a super interesting comparison to the PSS service in Section 5.4, which runs on RTSP 1.0 and the service requirements that mobile operators had in mind. the big difference is that 2.0 is fully designed around having a mandatory-to-implement security mechanism. 🔒 and since it covers one transport media over RTP, it also defines security mechanisms for the RTP-transported media streams. so thorough, I'm obsessed 😭
the security goal for RTP in RTSP 2.0 is to make sure there's confidentiality, integrity, and source authentication between the RTSP server and the client. 🫶 why? so nobody can eavesdrop on what the user is watching, which is a privacy thing, and so nobody can pull off replay or injection attacks on the media stream. 💅 to hit those goals, the signaling has to be protected too, which means TLS is required between the client and server. no skipping it, bestie 🙈
with TLS-protected signaling, the client and server agree on the media transport method during the SETUP request and response. ✨ the secured media transport is SRTP (SAVP/RTP), normally over UDP. the key management for SRTP is MIKEY using RSA-R mode. 🦋 RSA-R is picked because it lets the RTSP server choose the key even though the RTSP client is the one that starts the MIKEY exchange. it also lets the server reuse its TLS certificate when it creates the MIKEY messages, which ties the RTSP server to the key exchange. 👑 if the SETUP process works out, an SRTP crypto context gets established between the RTSP server and the client for the RTP-transported media streams. iconic 🌈
6. Security Considerations 💀
this entire document is about security, so please, bestie, read it. 🙏✨
7. Acknowledgements 🫶
we thank the IESG for their careful review of [RFC7202], which led to the writing of this memo. 💖 John Mattsson contributed the IMS Media Security example (Section 5.3), so he's a legend 👑
the authors wanted to thank Christian Correll, Dan Wing, Kevin Gross, Alan Johnston, Michael Peck, Ole Jacobsen, Spencer Dawkins, Stephen Farrell, John Mattsson, and Suresh Krishnan for their reviews and suggestions for improving the text. 🌸 thank you all, you're the real MVPs 🧚
8. Informative References ✨
okay bestie, this is the reading list 📚 these are the docs the spec leans on for context, so here they are, every single one, exactly as written 💖
[AES-GCM] McGrew, D. and K. Igoe, "AES-GCM and AES-CCM
Authenticated Encryption in Secure RTP (SRTP)", Work in
Progress, September 2013.
[ARIA-SRTP] Kim, W., Lee, J., Kim, D., Park, J., and D. Kwon, "The
ARIA Algorithm and Its Use with the Secure Real-time
Transport Protocol(SRTP)", Work in Progress, November
2013.
[EKT] McGrew, D. and D. Wing, "Encrypted Key Transport for
Secure RTP", Work in Progress, February 2014.
[ISMACryp2] Internet Streaming Media Alliance (ISMA), "ISMA
Encryption and Authentication Version 2.0", November
2007, <http://www.oipf.tv/images/site/DOCS/mpegif/ISMA/
isma_easpec2.0.pdf>.
[OMABCAST] Open Mobile Alliance, "Mobile Broadcast Services Version
1.0", February 2009,
<http://technical.openmobilealliance.org/Technical/
release_program/bcast_v1_0.aspx>.
[OMADRMv2] Open Mobile Alliance, "OMA Digital Rights Management
V2.0", July 2008,
<http://technical.openmobilealliance.org/
Technical/release_program/drm_v2_0.aspx>.
[OMASCP] Open Mobile Alliance, "Service and Content Protection for
Mobile Broadcast Services", January 2013,
<http://technical.openmobilealliance.org/Technical/
release_program/docs/BCAST/V1_0_1-20130109-A/
OMA-TS-BCAST_SvcCntProtection-V1_0_1-20130109-A.pdf>.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD
5, RFC 1112, August 1989.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC3365] Schiller, J., "Strong Security Requirements for Internet
Engineering Task Force Standard Protocols", BCP 61, RFC
3365, August 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer,
D., and P. Gentric, "RTP Payload Format for Transport of
MPEG-4 Elementary Streams", RFC 3640, November 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for
Cryptographic Key Management", BCP 107, RFC 4107, June
2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383, February
2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for
Media Streams", RFC 4568, July 2006.
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport", RFC 4571, July 2006.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for
Multimedia Internet KEYing (MIKEY)", RFC 4650, September
2006.
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-
RSA-R: An Additional Mode of Key Distribution in
Multimedia Internet KEYing (MIKEY)", RFC 4738, November
2006.
[RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity
Transform Carrying Roll-Over Counter for the Secure Real-
time Transport Protocol (SRTP)", RFC 4771, January 2007.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008.
[RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of
Various Multimedia Internet KEYing (MIKEY) Modes and
Extensions", RFC 5197, June 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet,
"Requirements and Analysis of Media Security Management
Protocols", RFC 5479, April 2009.
[RFC5669] Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The
SEED Cipher Algorithm and Its Use with the Secure Real-
Time Transport Protocol (SRTP)", RFC 5669, August 2010.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the
Secure Real-time Transport Protocol (SRTP)", RFC 5764,
May 2010.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal
Using Relays around NAT (TURN): Relay Extensions to
Session Traversal Utilities for NAT (STUN)", RFC 5766,
April 2010.
[RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based
Modes of Key Distribution in Multimedia Internet KEYing
(MIKEY)", RFC 6043, March 2011.
[RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure
RTP", RFC 6188, March 2011.
[RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
Path Key Agreement for Unicast Secure RTP", RFC 6189,
April 2011.
[RFC6267] Cakulev, V. and G. Sundaram, "MIKEY-IBAKE: Identity-Based
Authenticated Key Exchange (IBAKE) Mode of Key
Distribution in Multimedia Internet KEYing (MIKEY)", RFC
6267, June 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC6509] Groves, M., "MIKEY-SAKKE: Sakai-Kasahara Key Encryption
in Multimedia Internet KEYing (MIKEY)", RFC 6509,
February 2012.
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of
Variable Bit Rate Audio with Secure RTP", RFC 6562, March
2012.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the
Secure Real-time Transport Protocol (SRTP)", RFC 6904,
April 2013.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, September 2013.
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Protocol
Framework: Why RTP Does Not Mandate a Single Media
Security Solution", RFC 7202, April 2014.
[RTSP] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, "Real Time Streaming Protocol 2.0
(RTSP)", Work in Progress, February 2014.
[T3GPP.26.234R11]
3GPP, "Technical Specification Group Services and System
Aspects; Transparent end-to-end Packet-switched Streaming
Service (PSS); Protocols and codecs", 3GPP TS 26.234
11.1.0, September 2012,
<http://www.3gpp.org/DynaReport/26234.htm>.
[T3GPP.26.234R8]
3GPP, "Technical Specification Group Services and System
Aspects; Transparent end-to-end Packet-switched Streaming
Service (PSS); Protocols and codecs", 3GPP TS 26.234
8.4.0, September 2009,
<http://www.3gpp.org/DynaReport/26234.htm>.
[T3GPP.26.346]
3GPP, "Multimedia Broadcast/Multicast Service (MBMS);
Protocols and codecs", 3GPP TS 26.346 10.7.0, March 2013,
<http://www.3gpp.org/DynaReport/26346.htm>.
[T3GPP.33.246]
3GPP, "3G Security; Security of Multimedia Broadcast/
Multicast Service (MBMS)", 3GPP TS 33.246 11.1.0,
December 2012,
<http://www.3gpp.org/DynaReport/33246.htm>.
[T3GPP.33.328]
3GPP, "IP Multimedia Subsystem (IMS) media plane
security", 3GPP TS 33.328 12.1.0, December 2012,
<http://www.3gpp.org/DynaReport/33328.htm>.
[WebRTC-SEC]
Rescorla, E., "WebRTC Security Architecture", Work in
Progress, February 2014.
[WebRTC] Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", Work in Progress, February
2014.Authors' Addresses 🎀
and these are the lovely humans who wrote it 🫶 here's how to reach them, exactly as listed:
Magnus Westerlund
Ericsson
Farogatan 6
SE-164 80 Kista
Sweden
Phone: +46 10 714 82 87
EMail: magnus.westerlund@ericsson.com
Colin Perkins
University of Glasgow
School of Computing Science
Glasgow G12 8QQ
United Kingdom
EMail: csp@csperkins.org
URI: http://csperkins.org/📦 where this page comes from
- ietf: rfc7201 2014-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms