RFC 5764
Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)
Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP) 🎀
Okay bestie, this is RFC 5764 🦋 It's an IETF Standards Track doc, written by D. McGrew (Cisco Systems) and E. Rescorla (RTFM, Inc.), and it's dated May 2010. The ISSN is 2070-1721. It's giving official spec energy, and it's literally the rulebook for how DTLS hands SRTP its keys 💅
Abstract
Here's the tea 🍓 This doc describes a DTLS extension that sets up keys for SRTP and SRTCP flows ✨ DTLS keying happens right on the media path, no matter what out-of-band signalling channel is hanging around 💜
Status of This Memo
This is an Internet Standards Track document 🔥 It's a product of the IETF, it represents the consensus of the IETF community, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741 🌸
Info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc5764 🫶
Copyright Notice
Copyright (c) 2010 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 in effect on the publication date. Please read them carefully, because they spell out your rights and restrictions 📜 Any Code Components pulled from this doc must include 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 🧚
Heads up 👀 This doc may include material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. Some of the people who own the copyright in that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this doc may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used In This Document . . . . . . . . . . . . . . 3
3. Overview of DTLS-SRTP Operation . . . . . . . . . . . . . . . 4
4. DTLS Extensions for SRTP Key Establishment . . . . . . . . . . 5
4.1. The use_srtp Extension . . . . . . . . . . . . . . . . . . 5
4.1.1. use_srtp Extension Definition . . . . . . . . . . . . 7
4.1.2. SRTP Protection Profiles . . . . . . . . . . . . . . . 8
4.1.3. srtp_mki value . . . . . . . . . . . . . . . . . . . . 9
4.2. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Key Scope . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Key Usage Limitations . . . . . . . . . . . . . . . . . . 12
5. Use of RTP and RTCP over a DTLS-SRTP Channel . . . . . . . . . 13
5.1. Data Protection . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. Transmission . . . . . . . . . . . . . . . . . . . . . 13
5.1.2. Reception . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Rehandshake and Rekey . . . . . . . . . . . . . . . . . . 16
6. Multi-Party RTP Sessions . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.1. Security of Negotiation . . . . . . . . . . . . . . . . . 17
7.2. Framing Confusion . . . . . . . . . . . . . . . . . . . . 17
7.3. Sequence Number Interactions . . . . . . . . . . . . . . . 18
7.3.1. Alerts . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3.2. Renegotiation . . . . . . . . . . . . . . . . . . . . 18
7.4. Decryption Cost . . . . . . . . . . . . . . . . . . . . . 19
8. Session Description for RTP/SAVP over DTLS . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Overview of DTLS . . . . . . . . . . . . . . . . . . 23
Appendix B. Performance of Multiple DTLS Handshakes . . . . . . . 241. Introduction ✨
So the Secure RTP (SRTP) profile [RFC3711] can give you confidentiality, message authentication, and replay protection for RTP data and RTP Control (RTCP) traffic 🎀 The catch is that SRTP doesn't do key management at all. It depends on some external key management to swap the secret master keys and to agree on the algorithms and parameters you use with them 🙈
Datagram Transport Layer Security (DTLS) [RFC4347] is a channel security protocol that comes with integrated key management, parameter negotiation, and secure data transfer 🦋 Its data transfer protocol is generic, though, so it isn't as highly optimized for RTP as SRTP is. SRTP was specifically tuned for that job 💅
This doc describes DTLS-SRTP, which is an SRTP extension for DTLS. It mixes the performance and encryption flexibility of SRTP with the flexibility and convenience of DTLS-integrated key and association management 💜 You can look at DTLS-SRTP in two equivalent ways: as a new key management method for SRTP, or as a new RTP-specific data format for DTLS 🧚
The key points of DTLS-SRTP are:
- application data is protected using SRTP,
- the DTLS handshake is used to establish keying material, algorithms, and parameters for SRTP,
- a DTLS extension is used to negotiate SRTP algorithms, and
- other DTLS record-layer content types are protected using the ordinary DTLS record format.
The rest of this memo is laid out like this 🗺️ Section 2 covers the conventions used to show normative requirements. Section 3 gives an overview of how DTLS-SRTP works. Section 4 specifies the DTLS extensions, and Section 5 talks about how RTP and RTCP get carried over a DTLS-SRTP channel. Section 6 covers use with multi-party sessions. Section 7 and Section 9 are the Security and IANA considerations 🔥
2. Conventions Used In This Document 💅
So the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119] 🫶
3. Overview of DTLS-SRTP Operation ✨
okay so DTLS-SRTP is built for point-to-point media sessions, which means exactly two participants 💖 Each DTLS-SRTP session has a single DTLS association (TLS people call it a "connection" 🎀), and you end up with either two SRTP contexts (if media is flowing both ways on the same host/port quartet) or one SRTP context (if it's only going one direction). All SRTP traffic going over that pair in a given direction uses a single SRTP context. A single DTLS-SRTP session only protects data carried over a single UDP source and destination port pair 🦋
Here's the general pattern. For each RTP or RTCP flow, the peers do a DTLS handshake on the same source and destination port pair to set up a DTLS association 🧚 Which side is the DTLS client and which side is the DTLS server has to be sorted out through some out-of-band mechanism, like SDP. The keying material from that handshake gets fed into the SRTP stack. Once the association is up, RTP packets get protected (and become SRTP) using that keying material ✨
RTP and RTCP traffic is usually sent on two separate UDP ports. When symmetric RTP [RFC4961] is used, you need two bidirectional DTLS-SRTP sessions, one for the RTP port and one for the RTCP port. When RTP flows aren't symmetric, you need four unidirectional DTLS-SRTP sessions (for inbound and outbound RTP, and inbound and outbound RTCP) 💅
Symmetric RTP [RFC4961] is the case where there are two RTP sessions with their source and destination ports and addresses reversed, kind of like how a TCP connection uses its ports 🌸 Each participant has an inbound RTP session and an outbound RTP session. When symmetric RTP is in use, a single DTLS-SRTP session can protect both of those RTP sessions. It is RECOMMENDED that symmetric RTP be used with DTLS-SRTP 🫶
RTP and RTCP traffic MAY be multiplexed on a single UDP port [RFC5761]. In that case, both RTP and RTCP packets can go over the same DTLS-SRTP session, which halves the number of DTLS-SRTP sessions needed. This improves the cryptographic performance of DTLS, but it may cause problems when RTCP and RTP get different network treatment (for example, for bandwidth reservation or scheduling reasons) 🍓
Between a single pair of participants, there may be multiple media sessions. There MUST be a separate DTLS-SRTP session for each distinct pair of source and destination ports used by a media session (though the sessions can share a single DTLS session and hence amortize the initial public key handshake, which is honestly so smart 🧠✨)
A DTLS-SRTP session may be indicated by an external signaling protocol like SIP. When the signaling exchange is integrity-protected (for example, when SIP Identity protection via digital signatures is used), DTLS-SRTP can use that integrity guarantee to provide complete security of the media stream 🔐 How to indicate DTLS-SRTP sessions in SIP and SDP [RFC4566], and how to authenticate the endpoints using fingerprints, is covered in [RFC5763] 📖
Now, in a naive implementation, when there are multiple media sessions, every media channel gets a brand new DTLS session establishment (complete with public key cryptography) 😭 For example, a videophone might be sending both an audio stream and a video stream, and each one would run its own separate DTLS session establishment exchange, all happening in parallel. As an optimization, the DTLS-SRTP implementation SHOULD use the following strategy: a single DTLS association is established first, and all the other DTLS associations wait until that connection is up before continuing with their handshakes. This lets the later sessions use DTLS session resumption, which amortizes the expensive public key cryptography operations over multiple DTLS handshakes 💜
The SRTP keys used to protect packets originated by the client are distinct from the SRTP keys used to protect packets originated by the server. All of the RTP sources originating on the client for the same channel use the same SRTP keys, and likewise, all of the RTP sources originating on the server for the same channel use the same SRTP keys 🦋 The SRTP implementation MUST ensure that all of the synchronization source (SSRC) values for all of the RTP sources originating from the same device over the same channel are distinct, so we avoid the "two-time pad" problem (as described in Section 9.1 of RFC 3711) 🚫 Note that this isn't an issue for separate media streams (on different host/port quartets) that use independent keying material, even if an SSRC collision happens 🙈
4. DTLS Extensions for SRTP Key Establishment 🎀
4.1. The use_srtp Extension 💖
In order to negotiate SRTP data protection, clients include an extension of type "use_srtp" in the DTLS extended client hello. This extension MUST only be used when the data being transported is RTP or RTCP [RFC3550]. The "extension_data" field of this extension contains the list of acceptable SRTP protection profiles, as indicated below ✨
Servers that receive an extended hello containing a "use_srtp" extension can agree to use SRTP by including an extension of type "use_srtp", with the chosen protection profile in the extended server hello. The process looks like this 👑
Client Server
ClientHello + use_srtp -------->
ServerHello + use_srtp
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
SRTP packets <-------> SRTP packetsNote that '*' indicates messages that are not always sent in DTLS. The CertificateRequest, client and server Certificates, and CertificateVerify will be sent in DTLS-SRTP 🧾
Once the "use_srtp" extension is negotiated, the RTP or RTCP application data is protected solely using SRTP. Application data is never sent in DTLS record-layer "application_data" packets 🙅♀️ Instead, complete RTP or RTCP packets are passed to the DTLS stack, which passes them to the SRTP stack, which protects them appropriately. If RTP/RTCP multiplexing [RFC5761] is in use, this means RTP and RTCP packets may both be passed to the DTLS stack. Because the DTLS layer doesn't process the packets, it doesn't need to tell them apart. The SRTP stack can use the procedures of [RFC5761] to distinguish RTP from RTCP 🔍
When the "use_srtp" extension is in effect, implementations must not place more than one application data "record" per datagram. (This only matters from the DTLS point of view, because SRTP is inherently oriented towards one payload per packet, but it's stated purely for clarification 💅)
Data other than RTP/RTCP (that is, TLS control messages) MUST use ordinary DTLS framing and MUST be placed in separate datagrams from SRTP data 📦
A DTLS-SRTP handshake establishes one or more SRTP crypto contexts. However, they all have the same SRTP Protection Profile and Master Key Identifier (MKI), if any. MKIs are used solely to tell apart the keying material and protection profiles between distinct handshakes, for instance, due to rekeying 🗝️ When an MKI is established in a DTLS-SRTP session, it MUST apply to all of the SSRCs within that session, though a single endpoint may negotiate multiple DTLS-SRTP sessions due to, for instance, forking. (Note that RFC 3711 lets packets within the same session but with different SSRCs use MKIs differently. In contrast, DTLS-SRTP requires that MKIs and the keys they're associated with have the same meaning and are uniform across the entire SRTP session 🌈)
4.1.1. use_srtp Extension Definition ⭐
4.1.1.1. Hmm, see below
The client MUST fill the extension_data field of the "use_srtp" extension with a UseSRTPData value (see Section 9 for the registration):
uint8 SRTPProtectionProfile[2];
struct {
SRTPProtectionProfiles SRTPProtectionProfiles;
opaque srtp_mki<0..255>;
} UseSRTPData;
SRTPProtectionProfile SRTPProtectionProfiles<2..2^16-1>;The SRTPProtectionProfiles list indicates the SRTP protection profiles that the client is willing to support, listed in descending order of preference. The srtp_mki value contains the SRTP Master Key Identifier (MKI) value (if any) that the client will use for its SRTP packets. If this field is of zero length, then no MKI will be used 🎯
Note: for those unfamiliar with TLS syntax, "srtp_mki<0..255>" indicates a variable-length value with a length between 0 and 255 (inclusive). So the MKI may be up to 255 bytes long 📏
If the server is willing to accept the use_srtp extension, it MUST respond with its own "use_srtp" extension in the ExtendedServerHello. The extension_data field MUST contain a UseSRTPData value with a single SRTPProtectionProfile value that the server has chosen for use with this connection. The server MUST NOT select a value that the client has not offered. If there is no shared profile, the server SHOULD NOT return the use_srtp extension, at which point the connection falls back to the negotiated DTLS cipher suite. If that isn't acceptable, the server SHOULD return an appropriate DTLS alert 🚨
4.1.2. SRTP Protection Profiles ✨
okay so an SRTP protection profile is basically the whole vibe for how SRTP processing goes down. it's the bundle of parameters and options that are in effect for it 💅 this doc defines these four:
SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_80 = {0x00, 0x01};
SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_32 = {0x00, 0x02};
SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_80 = {0x00, 0x05};
SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_32 = {0x00, 0x06};next up, the list of SRTP transform parameters for each profile 🎀 quick heads up: cipher_key_length, cipher_salt_length, auth_key_length, and auth_tag_length are all counted in bits. maximum_lifetime is the max number of packets you can protect with each single set of keys when that profile is in use. all of these apply to both RTP and RTCP, unless the RTCP params get their own separate listing 🫶
SRTP_AES128_CM_HMAC_SHA1_80
cipher: AES_128_CM
cipher_key_length: 128
cipher_salt_length: 112
maximum_lifetime: 2^31
auth_function: HMAC-SHA1
auth_key_length: 160
auth_tag_length: 80
SRTP_AES128_CM_HMAC_SHA1_32
cipher: AES_128_CM
cipher_key_length: 128
cipher_salt_length: 112
maximum_lifetime: 2^31
auth_function: HMAC-SHA1
auth_key_length: 160
auth_tag_length: 32
RTCP auth_tag_length: 80
SRTP_NULL_HMAC_SHA1_80
cipher: NULL
cipher_key_length: 0
cipher_salt_length: 0
maximum_lifetime: 2^31
auth_function: HMAC-SHA1
auth_key_length: 160
auth_tag_length: 80
SRTP_NULL_HMAC_SHA1_32
cipher: NULL
cipher_key_length: 0
cipher_salt_length: 0
maximum_lifetime: 2^31
auth_function: HMAC-SHA1
auth_key_length: 160
auth_tag_length: 32
RTCP auth_tag_length: 80all the crypto algorithms in these profiles come from [RFC3711], so that's the source of truth 📖
with all of these SRTP parameter profiles, these SRTP options are also in effect 🌸
- the TLS PseudoRandom Function (PRF) is used to generate keys to feed into the SRTP Key Derivation Function (KDF). when DTLS 1.2 [DTLS1.2] is in use, the PRF is the one associated with the cipher suite. note that this spec is compatible with DTLS 1.0 or DTLS 1.2 💜
- the Key Derivation Rate (KDR) is equal to zero. so keys are not re-derived based on the SRTP sequence number 🙈
- the key derivation procedures from Section 4.3 with the AES-CM PRF from RFC 3711 are used.
- for all other parameters (in particular, SRTP replay window size and FEC order), the default values are used.
if you need values other than the defaults for these parameters, they can be turned on by writing a separate spec that defines the SDP syntax to signal them 🦋
applications using DTLS-SRTP SHOULD coordinate the SRTP Protection Profiles between the DTLS-SRTP session that protects an RTP flow and the DTLS-SRTP session that protects the associated RTCP flow. this only matters in cases where RTP and RTCP are not multiplexed over a common port. in particular, identical ciphers SHOULD be used 🔥
new SRTPProtectionProfile values must be defined according to the "Specification Required" policy as defined by RFC 5226 [RFC5226]. see Section 9 for IANA Considerations 👑
4.1.3. srtp_mki value 🧚
the srtp_mki value MAY be used to show the capability and desire to use the SRTP Master Key Identifier (MKI) field in the SRTP and SRTCP packets. the MKI field tells an SRTP receiver which key was used to protect the packet that has that field. the srtp_mki field holds the value of the SRTP MKI that's associated with the SRTP master keys derived from this handshake. ngl the rule here is that each SRTP session MUST have exactly one master key protecting packets at any given time. the client MUST choose the MKI value so that it's distinct from the last MKI value that was used, and it SHOULD make these values unique for the whole duration of the TLS session 💖
when the server gets a use_srtp extension containing an srtp_mki field, it MUST either (assuming it accepts the extension at all):
- include a matching
srtp_mkivalue in itsuse_srtpextension to show that it will make use of the MKI, or - return an empty
srtp_mkivalue to show that it cannot make use of the MKI.
if the client spots a nonzero-length MKI in the server's response that's different from the one the client offered, the client MUST abort the handshake and SHOULD send an invalid_parameter alert 😭 and if the client and server do agree on an MKI, then all SRTP packets protected under the new security parameters MUST contain that MKI.
lowkey important: any given DTLS-SRTP session only has a single active MKI (if any). so at any given time, the endpoints will generally only be using one MKI. the major exception is during rehandshakes 🌈
4.2. Key Derivation 🔑
when SRTP mode is in effect, different keys are used for ordinary DTLS record protection and for SRTP packet protection. these keys get generated using a TLS exporter [RFC5705] to produce
2 * (SRTPSecurityParams.master_key_len +
SRTPSecurityParams.master_salt_len) bytes of dataand they get assigned as shown below. the per-association context value is empty 🍓
client_write_SRTP_master_key[SRTPSecurityParams.master_key_len];
server_write_SRTP_master_key[SRTPSecurityParams.master_key_len];
client_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len];
server_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len];the exporter label for this usage is "EXTRACTOR-dtls_srtp". (the "EXTRACTOR" prefix is there for historical compatibility 🙃)
the four keying material values (the master key and master salt for each direction) are fed in as inputs to the SRTP key derivation mechanism, like in Figure 1 below and the details after it. by default the mechanism in Section 4.3 of [RFC3711] is used, unless another key derivation mechanism is specified as part of an SRTP Protection Profile 🧠
the client_write_SRTP_master_key and client_write_SRTP_master_salt go into one invocation of the SRTP key derivation function, which makes the SRTP keys the client uses to encrypt and authenticate the packets it sends. the server MUST only use these keys to decrypt and to check the authenticity of inbound packets 🛡️
the server_write_SRTP_master_key and server_write_SRTP_master_salt go into one invocation of the SRTP key derivation function, which makes the SRTP keys the server uses to encrypt and authenticate the packets it sends. the client MUST only use these keys to decrypt and to check the authenticity of inbound packets 🛡️
TLS master
secret label
| |
v v
+---------------+
| TLS extractor |
+---------------+
| +------+ SRTP
+-> client_write_SRTP_master_key ----+--->| SRTP |-> client
| | +->| KDF | write
| | | +------+ keys
| | |
+-> server_write_SRTP_master_key -- | | +------+ SRTCP
| \ \--->|SRTCP |-> client
| \ +->| KDF | write
| | | +------+ keys
+-> client_write_SRTP_master_salt ---|-+
| |
| | +------+ SRTP
| +--->| SRTP |-> server
+-> server_write_SRTP_master_salt -+-|--->| KDF | write
| | +------+ keys
| |
| | +------+ SRTCP
| +--->|SRTCP |-> server
+----->| KDF | write
+------+ keysFigure 1: The derivation of the SRTP keys.
when RTCP and RTP use the same source and destination ports, then both the SRTP and SRTCP keys are needed 🎯 otherwise there are two DTLS-SRTP sessions. one protects the RTP packets and the other protects the RTCP packets. each DTLS-SRTP session protects the part of an SRTP session that passes over a single source/destination transport address pair, as shown in Figure 2, no matter which SSRCs are used on that pair. when a DTLS-SRTP session is protecting RTP, the SRTCP keys derived from the DTLS handshake aren't needed and get discarded. when a DTLS-SRTP session is protecting RTCP, the SRTP keys derived from the DTLS handshake aren't needed and get discarded 🗑️
Client Server
(Sender) (Receiver)
(1) <----- DTLS ------> src/dst = a/b and b/a
------ SRTP ------> src/dst = a/b, uses client write keys
(2) <----- DTLS ------> src/dst = c/d and d/c
------ SRTCP -----> src/dst = c/d, uses client write keys
<----- SRTCP ------ src/dst = d/c, uses server write keysFigure 2: A DTLS-SRTP session protecting RTP (1) and another one protecting RTCP (2), showing the transport addresses and keys used.
4.3. Key Scope 🗝️
because packets can get reordered, DTLS-SRTP implementations SHOULD store multiple SRTP key sets during a rekey. that way receivers don't have to drop packets they don't have a key for 🫧
4.4. Key Usage Limitations ⏳
the maximum_lifetime parameter in the SRTP protection profile is the max number of packets that can be protected with each single encryption and authentication key. (note that since RTP and RTCP are protected with independent keys, those protocols get counted separately when working out when a key has hit the end of its lifetime 🧮) each profile defines its own limit. when that limit is reached, a new DTLS session SHOULD be used to establish replacement keys, and SRTP implementations MUST NOT use the existing keys for processing either outbound or inbound traffic 🚫
5. Use of RTP and RTCP over a DTLS-SRTP Channel 🎬
5.1. Data Protection 🛸
once the DTLS handshake has completed, the peers can send RTP or RTCP over the newly created channel. we'll go through the transmission process first, then the reception process 💫
within each RTP session, SRTP processing MUST NOT take place before the DTLS handshake completes 🙌
5.1.1. Transmission ✨
okay so DTLS and TLS define a bunch of record content types 💅 In regular TLS/DTLS, everything gets protected with the same record encoding and the same mechanisms, no exceptions. But when this mechanism is in effect, that changes. Data written by the upper-level protocol clients of DTLS is treated as RTP/RTP and gets encrypted with SRTP instead of the usual TLS record encoding 🦋
When a DTLS user wants to send an RTP packet in SRTP mode, they hand it to the DTLS implementation as an ordinary application data write, like SSL_write(). The DTLS implementation then runs the processing from RFC 3711, Sections 3 and 4 🚀 The resulting SRTP packet goes straight onto the wire as one single datagram with no DTLS framing at all. This gives you an encapsulation of the data that conforms to and interoperates with SRTP 🫶 Heads up, though: these packets use the RTP sequence number, not the DTLS sequence number 🧚
5.1.2. Reception
so when DTLS-SRTP is protecting an RTP session, the RTP receiver has to demultiplex the packets arriving on the RTP port 🌈 Those packets can be RTP, DTLS, or STUN [RFC5389]. If those are the only types floating around, you can tell a packet's type just by looking at its first byte 👑
Here's how the receiver sorts things out. It looks at the first byte of the packet. If the value is 0 or 1, the packet is STUN. If the value is between 128 and 191 (inclusive), the packet is RTP, or RTCP if RTP and RTCP are being multiplexed over the same destination port. If the value is between 20 and 63 (inclusive), the packet is DTLS. Here's the whole thing in Figure 3 🎀
+----------------+
| 127 < B < 192 -+--> forward to RTP
| |
packet --> | 19 < B < 64 -+--> forward to DTLS
| |
| B < 2 -+--> forward to STUN
+----------------+Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. Here the field B denotes the leading byte of the packet.
If you want to multiplex other packet types too, implementors and/or designers SHOULD ensure that those types can be demultiplexed from these three packet types 🔥
Now, sometimes one SRTP endpoint ends up with multiple DTLS-SRTP associations 😭 For example, if Alice makes a call that gets SIP forked to both Bob and Charlie, she uses the same local host/port pair for both of them, like in Figure 4. XXX and YYY stand for the different DTLS-SRTP associations. (The SSRCs shown are the ones for data flowing to Alice.)
Bob (192.0.2.1:6666)
/
/
/ SSRC=1
/ DTLS-SRTP=XXX
/
v
Alice (192.0.2.0:5555)
^
\
\ SSRC=2
\ DTLS-SRTP=YYY
\
\
Charlie (192.0.2.2:6666)Figure 4: RTP sessions with SIP forking.
DTLS works on the host/port quartet, so the DTLS association still completes correctly, using the foreign host/port pair to tell the associations apart. RTP is a different story, though. It doesn't use the source host/port, and sessions get identified by the destination host/port plus the SSRC. So we need a way to figure out which SSRCs belong to which DTLS associations 🧩 The following method SHOULD be used.
For each local host/port pair, the DTLS-SRTP implementation keeps a table of all the SSRCs it knows about and the DTLS-SRTP associations they belong to. The table starts out empty. When an SRTP packet arrives for a given RTP endpoint (destination IP/port pair), this is the procedure:
- If the SSRC is already known for that endpoint, the corresponding DTLS-SRTP association and its keying material get used to decrypt and verify the packet.
- If the SSRC is not known, the receiver tries to decrypt the packet with the keying material for each DTLS-SRTP association on that endpoint.
- If decryption and verification succeed (the authentication tag verifies), an entry gets added to the table mapping the SSRC to that association.
- If decryption and verification fail, the packet is silently discarded.
- When a DTLS-SRTP association is closed (for instance, because the fork is abandoned), its entries MUST be removed from the mapping table.
The average cost of this for a single SSRC is the decryption and verification time of one packet, multiplied by the number of valid DTLS-SRTP associations on a single receiving port of the host. In practice, that's the number of forks, so in the Figure 4 case it's two 🦋 You only pay this cost once per SSRC, since after that the SSRC sits in the map table and gets looked up right away. Just like normal RTP, this lets the source introduce new SSRCs at any time, and they'll automatically map to the right DTLS association 💜
Multiple SSRCs can be sent from the same address/port pair, and this algorithm explicitly allows that. One way it happens is with an RTP translator. The algorithm will automatically assign the SSRCs to the correct associations. But here's the catch: because the SRTP packets are cryptographically protected, a translator has to either share keying material with one endpoint or leave the packets alone in a way that would break the integrity check. This is a general property of SRTP and isn't specific to DTLS-SRTP 🙈
There are two error cases to think about. First, if an SSRC collision happens, only packets from the first source get processed. When packets from the second source show up, the DTLS association with the first source is used for decryption and verification, which fails, so the packet gets discarded. This is consistent with [RFC3550], which lets the receiver keep packets from one source and discard those from the other. And of course, the RFC 3550 SSRC collision detection and handling procedures MUST also be followed 💀
Second, a malfunctioning source might send corrupt packets that can never be decrypted and verified. In that case, the SSRC never gets into the mapping table, because decryption and verification always fail. Receivers MAY keep records of unmapped SSRCs that consistently fail decryption and verification, and stop trying to process them once they hit some limit. That limit MUST be large enough to account for the effects of transmission errors. Entries MUST be pruned from this table when the relevant SRTP endpoint is deleted (for example, when the call ends). They SHOULD also time out faster than that. We don't give a hard recommendation here, but 10 to 30 seconds seems appropriate 🌸 The reason is to allow for the possibility that the peer implementation has been fixed in the meantime ✨
5.2. Rehandshake and Rekey
okay rekeying in DTLS happens by doing a brand new handshake over the existing DTLS channel 🔐 So the handshake messages are protected by the existing DTLS cipher suite. The best part is that this handshake can run in parallel with data transport, so the data flow doesn't have to stop at all 🙌 Once the handshake finishes, the newly derived set of keys protects all outbound packets, both DTLS and SRTP.
Packets can get reordered, which means packets protected by the previous set of keys can still show up on the wire after the handshake is done 😵 To handle that, receivers SHOULD maintain both sets of keys for some time, so they can still decrypt and verify older packets. The keys should be maintained for the duration of the maximum segment lifetime (MSL).
If an MKI is used, the receiver should use the matching set of keys to process an incoming packet. If there's no matching MKI present, the packet MUST be rejected. Otherwise, when a packet arrives after the handshake has completed, a receiver SHOULD use the newly derived set of keys to process that packet, unless there is an MKI. (If the packet was protected with the older set of keys, the receiver will find out because an authentication failure happens.) If the authentication check on the packet fails and no MKI is being used, the receiver MAY process the packet with the older set of keys. If that check says the packet is valid, the packet should be accepted. Otherwise, the packet MUST be discarded and rejected 🧐
Receivers MAY use the SRTP packet sequence number to help pick the keys. Once a packet has been received and authenticated with the new key set, any packets with greater sequence numbers will also have been protected with the new key set 💖
6. Multi-Party RTP Sessions
DTLS is a point-to-point protocol, so DTLS-SRTP is only meant to protect unicast RTP sessions 🎀 That doesn't rule out using it with RTP mixers, though. For example, a conference bridge can use DTLS-SRTP to secure the communication to and from each participant in a conference. But because each flow between an endpoint and a mixer has its own key, the mixer has to decrypt and then reencrypt the traffic for each recipient 🫠
A future specification might describe ways to share a single key across multiple DTLS-SRTP associations, so conferencing systems could skip the decrypt/reencrypt stage 👀 Still, any system that modifies the media (for example, for level balancing or transcoding) generally needs to do that on the plaintext. It will definitely break the authentication tag, so it'll need a decrypt/reencrypt stage anyway 💅
7. Security Considerations
okay this part is serious 😤 Using multiple data protection framings negotiated in the same handshake creates some complexities, and we're going to talk through them here.
7.1. Security of Negotiation
One worry is that attackers might be able to pull off a bid-down attack, forcing the peers to use ordinary DTLS instead of SRTP 🚨 But the negotiation of this extension happens inside the DTLS handshake, so it's protected by the Finished messages. That means any bid-down attack gets detected automatically. So it gets reduced to a denial-of-service attack, which any attacker who can control the channel can mount 😭
7.2. Framing Confusion ✨
okay bestie, this one is sneaky 🕵️♀️ Because two different framing formats are used, there's a worry that an attacker could trick the receiver into treating an SRTP-framed RTP packet as a DTLS record (like a handshake message), or the other way around. 😱 The fix is that each type of data gets its own keys for Message Authentication Code (MAC) verification. So this kind of attack basically turns into "can you forge a packet with a valid MAC?" and that would break a basic security invariant of both DTLS and SRTP. Not happening, babe 💅
As an extra layer of defense against injecting stuff into the DTLS handshake channel, the DTLS record type is included in the MAC. So an SRTP record would just get treated as an unknown type and ignored 🙅♀️ (See Section 6 of [RFC5246].)
7.3. Sequence Number Interactions
okay so, as described in Section 5.1.1, the SRTP and DTLS sequence number spaces are totally separate 🧩 which means you can't unambiguously put a given DTLS control record in order relative to an SRTP packet. This matters mostly in two situations: alerts and rehandshake.
7.3.1. Alerts
Good news! DTLS handshake and change_cipher_spec messages share the same sequence number space as alerts, so those can be ordered correctly ✨ Alerts are inherently unreliable, though, and they SHOULD NOT be generated as a response to data packets. So reliable sequencing between SRTP packets and DTLS alerts isn't a big deal here 🙈 Still, implementations that want to use DTLS alerts to signal problems with the SRTP encoding SHOULD just act on alerts as soon as they arrive, and assume they refer to the temporally contiguous stream. And they MUST check for alert retransmission and discard retransmitted alerts, so nobody gets tricked into overreacting to replay attacks 🛡️
Retransmitted alerts = potential replay drama. Check for them, bestie! 😤
7.3.2. Renegotiation
okay this part is a little spicy 🌶️ The rehandshake transition algorithm in Section 5.2 has to try multiple sets of keys when no MKI is used, and that slightly weakens authentication. For example, if you've got an n-bit MAC and k different sets of keys, the MAC gets weakened by log_2(k) bits, down to n - log_2(k). In practice though, the number of keys is super small and the MACs in use are usually strong (the default for SRTP is 80 bits), so the security hit is minimal 🥰
Another thing: this algorithm slightly bumps up the work factor on the receiver, since it has to attempt multiple validations. Again, the number of potential keys is very small (and an attacker can't force it to get bigger), and this technique is already used for rollover counter management. So the authors don't think this is a serious flaw 💖
7.4. Decryption Cost
okay so an attacker can make the receiver do extra work by sending superficially valid SRTP packets that don't decrypt correctly 💀 Honestly though, encryption algorithms are so fast that this cost is tiny compared to the bandwidth being used ⚡ The SSRC-DTLS mapping algorithm from Section 5.1.2 gives attackers a slight edge, because they can force the receiver to do more than one decryption per packet. But the edge is modest, since the number of decryptions is capped by how many associations the receiver has for a given destination host/port, which is usually pretty small 🌸
For comparison, a single 1024-bit RSA private key operation (the typical minimum cost to set up a DTLS-SRTP association) is hundreds of times more expensive than decrypting one SRTP packet. Wild, right? 😭
Implementations can spot this kind of attack by keeping track of how many SRTP packets they see with unknown SSRCs that fail the authentication tag check 👀 If they're under attack, implementations SHOULD prioritize decrypting and verifying packets that either have known SSRCs or come from source addresses matching peers they already have DTLS-SRTP associations with 🫶
8. Session Description for RTP/SAVP over DTLS ✨
This spec defines new tokens for describing the protocol used in SDP media descriptions ("m=" lines and their parameters) 📝 The new values for the proto field are:
- Over DCCP: when a RTP/SAVP or RTP/SAVPF [RFC5124] stream is carried over DTLS with the Datagram Congestion Control Protocol (DCCP), the token SHALL be
DCCP/TLS/RTP/SAVPorDCCP/TLS/RTP/SAVPF, respectively 🦋 - Over UDP: when a RTP/SAVP or RTP/SAVPF stream is carried over DTLS with UDP, the token SHALL be
UDP/TLS/RTP/SAVPorUDP/TLS/RTP/SAVPF, respectively 🌈
The "fmt" parameter SHALL be defined the same way as it is for RTP/SAVP 💜
For how to use offer/answer with DTLS-SRTP, check out [RFC5763] 🎀
Now, this doc does NOT specify how to protect RTP data sent over TCP 🙅♀️ There are some possible routes, like carrying RTP over TLS over TCP (see [SRTP-NOT-MAND]), or using something similar to this document over TCP with either TLS or DTLS. DTLS would be nice for consistency between reliable and unreliable transports, but then you'd need to profile DTLS so fragmentation and retransmissions stop happening. Either way, you'd need a new document for it 📚
9. IANA Considerations 🧾
This doc adds a new extension for DTLS, following [RFC5246]:
enum { use_srtp (14) } ExtensionType;This extension MUST only be used with DTLS, and NOT with TLS [RFC4572]. That one says TLS can be used over TCP, but it doesn't address TCP for RTP/SAVP 🚫
Section 4.1.2 requires that every SRTPProtectionProfile value be defined by RFC 5226 "Specification Required". IANA has set up a DTLS SRTPProtectionProfile registry, initially filled with the values from Section 4.1.2 of this document. Future values MUST be allocated via the "Specification Required" profile of [RFC5226] 🗂️
This spec updates the "Session Description Protocol (SDP) Parameters" registry as defined in Section 8.2.2 of [RFC4566]. Specifically, it adds these values to the table for the "proto" field 💖
Type SDP Name Reference
---- ------------------ ---------
proto UDP/TLS/RTP/SAVP [RFC5764]
proto DCCP/TLS/RTP/SAVP [RFC5764]
proto UDP/TLS/RTP/SAVPF [RFC5764]
proto DCCP/TLS/RTP/SAVPF [RFC5764]And finally, IANA registered the "EXTRACTOR-dtls_srtp" value in the TLS Extractor Label Registry to match this spec 🎉
10. Acknowledgments 🫶
Special thanks to Flemming Andreasen, Francois Audet, Pasi Eronen, Roni Even, Jason Fischl, Cullen Jennings, Colin Perkins, Dan Wing, and Ben Campbell for their input, discussions, and guidance 💜 Pasi Eronen made Figure 1 🎨
11. References 📚
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E.,
and K. Norrman, "The Secure Real-time Transport
Protocol (SRTP)", RFC 3711, March 2004.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport
Layer Security", RFC 4347, April 2006.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol
(RTCP)", BCP 131, RFC 4961, July 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246,
August 2008.
[RFC5705] Rescorla, E., "Keying Material Exporters for
Transport Layer Security (TLS)", RFC 5705,
March 2010.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP
Data and Control Packets on a Single Port",
RFC 5761, April 2010.11.2. Informative References
[DTLS1.2] Rescorla, E. and N. Modadugu, "Datagram Transport
Layer Security version 1.2", Work in Progress,
October 2009.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", RFC 4566, 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.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile
for Real-time Transport Control Protocol (RTCP)-
Based Feedback (RTP/SAVPF)", RFC 5124,
February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 5226, May 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)",
RFC 5389, October 2008.
[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.
[SRTP-NOT-MAND] Perkins, C. and M. Westerlund, "Why RTP Does Not
Mandate a Single Security Mechanism", Work in
Progress, January 2010.Appendix A. Overview of DTLS 🎀
okay bestie, so this one is a quick little primer on Datagram TLS (DTLS) for anyone who hasn't met it yet 🦋 DTLS is a channel security protocol built on the super famous Transport Layer Security (TLS) protocol [RFC5246] 💅 TLS leans on a reliable transport channel (usually TCP), but DTLS was adapted so it can handle unreliable transports like UDP 🫶 Other than that, it's basically a twin of TLS and supports the same cryptographic mechanisms, no cap ✨
every DTLS association kicks off with a handshake exchange (diagram below) 🌸 during this, the peers authenticate each other, negotiate algorithms, modes, and other parameters, and set up shared keying material 🔑 since the transport is unreliable, each side runs retransmission timers so these messages still get delivered reliably 😭 once the handshake is done, encrypted data can be sent 💜
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
'*' indicates messages that are not always sent.
Figure 5: Basic DTLS Handshake Exchange (after [RFC4347]).application data is protected by being sent as a series of DTLS "records" 🍓 these records are independent, so they can still be processed correctly even if packets get lost or reordered 🧚 in DTLS-SRTP, this record protocol gets replaced with SRTP [RFC3711] 🌈
Appendix B. Performance of Multiple DTLS Handshakes ⭐
okay so this part is all about the overhead of setting up a separate security association for each underlying network channel (like a TCP connection or a UDP host/port quartet) 💖 standard practice for security protocols like TLS, DTLS, and SSH (the ones that do inline key management) is to do exactly that, and it has two big perks: simplicity and each channel's security context staying independent 🫶
three concerns got raised about this approach for RTP security, and I'm obsessed with how they're organized 🙈
the first concern is the extra performance cost of doing a separate public key operation for every channel 😭 the usual fix (used in TLS and DTLS) is to set up a master context that can then derive fresh traffic keys for new associations 👑 in TLS/DTLS this is called "session resumption," and the peers can negotiate it transparently 💅
the second concern is the network bandwidth overhead for setting up later connections and for rehandshakes (rekeying) on existing connections 🦋 the worry is that channels with really narrow capacity are fully allocated to media, so a rehandshake would overflow them 😬 measurements of a rehandshake with resumption in TLS came out to about 300-400 bytes when a full selection of cipher suites is offered 🌸 (a full handshake is around 1-2 kilobytes bigger because of the certificate and keying material exchange 💜)
the third concern is the extra round-trips needed to set up the second, third, and so on channels 🧚 in TLS/DTLS those can all happen in parallel, but to take advantage of session resumption they should happen after the first channel is set up 🔥 for two channels, the ladder diagram looks something like this (the parenthetical numbers are the media channel numbers) ✨
Alice Bob
-------------------------------------------
<- ClientHello (1)
ServerHello (1) ->
Certificate (1)
ServerHelloDone (1)
<- ClientKeyExchange (1)
ChangeCipherSpec (1)
Finished (1)
ChangeCipherSpec (1)->
Finished (1)->
<--- Channel 1 ready
<- ClientHello (2)
ServerHello (2) ->
ChangeCipherSpec(2)->
Finished(2) ->
<- ChangeCipherSpec (2)
Finished (2)
<--- Channel 2 ready
Figure 6: Parallel DTLS-SRTP negotiations.so, there's an extra 1 RTT (round-trip time) after Channel 1 is ready before Channel 2 is ready 😭 if the peers are potentially willing to forgo resumption, they can interlace the handshakes instead, like so 💀
Alice Bob
-------------------------------------------
<- ClientHello (1)
ServerHello (1) ->
Certificate (1)
ServerHelloDone (1)
<- ClientKeyExchange (1)
ChangeCipherSpec (1)
Finished (1)
<- ClientHello (2)
ChangeCipherSpec (1)->
Finished (1)->
<--- Channel 1 ready
ServerHello (2) ->
ChangeCipherSpec(2)->
Finished(2) ->
<- ChangeCipherSpec (2)
Finished (2)
<--- Channel 2 ready
Figure 7: Interlaced DTLS-SRTP negotiations.in this case the channels are ready at the same time, but if a message in handshake (1) gets lost, then handshake (2) needs either a full rehandshake or for Alice to be clever and queue the resumption attempt until the first handshake finishes 🧠 ngl, just dropping the packet works too, since Bob will retransmit 🫶
Authors' Addresses 🌸
David McGrew 💖 Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95305 USA
EMail: mcgrew@cisco.com
Eric Rescorla 💜 RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA
EMail: ekr@rtfm.com
📦 where this page comes from
- ietf: rfc5764 2010-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms