RFC 8870
Encrypted Key Transport for DTLS and Secure RTP
RFC 8870 💖 Encrypted Key Transport for DTLS and Secure RTP
Okay bestie, RFC 8870 is titled Encrypted Key Transport for DTLS and Secure RTP ✨ It's an Internet Engineering Task Force (IETF) document, filed as a Standards Track document with ISSN 2070-1721. The authors are C. Jennings (Cisco Systems), J. Mattsson (Ericsson AB), D. McGrew (Cisco Systems), D. Wing (Citrix), and F. Andreasen (Cisco Systems) 🫶 It's dated January 2021. The title block doesn't list anything it obsoletes or updates, so there's no drama there 💅
Abstract 🎀
Okay so Encrypted Key Transport (EKT) is an add-on for DTLS (Datagram Transport Layer Security) and the Secure Real-time Transport Protocol (SRTP). Its whole job is moving SRTP master keys, rollover counters, and other info around inside SRTP, and doing it securely 🔐 That's what makes SRTP work for decentralized conferences, because everyone gets a shared common key. Iconic, honestly 🦋
Status of This Memo 🌸
This one is an Internet Standards Track document ✅
It's a product of the IETF, so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 📚
For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8870 💌
Copyright Notice 🌈
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication. Please actually read these, bestie, because they explain your rights and restrictions for this document 🙈 Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.
Table of Contents 🧚
1. Introduction
2. Overview
3. Conventions Used in This Document
4. Encrypted Key Transport
4.1. EKTField Formats
4.2. SPIs and EKT Parameter Sets
4.3. Packet Processing and State Machine
4.3.1. Outbound Processing
4.3.2. Inbound Processing
4.4. Ciphers
4.4.1. AES Key Wrap
4.4.2. Defining New EKT Ciphers
4.5. Synchronizing Operation
4.6. Timing and Reliability Considerations
5. Use of EKT with DTLS-SRTP
5.1. DTLS-SRTP Recap
5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP
5.2.1. Negotiating an EKTCipher
5.2.2. Establishing an EKT Key
5.3. Offer/Answer Considerations
5.4. Sending the DTLS EKTKey Reliably
6. Security Considerations
7. IANA Considerations
7.1. EKT Message Types
7.2. EKT Ciphers
7.3. TLS Extensions
7.4. TLS Handshake Type
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Authors' Addresses1. Introduction ✨
Okay, so RTP (the Real-time Transport Protocol) is built for decentralized groups with minimal control who still want to set up sessions, like multimedia conferences 🎥 The catch is that Secure RTP (SRTP) [RFC3711] can't be used in lots of minimal-control scenarios, because it requires that synchronization source (SSRC) values and other data get coordinated among all the participants in a session. For example, if someone joins a session that's already in progress, they need to be told the SRTP keys along with the SSRC, rollover counter (ROC), and other details of the other SRTP sources 😬
SRTP not working without central control was well understood when the protocol was designed. The omission was considered less important than optimizations like bandwidth conservation 📉 Plus, SRTP often runs alongside a signaling system that can provide the central control it needs. The thing is, there are several cases where conventional signaling systems can't easily provide all the coordination required.
This document defines Encrypted Key Transport (EKT) for SRTP, and it cuts down on how much external signaling control an SRTP session with multiple receivers needs 💅 EKT securely distributes the SRTP master key and other info for each SRTP source. With this method, SRTP entities are free to choose SSRC values as they see fit, and they can start up new SRTP sources with new SRTP master keys within a session without coordinating with other entities through external signaling or other external means. Main character energy 👑
EKT extends DTLS and SRTP so a common key encryption key (called an "EKTKey") can be distributed to all endpoints. That way, each endpoint can securely send its SRTP master key and current SRTP ROC to the other participants in the session 🦋 This data gives the receiver the info it needs to instantiate an SRTP receiver context.
EKT can be used in conferences where the central Media Distributor or conference bridge cannot decrypt the media, like the type defined in [RFC8871] 🔒 It can also be used for large-scale conferences where the conference bridge or Media Distributor can decrypt all the media but wants to encrypt the media it's sending just once, then send that same encrypted media to a large number of participants. This reduces encryption CPU time in general, and it's necessary when sending multicast media 🚀
EKT doesn't control how the SSRC is generated. It's only concerned with distributing the security parameters an endpoint needs to associate with a given SSRC, so it can decrypt SRTP packets from that sender 🧚
EKT is not meant to replace external key establishment mechanisms. Instead, it gets used alongside them, and it takes the burden off those methods of delivering the context for each SRTP source to every SRTP participant 🫶 This document defines how EKT works with the DTLS-SRTP approach to key establishment. It does this by using keys derived from the DTLS-SRTP handshake to encipher the EKTKey in addition to the SRTP media.
2. Overview 🌸
This specification defines a way for the server in a DTLS-SRTP negotiation (see Section 5) to provide an EKTKey to the client during the DTLS handshake 🤝 The EKTKey obtained this way can be used to encrypt the SRTP master key that's used to encrypt the media the endpoint sends. This spec also defines a way to send the encrypted SRTP master key (with the EKTKey) along with the SRTP packet (see Section 4). Endpoints that receive this packet and know the EKTKey can use it to decrypt the SRTP master key, and then that key can decrypt the SRTP packet. Chef's kiss 👩🍳
One way to use this specification is the architecture defined by [RFC8871]. Each participant in the conference forms a DTLS-SRTP connection to a common Key Distributor, which distributes the same EKTKey to all the endpoints. Then each endpoint picks its own SRTP master key for the media it sends. When sending media, the endpoint may also include the SRTP master key encrypted with the EKTKey in the SRTP packet. This lets all the endpoints decrypt the media 🎀
3. Conventions Used in This Document 🎀
Okay, this part is the rulebook for the capital-letter words. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📏 Lowercase is just regular English, no cap 💜
4. Encrypted Key Transport 🦋
Okay, now we're in the good stuff. EKT is a brand-new way to give SRTP master keys to an endpoint 🔑 To carry the ciphertext for the SRTP master key, plus any other extra info, a new field called the "EKTField" gets added to the SRTP packets. The EKTField sits at the very end of the SRTP packet. If there's an optional authentication tag, the EKTField comes after it. If there isn't one, the EKTField comes right after the ciphertext portion of the packet 📦
Here's the important part, so listen up 🚨 EKT MUST NOT be used together with SRTP's MKI (Master Key Identifier) or with SRTP's <From, To> [RFC3711], because those SRTP features duplicate some of the functions of EKT. Senders MUST NOT include the MKI when using EKT. Receivers SHOULD simply ignore any MKI field they receive if EKT is in use 🙅♀️
This document defines the use of EKT with SRTP. Its use with the Secure Real-time Transport Control Protocol (SRTCP) would be similar, but that topic is left for a future specification 👀 SRTP is preferred for transmitting keying material for three reasons: (1) it shares fate with the transmitted media, (2) SRTP rekeying can happen without worrying about RTCP transmission limits, and (3) it avoids the need for SRTCP compound packets with RTP translators and mixers 💖
4.1. EKTField Formats ✨
okay so the EKTField has two main looks, and they're both cute in their own way 🎀. The FullEKTField and ShortEKTField each get their own format in Figures 1 and 2. When the EKTField gets tacked onto the end of an SRTP packet, we can call it an "EKT Tag" 🏷️.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: EKT Ciphertext :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: FullEKTField Format
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
Figure 2: ShortEKTField FormatFigure 3 is the ABNF syntax for the EKTField, which is defined in [RFC5234] 📐. The EKTField gets added to the very end of an SRTP packet. The EKTPlaintext is the concatenation of SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC, in that order 🧩. The EKTCiphertext is made by encrypting the EKTPlaintext with the EKTKey 🔐. Future extensions to the EKTField MUST conform to the syntax of the ExtensionEKTField 💅.
BYTE = %x00-FF
EKTMsgTypeFull = %x02
EKTMsgTypeShort = %x00
EKTMsgTypeExtension = %x03-FF ; Message Type %x01 is not available
; for assignment due to its usage by
; legacy implementations.
EKTMsgLength = 2BYTE
SRTPMasterKeyLength = BYTE
SRTPMasterKey = 1*242BYTE
SSRC = 4BYTE ; SSRC from RTP
ROC = 4BYTE ; ROC from SRTP for the given SSRC
EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC
EKTCiphertext = 1*251BYTE ; EKTEncrypt(EKTKey, EKTPlaintext)
Epoch = 2BYTE
SPI = 2BYTE
FullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFull
ShortEKTField = EKTMsgTypeShort
ExtensionData = 1*1024BYTE
ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension
EKTField = FullEKTField / ShortEKTField / ExtensionEKTField
Figure 3: EKTField SyntaxHere's the tea on what each of these bits means 🫶:
- EKTPlaintext: This is the data that goes into the EKT encryption operation. It never shows up on the wire, it's only used for behind-the-scenes EKT math 🙈. It's the SRTP master key plus its length, the SSRC, and the ROC, all bundled together.
- EKTCiphertext: This is the output from the EKT encryption operation (see Section 4.4) ✨. It's included in SRTP packets whenever EKT is in use. The EKTCiphertext can end up longer than the EKTPlaintext it came from, so don't be surprised by that 🌸.
- SRTPMasterKey: On the sender side, this is the SRTP master key tied to the indicated SSRC 🗝️.
- SRTPMasterKeyLength: This is how long the SRTPMasterKey is, in bytes 📏. It depends on the cipher suite negotiated for SRTP using Session Description Protocol (SDP) Offer/Answer [RFC3264] 🤝.
- SSRC: On the sender side, this is the SSRC for this SRTP source 🎤. It's 32 bits long. The SSRC value in the EKT Tag MUST be the same as the one in the header of the SRTP packet the tag is attached to 🙌.
- Rollover Counter (ROC): On the sender side, this is set to the current value of the SRTP ROC in the SRTP context linked to the SSRC in the SRTP packet 🔄. It's 32 bits long too.
- Security Parameter Index (SPI): This tells the receiver which EKTKey and other parameters to use when it processes the packet, within a given conference 🧭. It's 16 bits, a two-byte integer in network byte order. The parameters it points to are:
- The EKT Cipher used to process the packet.
- The EKTKey used to process the packet.
- The SRTP master salt associated with any master key encrypted with this EKT Key. The master salt is communicated separately, via signaling, typically along with the EKTKey. (Recall that the SRTP master salt is used in the formation of Initialization Vectors (IVs) / nonces 🧂.)
- Epoch: This field shows how many SRTP keys have been sent for this SSRC under the current EKTKey, before the current key. It's a two-byte integer in network byte order 🔢. It starts at zero at the beginning of a session, and it resets to zero whenever the EKTKey changes (aka when a new SPI shows up) 🔁. The epoch for an SSRC goes up by one every time the sender transmits a new key. The recipient of a FullEKTField MUST reject any future FullEKTField for this SPI and SSRC that has an epoch value equal to or lower than an epoch already seen 🚫. No time travel allowed, bestie ⏳.
All of these data elements together are called an "EKT parameter set" 💜. To avoid mix-ups, each distinct EKT parameter set that gets used MUST be associated with a distinct SPI value 🫣.
- EKTMsgLength: Every EKT Message Type except the ShortEKTField includes a length in octets (in network byte order) for either the FullEKTField or the ExtensionEKTField. That length counts the length field itself and the EKT Message Type too (more on that in the next bit) 📦.
- Message Type: The last byte tells you what kind of EKTField you've got 🏁. It MUST be 2 for the FullEKTField format and 0 for the ShortEKTField format. If a received EKT Tag has an unknown Message Type, then the receiver MUST discard the whole EKT Tag 🗑️. Bye bye, mystery tag 👋.
4.2. SPIs and EKT Parameter Sets
The SPI is what tells you how the EKT Tag should be processed 🕵️♀️:
- The EKTKey and EKT Cipher used to process the packet.
- The SRTP master salt associated with any master key encrypted with this EKT Key. The master salt is communicated separately, via signaling, typically along with the EKTKey.
Together, these data elements are called an "EKT parameter set" 💖. Again, to avoid ambiguity, each distinct EKT parameter set that is used MUST be associated with a distinct SPI value 💅. How a given parameter set gets matched up with a given SPI value is configured by some other protocol, for example the DTLS-SRTP extension defined in Section 5 🦋.
4.3. Packet Processing and State Machine
At any given time, each SRTP source's SSRC has exactly one EKT parameter set attached to it 🎯. That parameter set is used to process all outbound packets, and it's called the "outbound parameter set" for that SSRC 📤. Other SRTP sources in the same session can have their own EKT parameter sets too, including other sources on the same endpoint. Like, one endpoint with voice and video might have two EKT parameter sets, or there might be multiple video sources on one endpoint, each with its own set 📹🎙️. All of the received EKT parameter sets SHOULD be stored by every participant in an SRTP session, so they can be used to process inbound SRTP traffic 🗄️. If a participant deletes an EKT parameter set (say, because of space limitations), then it won't be able to process Full EKT Tags with updated media keys. That means it won't be able to receive media from a participant that has changed its media key 😬. Not ideal, babe.
Either the FullEKTField or the ShortEKTField gets appended to the tail end of all SRTP packets 📎. Which one to send and when is specified in Section 4.6 🗓️.
4.3.1. Outbound Processing
Check out Section 4.6, which explains when to send an SRTP packet with a FullEKTField 👀. If a FullEKTField isn't being sent, then a ShortEKTField gets sent instead, so the receiver can correctly figure out how to process the packet 🧠.
When an SRTP packet goes out with a FullEKTField, the EKTField for that packet gets created using either the steps below or an equivalent set of steps 🛠️:
- The Security Parameter Index (SPI) field is set to the value of the SPI that is associated with the outbound parameter set 🧭.
- The EKTPlaintext field is computed from the SRTP master key, SSRC, and ROC fields, as shown in Section 4.1 🧮. The ROC, SRTP master key, and SSRC used in EKT processing MUST be the same as the ones used in SRTP processing 🪞.
- The EKTCiphertext field is set to the ciphertext created by encrypting the EKTPlaintext with the EKTCipher, using the EKTKey as the encryption key 🔏. The encryption process is detailed in Section 4.4 📖.
- Then, the FullEKTField is formed using the EKTCiphertext and the SPI associated with the EKTKey used above. The length and Message Type get appended too, using the FullEKTField format 🎀.
Note: The value of the EKTCiphertext field is identical in successive packets protected by the same EKTKey and SRTP master key. This value MAY be cached by an SRTP sender to minimize computational effort 🧊.
The computed FullEKTField gets appended to the end of the SRTP packet, right after the encrypted payload 🍓. When a packet goes out with the ShortEKTField, the ShortEKTField is just tacked onto the packet 🧸.
Outbound packets SHOULD keep using the old SRTP master key for 250 ms after sending any new key in a FullEKTField value ⏱️. This gives everyone in the system time to grab the new key before they start getting media encrypted with it 🫶. (The specific value of 250 ms was picked to be a reasonable upper bound on how much latency and jitter is tolerable in a real-time context 🌈.)
4.3.2. Inbound Processing ✨
okay bestie, let's talk about what happens when a packet lands on an RTP stream 📬 For every single SRTP packet, the receiver runs these steps:
- okay so first, check the last byte to see which EKT format we've got 🔍 If the packet has a ShortEKTField, strip it off and carry on with normal SRTP processing. If it's a FullEKTField, keep going with the steps below. Why the last byte?? The length of the SRTP part isn't known until after decryption, so there's no easy way to find where the EKTField starts from the front. But the whole packet has already arrived, so we parse backwards from the end. That's why the type lives at the very end 🙃 iconic design, honestly.
- Use the Security Parameter Index (SPI) field to find the right EKT parameter set for the packet 🪪 If there's no matching SPI, the verification function MUST return an indication of authentication failure, and the steps below are not performed. The parameter set holds the EKTKey, the EKTCipher, and the SRTP master salt 🧂
- Authenticate and decrypt the EKTCiphertext, as described in Section 4.4, using the EKTKey and EKTCipher from the previous step. If the EKT decryption operation returns an authentication failure, EKT processing MUST be aborted. The receiver SHOULD discard the whole SRTP packet 💀
- Parse the resulting EKTPlaintext (see Section 4.1) to recover the SRTP master key, SSRC, and ROC fields. The SRTP master salt linked to the EKTKey gets pulled out too 🫶 If the srtp_master_salt (see Section 5.2.2) sent as part of the EKTKey is longer than SRTP needs, truncate it by taking the first N bytes from the srtp_master_salt field.
- If the SSRC in the EKTPlaintext doesn't match the SSRC of the SRTP packet you received, this FullEKTField MUST be discarded and the rest of the steps in this list get skipped 🙅♀️ After stripping the FullEKTField, the remainder of the SRTP packet MAY be processed as normal.
- Save the SRTP master key, ROC, and SRTP master salt from the previous steps in a map indexed by the SSRC found in the EKTPlaintext. They can then be used for any future crypto operations on inbound packets with that SSRC 🗂️
- Unless the transform specifies other acceptable key lengths, the length of the SRTP master key MUST be the same as the master key length for the SRTP transform in use. If this isn't the case, the receiver MUST abort EKT processing and SHOULD discard the whole SRTP packet.
- If the length of the SRTP master key is less than the master key length for the SRTP transform in use, and the transform says that length is acceptable, then the SRTP master key value replaces the first bytes of the existing master key. The other bytes stay the same as in the old key. For example, the double GCM transform [RFC8723] allows replacement of the first ("end-to-end") half of the master key 🔐
- At this point EKT processing has successfully completed, and normal SRTP processing takes place 🎉 slay.
The value of the EKTCiphertext field is identical in successive packets protected by the same EKT parameter set, SRTP master key, and ROC. SRTP senders and receivers MAY cache an EKTCiphertext value to optimize processing in cases where the master key hasn't changed. Instead of encrypting and decrypting, senders can just copy the precomputed value, and receivers can compare a received EKTCiphertext to the known value 🧠✨
Section 4.3.1 recommends that SRTP senders keep using an old key for some time after sending a new key in an EKT Tag. Receivers that want to avoid packet loss due to decryption failures MAY perform trial decryption with both the old key and the new key, keeping the result of whichever decryption succeeds. Note that this approach is only compatible with SRTP transforms that include integrity protection 👀
When a new EKTKey comes in, implementations need to use the ekt_ttl field (see Section 5.2.2) to create a time after which that key can't be used. They also need a counter that tracks how many times the key has been used to encrypt data, so it doesn't go past the T value for that cipher (see Section 4.4). If either of these limits gets exceeded, the key can no longer be used for encryption. At that point, implementations need to either use call signaling to renegotiate a new session or terminate the existing session. Terminating the session is a reasonable implementation choice, because these limits shouldn't be exceeded except under an attack or error condition 🚨 no cap, that's a lot of pressure on a key.
4.4. Ciphers 🔑
EKT uses an authenticated cipher to encrypt and authenticate the EKTPlaintext. This specification defines the interface to the cipher, so the interface is abstracted away from the details of that function 🧁 It also defines the default cipher used in EKT. The default cipher described in Section 4.4.1 MUST be implemented, but another cipher that conforms to this interface MAY be used. The cipher used for a given EKTCiphertext value is negotiated using the supported_ekt_ciphers extension (see Section 5.2) and indicated with the SPI value in the FullEKTField.
An EKTCipher is made of an encryption function and a decryption function. The encryption function E(K, P) takes these inputs:
- a secret key K with a length of L bytes, and
- a plaintext value P with a length of M bytes.
The encryption function returns a ciphertext value C whose length is N bytes, where N may be larger than M. The decryption function D(K, C) takes these inputs:
- a secret key K with a length of L bytes, and
- a ciphertext value C with a length of N bytes.
The decryption function returns a plaintext value P that is M bytes long, or it returns an indication that the decryption operation failed because the ciphertext was invalid (i.e., it was not generated by the encryption of plaintext with the key K).
These functions have the property that D(K, E(K, P)) = P for all values of K and P. Each cipher also has a limit T on how many times it can be used with any fixed key value. The EKTKey MUST NOT be used for encryption more than T times. Note that if the same FullEKTField is retransmitted three times, that only counts as one encryption 🔁
Security requirements for EKT Ciphers are discussed in Section 6. 🛡️
4.4.1. AES Key Wrap
The default EKT Cipher is the Advanced Encryption Standard (AES) Key Wrap with Padding algorithm [RFC5649]. It requires a plaintext length M that is at least one octet, and it returns a ciphertext with a length of N = M + (M mod 8) + 8 octets. It can be used with key sizes of L = 16 octets or L = 32 octets, and that use is indicated as AESKW128 or AESKW256, respectively. The key size determines the length of the AES key used by the Key Wrap algorithm. With this cipher, T=2^(48) 🧮
+==========+====+========+
| Cipher | L | T |
+==========+====+========+
| AESKW128 | 16 | 2^(48) |
+----------+----+--------+
| AESKW256 | 32 | 2^(48) |
+----------+----+--------+
Table 1: EKT CiphersAs AES-128 is the mandatory-to-implement transform in SRTP, AESKW128 MUST be implemented for EKT. AESKW256 MAY be implemented 💖
4.4.2. Defining New EKT Ciphers
Other specifications may extend this document by defining other EKTCiphers, as described in Section 7. This section defines how those ciphers interact with this specification 🧩
An EKTCipher decides how the EKTCiphertext field is written and how it gets processed when it's read. This field is opaque to the other aspects of EKT processing. EKT Ciphers are free to use this field in any way, but they SHOULD NOT use other EKT or SRTP fields as an input. The values of the parameters L and T MUST be defined by each EKTCipher. The cipher MUST provide integrity protection 🫧
4.5. Synchronizing Operation 🌸
If a source has its EKTKey changed by key management, it MUST also change its SRTP master key. That will cause it to send out a new FullEKTField and eventually begin encrypting with it, as described in Section 4.3.1. This makes sure that if key management decided the EKTKey needs changing (because a participant left or joined) and told a source about it, the source also changes its SRTP master key. That way, traffic can only be decrypted by those who know the current EKTKey 🔐💅
4.6. Timing and Reliability Considerations ✨
okay so a system using EKT learns the SRTP master keys from the FullEKTField that rides along with SRTP 📦, not from call signaling 📞. A receiver can immediately decrypt an SRTP packet, provided the SRTP packet contains a FullEKTField. 🔓
This section is all about how to deliver new SRTP master keys to receivers reliably and quickly 🚀
There are three cases to think about. The first is a new sender joining a session who needs to share its SRTP master key with every receiver. The second is a sender changing its SRTP master key, which everyone also needs to hear about. The third is a new receiver joining a session that's already happening and needing to learn the sender's SRTP master key. 🧚
New sender: A new sender SHOULD send a packet containing the FullEKTField as soon as possible, ideally in its initial SRTP packet. 🏃♀️ To handle packet loss, it is RECOMMENDED that the FullEKTField be transmitted in three consecutive packets. If the sender does not send a FullEKTField in its initial packets and receivers have not otherwise been provisioned with a decryption key, then decryption will fail and SRTP packets will be dropped until the receiver receives a FullEKTField from the sender. 💀
Rekey: When an EKT Tag is sent over SRTP, the rekeying event shares fate with the SRTP packets protected by that new SRTP master key, so they stick together 🫶 To handle packet loss, it is RECOMMENDED that three consecutive packets containing the FullEKTField be transmitted. 🔁
New receiver: A new receiver doesn't need to communicate its sending SRTP master key, because it's a receiver 🙈 Also, the sender is usually not aware when a new receiver joins, so senders SHOULD periodically transmit the FullEKTField. ⏰ How often depends on how frequently new receivers join, how long those receivers can wait before they can start processing SRTP packets, and how much overhead the FullEKTField is allowed to add. If sending audio and video, the RECOMMENDED frequency is the same as the rate of intra-coded video frames. If only sending audio, the RECOMMENDED frequency is every 100 ms. 🎬🎙️
If none of the above three cases apply, a ShortEKTField SHOULD be sent. 💅
In general, sending FullEKTField tags less often uses less bandwidth, but it makes joins or rekeys take longer to take effect. 🐢 Applications should schedule FullEKTField tags in a way that fits their bandwidth and latency requirements. It's all about balance, bestie ⚖️✨
5. Use of EKT with DTLS-SRTP ✨
This document defines an extension to DTLS-SRTP called "SRTP EKTKey Transport" 🎀 It lets the DTLS-SRTP peer in the server role securely send EKT keying material to the client. That means the client can process EKT keying material in SRTP and pull out the SRTP keying material embedded inside 🔑 Why is this combo so good? DTLS has strong endpoint authentication and flexibility, and EKT gives you secure multi-party RTP with loose coordination and efficient per-source keys. Iconic pairing, honestly 👑
In cases where the DTLS termination point is more trusted than the media relay, the protection DTLS gives EKT keying material means EKT Keys can be tunneled through an untrusted relay, like a centralized conference bridge 🌉 For more details, see [RFC8871].
5.1. DTLS-SRTP Recap
DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers to exchange keying material, algorithms, and parameters for SRTP 🧁 The SRTP flow runs over the same transport as the DTLS-SRTP exchange (that is, the same 5-tuple). DTLS-SRTP mixes the performance and encryption flexibility of SRTP with the convenience of DTLS-integrated key and association management 💖 You can think of it in two equivalent ways: as a new key management method for SRTP, or as a new RTP-specific data format for DTLS 🦋
5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP
This document defines a new TLS negotiated extension called "supported_ekt_ciphers" and a new TLS handshake message type called "ekt_key" 🌸 The extension negotiates the cipher used to encrypt and decrypt EKTCiphertext values, and the handshake message carries the matching key 🔐
Figure 4 shows a message flow between a DTLS 1.3 client and server using EKT, configured with the DTLS extensions from this section 🧚 (The initial cookie exchange and other normal DTLS messages are left out.) To be clear, EKT can be used with versions of DTLS before 1.3 too 🙌 The only difference is that in pre-1.3 TLS, stacks won't have built-in support for generating and processing ACK messages 🤓
Client Server
ClientHello
+ use_srtp
+ supported_ekt_ciphers
-------->
ServerHello
{EncryptedExtensions}
+ use_srtp
+ supported_ekt_ciphers
{... Finished}
<--------
{... Finished} -------->
[ACK]
<-------- [EKTKey]
[ACK] -------->
|SRTP packets| <-------> |SRTP packets|
+ <EKT Tags> + <EKT Tags>
{} Messages protected using DTLS handshake keys
[] Messages protected using DTLS application traffic keys
<> Messages protected using the EKTKey and EKT Cipher
|| Messages protected using the SRTP master key sent in
a Full EKT Tag
Figure 4: DTLS 1.3 Message FlowIn a multi-party SRTP session where each endpoint does a DTLS handshake as a client with a central DTLS server, the extensions in this document let the DTLS server set one common EKTKey for everyone 🎉 Each endpoint can then use EKT Tags encrypted with that shared key to tell the other endpoints which keys it uses to protect SRTP packets. This skips the need for lots of individual DTLS handshakes between endpoints, but the trade-off is that endpoints can't directly authenticate one another 🫠
Client A Server Client B
<----DTLS Handshake---->
<--------EKTKey---------
<----DTLS Handshake---->
---------EKTKey-------->
-------------SRTP Packet + EKT Tag------------->
<------------SRTP Packet + EKT Tag--------------5.2.1. Negotiating an EKTCipher
To say it supports EKT, a DTLS-SRTP client puts an extension of type supported_ekt_ciphers in its ClientHello. It lists the ciphers the client uses for EKT in preference order, most preferred first 🥇 If the server agrees to use EKT, it includes a supported_ekt_ciphers extension in its EncryptedExtensions (or ServerHello for DTLS 1.2), holding one cipher picked from the ones the client advertised 💫
The extension_data field of this extension holds an "EKTCipher" value, encoded using the syntax defined in [RFC8446]:
enum {
reserved(0),
aeskw_128(1),
aeskw_256(2),
} EKTCipherType;
struct {
select (Handshake.msg_type) {
case client_hello:
EKTCipherType supported_ciphers<1..255>;
case server_hello:
EKTCipherType selected_cipher;
case encrypted_extensions:
EKTCipherType selected_cipher;
};
} EKTCipher;5.2.2. Establishing an EKT Key
Once a client and server finish a handshake that negotiated an EKTCipher, the server MUST provide the client with a key to use when encrypting and decrypting EKTCiphertext values 🗝️ EKTKeys go out in encrypted handshake records, using handshake type ekt_key(26). The body of the handshake message is an EKTKey structure, like this:
struct {
opaque ekt_key_value<1..256>;
opaque srtp_master_salt<1..256>;
uint16 ekt_spi;
uint24 ekt_ttl;
} EKTKey;Here's what each field does 🧠
ekt_key_value: The EKTKey that the recipient should use when generating EKTCiphertext values.srtp_master_salt: The SRTP master salt to be used with any master key encrypted with this EKT Key.ekt_spi: The SPI value used to reference this EKTKey and SRTP master salt in EKT Tags (along with the EKT Cipher negotiated in the handshake).ekt_ttl: The maximum amount of time, in seconds, that this EKTKey can be used. The ekt_key_value in this message MUST NOT be used for encrypting or decrypting information after the TTL expires. ⏳
If the server did not provide a supported_ekt_ciphers extension in its EncryptedExtensions (or ServerHello for DTLS 1.2), then EKTKey messages MUST NOT be sent by the client or the server 🚫
When an EKTKey is received and processed successfully, the recipient MUST respond with an ACK message, as described in Section 7 of [TLS-DTLS13] ✅ The EKTKey message and ACK MUST be retransmitted following the rules of the negotiated version of DTLS.
EKT MAY be used with versions of DTLS prior to 1.3 ✨ In those cases, the ACK message is still used for reliability. So DTLS implementations that support EKT with pre-1.3 versions of DTLS will need explicit affordances for sending the ACK message in response to an EKTKey message, and for checking that an ACK message was received 🛠️ Otherwise, the retransmission rules for both sides are defined by the negotiated version of DTLS.
If an EKTKey message is received that cannot be processed, then the recipient MUST respond with an appropriate DTLS alert 🚨
5.3. Offer/Answer Considerations
When using EKT with DTLS-SRTP, the negotiation to use EKT happens at the DTLS handshake level and doesn't change the SDP Offer/Answer messaging [RFC3264] 📝 no extra drama there!
5.4. Sending the DTLS EKTKey Reliably
The DTLS EKTKey message is sent using the retransmissions specified in Section 4.2.4 of DTLS [RFC6347] 🔁 Retransmission ends when an ACK message arrives, or when an alert is received 🫶
6. Security Considerations 🔐
Okay bestie, this is the serious section, but we can still make it cute 🥹. EKT inherits the security properties of the key management protocol that is used to establish the EKTKey, e.g., the DTLS-SRTP extension defined in this document. So whatever DTLS-SRTP is giving, EKT gets too 💅
With EKT, each SRTP sender and receiver MUST generate distinct SRTP master keys. This is the main vibe: it kills any worry about reusing keys, because the SRTP layer creates keys on demand ✨ Note that the inputs of EKT are the same as for SRTP with key-sharing, so a single key protects an entire SRTP session. Still, EKT stays secure even when SSRC values collide 🙈
SRTP master keys MUST be randomly generated, and [RFC4086] has some guidance about random number generation 🎲. SRTP master keys MUST NOT be reused for any other purpose, and SRTP master keys MUST NOT be derived from other SRTP master keys. No recycling, no deriving, no exceptions 🙅
The EKT Cipher includes its own authentication/integrity check 🫶.
The SSRC in the EKTPlaintext is what stops an attacker from swapping an EKTCiphertext from one SRTP stream into another. That helps with cut-and-paste attacks, which can happen because there's no cryptographic binding between the EKT Tag and the rest of the SRTP packet. SRTP tags can only be cut-and-pasted within the stream of packets sent by a given RTP endpoint. An attacker can't "cross the streams" and use an EKT Tag from one SSRC to reset the key for another SSRC 🚫. The Epoch field in the FullEKTField also stops an attacker from rolling back to a previous key ⏪.
An attacker could send packets containing a FullEKTField to make the receiving system burn extra CPU. They'd do this by forcing it to decrypt the EKT ciphertext and then detect an authentication failure 😤. In some cases, caching the previous values of the ciphertext, as described in Section 4.3.2, helps with this.
Similarly, EKT has no replay protection. That means an attacker could plant improper keys in receivers by capturing EKTCiphertext values encrypted with a given EKTKey and replaying them in a different context, e.g., from a different sender 😬. When the underlying SRTP transform provides integrity protection, this attack just results in packet loss. If it doesn't, the result is random data being fed to RTP payload processing. An attacker who can pull these off, though, could get the same effects more easily without attacking EKT, so... yeah 🙄.
The key encryption keys distributed with EKTKey messages are group shared symmetric keys. That means they don't provide protection within the group 👯. Group members can impersonate each other. For example, any group member can generate an EKT Tag for any SSRC. The entity that distributes EKTKeys can decrypt any keys distributed using EKT, and therefore any media protected with those keys 👀.
Each EKT Cipher specifies a value T, which is the maximum number of times a given key can be used. An endpoint MUST NOT encrypt more than T different FullEKTField values using the same EKTKey. On top of that, the EKTKey MUST NOT be used beyond the lifetime provided by the TTL described in Section 5.2 ⏳.
The key length of the EKT Cipher MUST be at least as long as the SRTP cipher, and at least as long as the DTLS-SRTP ciphers 📏.
Part of the EKTPlaintext is known or easily guessable to an attacker. So the EKT Cipher MUST resist known plaintext attacks. In practice, this doesn't limit our choices much, since the ciphers in use stay highly secure even when a lot of plaintext is known 🛡️.
An EKT Cipher MUST resist attacks in which both ciphertexts and plaintexts can be adaptively chosen by an attacker who can query both the encryption and decryption functions 🕵️♀️.
In some systems, when someone leaves a conference, the conference gets rekeyed so the departed member no longer has the key. When switching to a new EKTKey, though, an attacker could block the EKTKey message from reaching a particular endpoint. That endpoint would then keep sending media encrypted with the old key 😱. To lower that risk, the lifetime of the EKTKey MUST be limited by using the ekt_ttl 🕰️.
7. IANA Considerations 📋
7.1. EKT Message Types
IANA has created a new table for "EKT Message Types" in the "Real-Time Transport Protocol (RTP) Parameters" registry. The initial values in this registry are as follows:
+==============+=======+===============+
| Message Type | Value | Specification |
+==============+=======+===============+
| Short | 0 | RFC 8870 |
+--------------+-------+---------------+
| Unassigned | 1 | |
+--------------+-------+---------------+
| Full | 2 | RFC 8870 |
+--------------+-------+---------------+
| Unassigned | 3-254 | |
+--------------+-------+---------------+
| Reserved | 255 | RFC 8870 |
+--------------+-------+---------------+
Table 2: EKT Message TypesNew entries in this table can be added via "Specification Required" as defined in [RFC8126]. To avoid conflicts with pre-standard versions of EKT that have already been deployed, IANA SHOULD give preference to the allocation of even values over odd values until the even code points are used up 🧩. Allocated values MUST be in the range of 0 to 254.
All new EKT messages MUST be defined to include a length parameter, as specified in Section 4.1 📏.
7.2. EKT Ciphers
IANA has created a new table for "EKT Ciphers" in the "Real-Time Transport Protocol (RTP) Parameters" registry. The initial values in this registry are as follows:
+============+=======+===============+
| Name | Value | Specification |
+============+=======+===============+
| AESKW128 | 0 | RFC 8870 |
+------------+-------+---------------+
| AESKW256 | 1 | RFC 8870 |
+------------+-------+---------------+
| Unassigned | 2-254 | |
+------------+-------+---------------+
| Reserved | 255 | RFC 8870 |
+------------+-------+---------------+
Table 3: EKT Cipher TypesNew entries in this table can be added via "Specification Required" as defined in [RFC8126]. The expert SHOULD ensure that the specification defines the values for L and T as required in Section 4.4 of this document 🧐. Allocated values MUST be in the range of 0 to 254.
7.3. TLS Extensions
IANA has added supported_ekt_ciphers as a new extension name to the "TLS ExtensionType Values" table of the "Transport Layer Security (TLS) Extensions" registry 🎀:
Value: 39
Extension Name: supported_ekt_ciphers
TLS 1.3: CH, EE
Recommended: Y
Reference: RFC 88707.4. TLS Handshake Type
IANA has added ekt_key as a new entry in the "TLS HandshakeType" table of the "Transport Layer Security (TLS) Parameters" registry 🧁:
Value: 26
Description: ekt_key
DTLS-OK: Y
Reference: RFC 8870
Comment:8. References 📚
8.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997,https://www.rfc-editor.org/info/rfc2119. - [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI
10.17487/RFC3264, June 2002,https://www.rfc-editor.org/info/rfc3264. - [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI
10.17487/RFC3711, March 2004,https://www.rfc-editor.org/info/rfc3711. - [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI
10.17487/RFC5234, January 2008,https://www.rfc-editor.org/info/rfc5234. - [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI
10.17487/RFC5649, September 2009,https://www.rfc-editor.org/info/rfc5649. - [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, DOI
10.17487/RFC5764, May 2010,https://www.rfc-editor.org/info/rfc5764. - [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI
10.17487/RFC6347, January 2012,https://www.rfc-editor.org/info/rfc6347. - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI
10.17487/RFC8126, June 2017,https://www.rfc-editor.org/info/rfc8126. - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI
10.17487/RFC8174, May 2017,https://www.rfc-editor.org/info/rfc8174. - [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI
10.17487/RFC8446, August 2018,https://www.rfc-editor.org/info/rfc8446.
8.2. Informative References
- [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI
10.17487/RFC4086, June 2005,https://www.rfc-editor.org/info/rfc4086. - [RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach, "Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)", RFC 8723, DOI
10.17487/RFC8723, April 2020,https://www.rfc-editor.org/info/rfc8723. - [RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC)", RFC 8871, DOI
10.17487/RFC8871, January 2021,https://www.rfc-editor.org/info/rfc8871. - [TLS-DTLS13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-dtls13-39, 2 November 2020,
https://tools.ietf.org/html/draft-ietf-tls-dtls13-39.
Acknowledgments 🫶
Thank you to Russ Housley, who gave a detailed review and a ton of help with writing this document 👑. Thanks to David Benham, Yi Cheng, Lakshminath Dondeti, Kai Fischer, Nermeen Ismail, Paul Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean Turner, Magnus Westerlund, and Felix Wyss for the fruitful discussions, comments, and contributions to this document 💖.
Authors' Addresses ✨
Okay bestie, last stop, the people who wrote this thing and where you can find them 🎀
- Cullen Jennings 💖 from Cisco Systems. Email:
fluffy@iii.ca - John Mattsson 🦋 from Ericsson AB. Email:
john.mattsson@ericsson.com - David A. McGrew 👑 from Cisco Systems. Email:
mcgrew@cisco.com - Dan Wing 🌸 from Citrix Systems, Inc. Email:
dwing-ietf@fuggles.com - Flemming Andreasen 🧚 from Cisco Systems. Email:
fandreas@cisco.com
That's the whole squad, five authors across Cisco, Ericsson, and Citrix, all lowkey carrying this spec 💅🔥
📦 where this page comes from
- ietf: rfc8870 2021-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms