RFC 3711
The Secure Real-time Transport Protocol (SRTP)
Part 1 of 12
The Secure Real-time Transport Protocol (SRTP) 🎀
Okay bestie, here's the title block tea ☕
- Series: Network Working Group
- RFC: 3711
- Title: The Secure Real-time Transport Protocol (SRTP)
- Authors: M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman
- Affiliations: Cisco Systems, Inc. (Baugher, McGrew); Ericsson Research (Naslund, Carrara, Norrman)
- Category: Standards Track
- Date: March 2004
- Obsoletes / Updates: the header doesn't list any RFCs being obsoleted or updated ✨
Status of this Memo 📜
So this one is an Internet standards track protocol for the Internet community 💖 It's asking for discussion and suggestions for improvements, so bring your ideas. For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited, so share it with everyone 🌸
Copyright Notice 🦋
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract 🧚
Okay, the TL;DR: SRTP is a profile of the Real-time Transport Protocol (RTP) 💅 It can give RTP traffic and the control traffic for RTP (that's RTCP, the Real-time Transport Control Protocol) confidentiality, message authentication, and replay protection. Iconic glow-up, no cap 🔥
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Goals and Features . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SRTP Framework . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. SRTP Cryptographic Contexts. . . . . . . . . . . . . . . 7
3.2.1. Transform-independent parameters . . . . . . . . 8
3.2.2. Transform-dependent parameters . . . . . . . . . 10
3.2.3. Mapping SRTP Packets to Cryptographic Contexts . 10
3.3. SRTP Packet Processing . . . . . . . . . . . . . . . . . 11
3.3.1. Packet Index Determination, and ROC, s_l Update. 13
3.3.2. Replay Protection. . . . . . . . . . . . . . . . 15
3.4. Secure RTCP . . . . . . . . . . . . . . . . . . . . . . . 15
4. Pre-Defined Cryptographic Transforms . . . . . . . . . . . . . 19
4.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.1. AES in Counter Mode. . . . . . . . . . . . . . . 21
4.1.2. AES in f8-mode . . . . . . . . . . . . . . . . . 22
4.1.3. NULL Cipher. . . . . . . . . . . . . . . . . . . 25
4.2. Message Authentication and Integrity . . . . . . . . . . 25
4.2.1. HMAC-SHA1. . . . . . . . . . . . . . . . . . . . 25
4.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . 26
4.3.1. Key Derivation Algorithm . . . . . . . . . . . . 26
4.3.2. SRTCP Key Derivation . . . . . . . . . . . . . . 28
4.3.3. AES-CM PRF . . . . . . . . . . . . . . . . . . . 28
5. Default and mandatory-to-implement Transforms. . . . . . . . . 28
5.1. Encryption: AES-CM and NULL. . . . . . . . . . . . . . . 29
5.2. Message Authentication/Integrity: HMAC-SHA1. . . . . . . 29
5.3. Key Derivation: AES-CM PRF . . . . . . . . . . . . . . . 29
6. Adding SRTP Transforms . . . . . . . . . . . . . . . . . . . . 29
7. Rationale. . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1. Key derivation . . . . . . . . . . . . . . . . . . . . . 30
7.2. Salting key. . . . . . . . . . . . . . . . . . . . . . . 30
7.3. Message Integrity from Universal Hashing . . . . . . . . 31
7.4. Data Origin Authentication Considerations. . . . . . . . 31
7.5. Short and Zero-length Message Authentication . . . . . . 32
8. Key Management Considerations. . . . . . . . . . . . . . . . . 33
8.1. Re-keying . . . . . . . . . . . . . . . . . . . . . . . 34
8.1.1. Use of the <From, To> for re-keying. . . . . . . 34
8.2. Key Management parameters. . . . . . . . . . . . . . . . 35
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 37
9.1. SSRC collision and two-time pad. . . . . . . . . . . . . 37
9.2. Key Usage. . . . . . . . . . . . . . . . . . . . . . . . 38
9.3. Confidentiality of the RTP Payload . . . . . . . . . . . 39
9.4. Confidentiality of the RTP Header. . . . . . . . . . . . 40
9.5. Integrity of the RTP payload and header. . . . . . . . . 40
9.5.1. Risks of Weak or Null Message Authentication. . . 42
9.5.2. Implicit Header Authentication . . . . . . . . . 43
10. Interaction with Forward Error Correction mechanisms. . . . . 43
11. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 43
11.1. Unicast. . . . . . . . . . . . . . . . . . . . . . . . . 43
11.2. Multicast (one sender) . . . . . . . . . . . . . . . . . 44
11.3. Re-keying and access control . . . . . . . . . . . . . . 45
11.4. Summary of basic scenarios . . . . . . . . . . . . . . . 46
12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 46
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
14.1. Normative References . . . . . . . . . . . . . . . . . . 47
14.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A: Pseudocode for Index Determination . . . . . . . . . . 51
Appendix B: Test Vectors . . . . . . . . . . . . . . . . . . . . . 51
B.1. AES-f8 Test Vectors. . . . . . . . . . . . . . . . . . . 51
B.2. AES-CM Test Vectors. . . . . . . . . . . . . . . . . . . 52
B.3. Key Derivation Test Vectors. . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 561. Introduction ✨
Okay so SRTP is the RTP glow-up 💅 It gives confidentiality, message authentication, and replay protection to the RTP traffic AND the control traffic for RTP, which is RTCP (the Real-time Transport Control Protocol) [RFC3350]. Iconic, periodt 💖
SRTP gives you a framework for encryption and message authentication of RTP and RTCP streams (Section 3). It defines a set of default cryptographic transforms (Sections 4 and 5), and it lets new transforms be introduced in the future (Section 6). With appropriate key management (Sections 7 and 8), SRTP is secure (Sections 9) for unicast and multicast RTP applications (Section 11) 🫶
SRTP can achieve high throughput and low packet expansion, and it's a suitable protection for heterogeneous environments (a mix of wired and wireless networks) 🌈 To get those features, the default transforms are: an additive stream cipher for encryption, a keyed-hash based function for message authentication, and an "implicit" index for sequencing and synchronization. That index is based on the RTP sequence number for SRTP and on an index number for Secure RTCP (SRTCP) 🦋
1.1. Notational Conventions 📚
The vibe here is that the capitalized keywords are the rules, and they mean exactly what [RFC2119] says they mean. Those are: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" ✨
The terminology follows [RFC2828], with one exception. For simplicity, I use the term "random" everywhere to mean randomly or pseudo-randomly generated values. Large amounts of random bits may be hard to get, and for the security of SRTP, pseudo-randomness is enough [RFC1750] 🎲
By convention, the representation is network byte order, which means the left-most bit (octet) is the most significant one. XOR means bitwise addition modulo 2 of binary strings, and || means concatenation. So if C = A || B, the most significant bits of C are the bits of A, and the least significant bits of C equal the bits of B. Hexadecimal numbers get the prefix 0x 🍓
"Encryption" also includes the use of the NULL algorithm, which in practice leaves the data in the clear 🙈
With a slight abuse of notation, I use the terms "message authentication" and "authentication tag" the way everyone does 💅 Even though in some situations, like group communication, the service you actually get is only integrity protection and not data origin authentication, the naming stays the same.
2. Goals and Features 🦋
Here's what SRTP is going for. The security goals are to ensure:
- the confidentiality of the RTP and RTCP payloads, and
- the integrity of the entire RTP and RTCP packets, together with protection against replayed packets.
These security services are optional and independent from each other, except that SRTCP integrity protection is mandatory. Malicious or erroneous alteration of RTCP messages could otherwise disrupt the processing of the RTP stream, so that one's non-negotiable 🔒
Other, functional, goals for the protocol are:
- a framework that permits upgrading with new cryptographic transforms,
- low bandwidth cost, i.e., a framework preserving RTP header compression efficiency,
and, asserted by the pre-defined transforms:
- a low computational cost,
- a small footprint (i.e., small code size and data memory for keying information and replay lists),
- limited packet expansion to support the bandwidth economy goal,
- independence from the underlying transport, network, and physical layers used by RTP, in particular high tolerance to packet loss and re-ordering.
These properties ensure that SRTP is a suitable protection scheme for RTP/RTCP in both wired and wireless scenarios. Main character energy 👑
2.1. Features 🌈
Besides the direct goals above, SRTP has some extra features. They were added to lighten the burden on key management and to boost security even more. They include:
- A single "master key" can provide keying material for confidentiality and integrity protection, for both the SRTP stream and the matching SRTCP stream. This works through a key derivation function (see Section 4.3), which gives "session keys" for each security primitive, securely derived from the master key 🔑
- The key derivation can also be set up to periodically refresh the session keys. That limits how much ciphertext a fixed key produces, which limits what an adversary has to cryptanalyze 🧚
- "Salting keys" protect against pre-computation and time-memory tradeoff attacks [MF00] [BS00] 🧂
Detailed rationale for these features can be found in Section 7 ✨
3. SRTP Framework ✨
okay so RTP is the Real-time Transport Protocol [RFC3550], and we define SRTP as a profile of RTP 🎀 it's an extension to the RTP Audio/Video Profile [RFC3551]. unless we explicitly say otherwise, everything in that profile still applies, plus the SRTP security features 🔐 the vibe is a "bump in the stack" 💅 it sits between the RTP app and the transport layer. on the sending side it grabs RTP packets and forwards an equivalent SRTP packet. on the receiving side it grabs SRTP packets and passes an equivalent RTP packet up the stack. it's giving middleman, but make it iconic 🦋
Secure RTCP (SRTCP) gives RTCP the same security services that SRTP gives RTP ✨ SRTCP message authentication is MANDATORY 🚨 that's how it protects the RTCP fields that keep track of membership, give feedback to RTP senders, or maintain packet sequence counters. SRTCP gets its own section, Section 3.4 💖
3.1. Secure RTP
the SRTP packet format is shown in Figure 1 🌸
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P|X| CC |M| PT | sequence number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| synchronization source (SSRC) identifier | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| contributing source (CSRC) identifiers | |
| .... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| RTP extension (OPTIONAL) | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | payload ... | |
| | +-------------------------------+ |
| | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag (RECOMMENDED) : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+- Encrypted Portion* Authenticated Portion ---+Figure 1 is the SRTP packet, and the *Encrypted Portion is the same size as the plaintext for the Section 4 pre-defined transforms 👀
The "Encrypted Portion" of an SRTP packet is the encryption of the RTP payload (padding included, when there is padding) from the equivalent RTP packet 🔒 the Encrypted Portion MAY be the exact size of the plaintext or MAY be larger. Figure 1 shows the RTP payload with any possible padding for RTP [RFC3550] 💜
none of the pre-defined encryption transforms uses padding, so for those the RTP and SRTP payload sizes match exactly 🎯 new transforms added to SRTP (following Section 6) may need padding, which means they can produce bigger payloads. RTP has its own padding format (see Fig. 1), and thanks to the padding indicator in the RTP header it's compact compared to padding that uses prefix-free codes 🧚 this RTP padding SHALL be the default method for transforms that need padding. Transforms MAY specify other padding methods, but then they MUST specify the amount, format, and processing of their padding 📝
⚠️ heads up bestie: encryption transforms that use padding are vulnerable to subtle attacks, especially when message authentication is not used [V02]. every spec for a new encryption transform needs to carefully think through and describe the security implications of the padding it uses 😭 message authentication codes define their own padding, so this default does not apply to authentication transforms.
the OPTIONAL MKI and the RECOMMENDED authentication tag are the only fields SRTP defines that aren't in RTP 🫶 only 8-bit alignment is assumed.
- MKI (Master Key Identifier): configurable length, OPTIONAL. the MKI is defined, signaled, and used by key management 🗝️ it identifies the master key that the session key(s) were derived from, which authenticate and/or encrypt that particular packet. the MKI SHALL NOT identify the SRTP cryptographic context, which is identified according to Section 3.2.3 🙅♀️ the MKI MAY be used by key management for re-keying, or for identifying a particular master key within the cryptographic context (Section 3.2.1).
- Authentication tag: configurable length, RECOMMENDED. the authentication tag carries message authentication data 🔏 the Authenticated Portion of an SRTP packet is the RTP header followed by the Encrypted Portion of the SRTP packet. so if you do both encryption and authentication, encryption SHALL be applied before authentication on the sender side, and the reverse on the receiver side 🔄 the authentication tag authenticates the RTP header and payload, and it indirectly gives replay protection by authenticating the sequence number 🛡️ the MKI is not integrity protected, since that wouldn't add any extra protection, so no need 💅
3.2. SRTP Cryptographic Contexts
every SRTP stream needs the sender and receiver to keep track of cryptographic state information 🧠 this info is called the "cryptographic context" 🎀
SRTP uses two kinds of keys ✨ a "session key" is a key used directly in a cryptographic transform (like encryption or message authentication) 🔑 a "master key" is a random bit string (provided by the key management protocol) that session keys are derived from in a cryptographically secure way 💫 the master key(s) and other parameters in the cryptographic context come from key management mechanisms outside SRTP, see Section 8 🌈
3.2.1. Transform-independent parameters
transform-independent parameters are in the cryptographic context no matter which encryption or authentication transforms are used 💖 the transform-independent parameters of the SRTP cryptographic context are:
- a 32-bit unsigned rollover counter (ROC), which counts how many times the 16-bit RTP sequence number has reset to zero after going past 65,535 🔄 unlike the sequence number (SEQ), which SRTP pulls from the RTP packet header, SRTP maintains the ROC itself, as described in Section 3.3.1 🧮
we define the index of an SRTP packet for a given ROC and RTP sequence number as the 48-bit quantity:
i = 2^16 * ROC + SEQ.- for the receiver only, a 16-bit sequence number s_l 🫧 think of it as the highest received RTP sequence number (see Section 3.3.1 for how it's handled). it SHOULD be authenticated, since message authentication is RECOMMENDED 🔏
- an identifier for the encryption algorithm, meaning the cipher and its mode of operation 🍓
- an identifier for the message authentication algorithm 🧁
- a replay list, kept by the receiver only (when authentication and replay protection are provided), holding the indices of recently received and authenticated SRTP packets 📜
- an MKI indicator (0/1) for whether an MKI is present in SRTP and SRTCP packets 🚩
- if the MKI indicator is set to one, the length (in octets) of the MKI field, and (for the sender) the actual value of the MKI that's currently active. the value of the MKI indicator and the length MUST be kept fixed for the lifetime of the context 🔒
- the master key(s), which MUST be random and kept secret 🤫
- for each master key, a counter of how many SRTP packets have been processed (sent) with that master key. this is essential for security, see Sections 3.3.1 and 9 📊
- non-negative integers n_e and n_a, which set the length of the session keys for encryption and message authentication 📏
on top of that, for each master key, an SRTP stream MAY use the following associated values ✨
- a master salt, used in the key derivation of session keys 🧂 this value MUST be random, but MAY be public. using a master salt is strongly RECOMMENDED, see Section 9.2. a "NULL" salt is treated as
00...0💅 - an integer from the set
{1,2,4,...,2^24}, the "key_derivation_rate". an unspecified value is treated as zero 🧮 being a power of 2 keeps the session-key derivation implementation simple, see Section 4.3 🌸 - an MKI value 🗝️
<From, To>values, which set the lifetime for a master key 💜 they're expressed as the two 48-bit index values, and the master key is valid inside that range (the end-points included). for how<From, To>is used, see Section 8.1.1 🦋 it's an alternative to the MKI, and it assumes a master key is in one-to-one correspondence with the SRTP session key that the<From, To>range is defined on 🫶
SRTCP SHALL, by default, share the crypto context with SRTP, except for these things 🎀
- no rollover counter and no s_l value need to be maintained, because the RTCP index is explicitly carried in each SRTCP packet 🙌
- a separate replay list is maintained (when replay protection is provided) 🔁
- SRTCP keeps its own counter for its master key (even if the master key is the same as SRTP's, see below). that's how it counts the SRTCP packets processed with that key 🔢
🚨 the master key(s) MAY be shared between SRTP and the corresponding SRTCP, if the pre-defined transforms (including the key derivation) are used. but the session key(s) MUST NOT be shared like that 🙅♀️
there can also be cases (see Sections 8 and 9.1) where several SRTP streams in one RTP session, identified by their synchronization source (SSRCs, which is part of the RTP header), share most of the crypto context parameters (possibly including master and session keys) 👯♀️ in those cases, just like the normal SRTP/SRTCP sharing above, separate replay lists and packet counters for each stream (SSRC) MUST still be maintained. separate SRTP indices MUST then be maintained too 🧾
a summary of the parameters, pre-defined transforms, and default values for all of the above (and other SRTP parameters) can be found in Sections 5 and 8.2 📚
3.2.2. Transform-dependent parameters
all the encryption, authentication/integrity, and key derivation parameters are defined in the transforms section (Section 4) 🧩 typical examples are cipher block size, session keys, data for Initialization Vector (IV) formation, and so on. future SRTP transform specifications MUST include a section that lists the additional cryptographic context parameters for that transform, if there are any 🥹👑
3.2.3. Mapping SRTP Packets to Cryptographic Contexts 🎀
Okay so quick refresher, bestie 🧚. An RTP session for each participant is defined [RFC3550] by a pair of destination transport addresses (one network address plus a port pair for RTP and RTCP), and a whole multimedia session is just a collection of RTP sessions 💜. For example, one multimedia session could have an audio RTP session, a video RTP session, and a text RTP session. The whole squad 🫶.
A cryptographic context SHALL be uniquely identified by the triplet context identifier 🔑, like this:
context id = <SSRC, destination network address, destination
transport port number>where the destination network address and the destination transport port are the ones in the SRTP packet. It is assumed that, when presented with this information, the key management returns a context with the information as described in Section 3.2.
Now the lowkey tricky part 👀. As noted above, SRTP and SRTCP by default share the bulk of the parameters in the cryptographic context. So retrieving the crypto context parameters for an SRTCP stream in practice may imply a binding to the correspondent SRTP crypto context. It is up to the implementation to assure such binding, since the RTCP port may not be directly deducible from the RTP port only. Alternatively, the key management may choose to provide separate SRTP- and SRTCP- contexts, duplicating the common parameters (such as master key(s)). The latter approach then also enables SRTP and SRTCP to use, e.g., distinct transforms, if so desired. Similar considerations arise when multiple SRTP streams, forming part of one single RTP session, share keys and other parameters. Same energy, different streams ✨.
If no valid context can be found for a packet corresponding to a certain context identifier, that packet MUST be discarded. No exceptions, no cap 🙅♀️.
3.3. SRTP Packet Processing
The following applies to SRTP. SRTCP is described in Section 3.4.
Assuming initialization of the cryptographic context(s) has taken place via key management, the sender SHALL do the following to construct an SRTP packet 📦:
- Determine which cryptographic context to use as described in Section 3.2.3.
- Determine the index of the SRTP packet using the rollover counter, the highest sequence number in the cryptographic context, and the sequence number in the RTP packet, as described in Section 3.3.1.
- Determine the master key and master salt. This is done using the index determined in the previous step or the current MKI in the cryptographic context, according to Section 8.1.
- Determine the session keys and session salt (if they are used by the transform) as described in Section 4.3, using master key, master salt, key_derivation_rate, and session key-lengths in the cryptographic context with the index, determined in Steps 2 and 3.
- Encrypt the RTP payload to produce the Encrypted Portion of the packet (see Section 4.1, for the defined ciphers). This step uses the encryption algorithm indicated in the cryptographic context, the session encryption key and the session salt (if used) found in Step 4 together with the index found in Step 2.
- If the MKI indicator is set to one, append the MKI to the packet.
- For message authentication, compute the authentication tag for the Authenticated Portion of the packet, as described in Section 4.2. This step uses the current rollover counter, the authentication algorithm indicated in the cryptographic context, and the session authentication key found in Step 4. Append the authentication tag to the packet.
- If necessary, update the ROC as in Section 3.3.1, using the packet index determined in Step 2.
To authenticate and decrypt an SRTP packet, the receiver SHALL do the following 🕵️♀️:
- Determine which cryptographic context to use as described in Section 3.2.3.
- Run the algorithm in Section 3.3.1 to get the index of the SRTP packet. The algorithm uses the rollover counter and highest sequence number in the cryptographic context with the sequence number in the SRTP packet, as described in Section 3.3.1.
- Determine the master key and master salt. If the MKI indicator in the context is set to one, use the MKI in the SRTP packet, otherwise use the index from the previous step, according to Section 8.1.
- Determine the session keys, and session salt (if used by the transform) as described in Section 4.3, using master key, master salt, key_derivation_rate and session key-lengths in the cryptographic context with the index, determined in Steps 2 and 3.
- For message authentication and replay protection, first check if the packet has been replayed (Section 3.3.2), using the Replay List and the index as determined in Step 2. If the packet is judged to be replayed, then the packet MUST be discarded, and the event SHOULD be logged.
Next, perform verification of the authentication tag, using the rollover counter from Step 2, the authentication algorithm indicated in the cryptographic context, and the session authentication key from Step 4. If the result is "AUTHENTICATION FAILURE" (see Section 4.2), the packet MUST be discarded from further processing and the event SHOULD be logged.
- Decrypt the Encrypted Portion of the packet (see Section 4.1, for the defined ciphers), using the decryption algorithm indicated in the cryptographic context, the session encryption key and salt (if used) found in Step 4 with the index from Step 2.
- Update the rollover counter and highest sequence number,
s_l, in the cryptographic context as in Section 3.3.1, using the packet index estimated in Step 2. If replay protection is provided, also update the Replay List as described in Section 3.3.2. - When present, remove the MKI and authentication tag fields from the packet.
3.3.1. Packet Index Determination, and ROC, s_l Update 🔢
SRTP implementations use an "implicit" packet index for sequencing, i.e., not all of the index is explicitly carried in the SRTP packet. This is the vibe 🌈. For the pre-defined transforms, the index i is used in replay protection (Section 3.3.2), encryption (Section 4.1), message authentication (Section 4.2), and for the key derivation (Section 4.3).
When the session starts, the sender side MUST set the rollover counter, ROC, to zero. Each time the RTP sequence number, SEQ, wraps modulo 2^16, the sender side MUST increment ROC by one, modulo 2^32 (see security aspects below). The sender's packet index is then defined as
i = 2^16 * ROC + SEQ.Receiver-side implementations use the RTP sequence number to determine the correct index of a packet, which is the location of the packet in the sequence of all SRTP packets. A robust approach for the proper use of a rollover counter requires its handling and use to be well defined. In particular, out-of-order RTP packets with sequence numbers close to 2^16 or zero must be properly handled. This part is giving serious wraparound drama 🎢.
The index estimate is based on the receiver's locally maintained ROC and s_l values. At the setup of the session, the ROC MUST be set to zero. Receivers joining an on-going session MUST be given the current ROC value using out-of-band signaling such as key-management signaling. Furthermore, the receiver SHALL initialize s_l to the RTP sequence number (SEQ) of the first observed SRTP packet (unless the initial value is provided by out of band signaling such as key management).
On consecutive SRTP packets, the receiver SHOULD estimate the index as
i = 2^16 * v + SEQ,where v is chosen from the set { ROC-1, ROC, ROC+1 } (modulo 2^32) such that i is closest (in modulo 2^48 sense) to the value 2^16 * ROC + s_l (see Appendix A for pseudocode).
After the packet has been processed and authenticated (when enabled for SRTP packets for the session), the receiver MUST use v to conditionally update its s_l and ROC variables as follows. If v=(ROC-1) mod 2^32, then there is no update to s_l or ROC. If v=ROC, then s_l is set to SEQ if and only if SEQ is larger than the current s_l; there is no change to ROC. If v=(ROC+1) mod 2^32, then s_l is set to SEQ and ROC is set to v.
After a re-keying occurs (changing to a new master key), the rollover counter always maintains its sequence of values, i.e., it MUST NOT be reset to zero. Never resetting the counter, period 🙅♀️.
As the rollover counter is 32 bits long and the sequence number is 16 bits long, the maximum number of packets belonging to a given SRTP stream that can be secured with the same key is 2^48 using the pre-defined transforms. After that number of SRTP packets have been sent with a given (master or session) key, the sender MUST NOT send any more packets with that key. (There exists a similar limit for SRTCP, which in practice may be more restrictive, see Section 9.2.) This limitation enforces a security benefit by providing an upper bound on the amount of traffic that can pass before cryptographic keys are changed. Re-keying (see Section 8.1) MUST be triggered, before this amount of traffic, and MAY be triggered earlier, e.g., for increased security and access control to media. Recurring key derivation by means of a non-zero key_derivation_rate (see Section 4.3), also gives stronger security but does not change the above absolute maximum value. Keys get refreshed before they get stale 🔄💅.
On the receiver side, there is a caveat to updating s_l and ROC: if message authentication is not present, neither the initialization of s_l, nor the ROC update can be made completely robust. The receiver's "implicit index" approach works for the pre-defined transforms as long as the reorder and loss of the packets are not too great and bit-errors do not occur in unfortunate ways. In particular, 2^15 packets would need to be lost, or a packet would need to be 2^15 packets out of sequence before synchronization is lost. Such drastic loss or reorder is likely to disrupt the RTP application itself. Yikes 😭.
The algorithm for the index estimate and ROC update is a matter of implementation, and should take into consideration the environment (e.g., packet loss rate) and the cases when synchronization is likely to be lost, e.g., when the initial sequence number (randomly chosen by RTP) is not known in advance (not sent in the key management protocol) but may be near to wrap modulo 2^16.
A more elaborate and more robust scheme than the one given above is the handling of RTP's own "rollover counter", see Appendix A.1 of [RFC3550] 🦋.
3.3.2. Replay Protection ✨
okay so replay protection only works if integrity protection is already there 🔐 bestie, it is RECOMMENDED to use replay protection for both RTP and RTCP, because integrity protection alone can't keep you safe from replay attacks 🙈
a packet is "replayed" when an adversary stores it and then re-injects it into the network 👀 when message authentication is provided, SRTP guards against this with a Replay List. every SRTP receiver keeps one, and conceptually it holds the indices of every packet that has been received and authenticated 🦋 in practice the list can use a "sliding window," so a fixed chunk of storage is enough. packet indices that lag behind the packet index in the context by more than SRTP-WINDOW-SIZE can be assumed to have been received 💅 SRTP-WINDOW-SIZE is a receiver-side, implementation-dependent parameter that MUST be at least 64, but it MAY be set to a higher value 🌸
the receiver checks the index of an incoming packet against the replay list and the window. only packets with an index ahead of the window, or inside the window but not already received, SHALL be accepted ✨
after the packet has been authenticated (if necessary, the window is first moved ahead), the replay list SHALL be updated with the new index 🫶
the Replay List can be implemented efficiently with a bitmap that shows which packets have been received, as described in the Security Architecture for IP [RFC2401] 🧚
3.4. Secure RTCP 🎀
secure RTCP follows the same definition as Secure RTP, so no surprises there 💖 SRTCP adds three mandatory new fields (the SRTCP index, an "encrypt-flag," and the authentication tag) and one optional field (the MKI) to the RTCP packet definition. the three mandatory fields MUST be appended to an RTCP packet to form an equivalent SRTCP packet. the added fields follow any other profile-specific extensions 🌈
according to Section 6.1 of [RFC3550], there is a REQUIRED packet format for compound packets 📦 SRTCP MUST be given packets that follow that requirement, meaning the first part MUST be a sender report or a receiver report. however, the RTCP encryption prefix (a random 32-bit quantity) from that Section MUST NOT be used 🙅♀️ as that section says, it only applies to the encryption method specified in [RFC3550] and isn't needed by the cryptographic mechanisms used in SRTP. no cap, it's giving clean design 💅
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| V=2 | P | RC | PT=SR or RR | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| SSRC of sender |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| ~ sender info ~ | ||||||
|---|---|---|---|---|---|---|
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||||
| ~ report block 1 ~ | ||||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||||
| ~ report block 2 ~ | ||||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||||
| ~ ... ~ | ||||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||||
| V=2 | P | SC | PT=SDES=202 | length | ||
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ||||||
| SSRC/CSRC_1 | ||||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||||
| ~ SDES items ~ | ||||||
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ||||||
| ~ ... ~ |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| E | SRTCP index | ||
|---|---|---|---|
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | |||
| ~ SRTCP MKI (OPTIONAL) ~ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| : authentication tag : | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+-- Encrypted Portion Authenticated Portion -----+
Figure 2. this is an example of a Secure RTCP packet 🦋 it's an underlying RTCP compound packet with a Sender Report and an SDES packet inside.
the Encrypted Portion of an SRTCP packet is the encryption (Section 4.1) of the RTCP payload of the equivalent compound RTCP packet 🔒 it runs from the first RTCP packet, i.e., from the ninth (9) octet to the end of the compound packet. the Authenticated Portion covers the entire equivalent (possibly compound) RTCP packet, the E flag, and the SRTCP index (after any encryption has been applied to the payload) 🛡️
the added fields are:
- E-flag: 1 bit, REQUIRED. this tells you whether the current SRTCP packet is encrypted. Section 9.1 of [RFC3550] lets a compound RTCP packet be split into two lower-layer packets, one to be encrypted and one to be sent in the clear 🙈 E set to "1" means encrypted, and "0" means not encrypted.
- SRTCP index: 31 bits, REQUIRED. this is a 31-bit counter for the SRTCP packet 🔢 unlike the "implicit" index approach used for SRTP, the index is explicitly included in each packet. the SRTCP index MUST be set to zero before the first SRTCP packet is sent, and MUST be incremented by one, modulo 2^31, after each SRTCP packet is sent. and after a re-key, the SRTCP index MUST NOT be reset to zero again 😤
- Authentication Tag: configurable length, REQUIRED. this carries the message authentication data 🏷️
- MKI: configurable length, OPTIONAL. the MKI is the Master Key Indicator, and it works according to the MKI definition in Section 3 🗝️
SRTCP uses the cryptographic context parameters and packet processing of SRTP by default, with these changes:
- the receiver doesn't need to "estimate" the index, because it's explicitly signaled in the packet 🙌
- pre-defined SRTCP encryption is as specified in Section 4.1, but it uses the SRTCP Encrypted Portion definition from this section and the SRTCP index as the index i. the encryption transform and related parameters SHALL by default be the same as the ones selected for protecting the associated SRTP stream(s), while the NULL algorithm SHALL be applied to RTCP packets that aren't going to be encrypted. SRTCP may use a different encryption transform than the corresponding SRTP 💜 the expected use for this is when the former has NULL-encryption and the latter has non-NULL-encryption.
the sender assigns a value to the E-flag depending on whether the packet was encrypted or not 🎀
- SRTCP decryption is performed as in Section 4, but only if the E flag is equal to 1. if so, the Encrypted Portion is decrypted, using the SRTCP index as the index i. if the E-flag is 0, the payload is simply left unmodified 🫧
- SRTCP replay protection works as defined in Section 3.3.2, but it uses the SRTCP index as the index i and a separate Replay List that's specific to SRTCP 🔁
- the pre-defined SRTCP authentication tag is specified as in Section 4.2, but it covers the Authenticated Portion of the SRTCP packet given in this section (which includes the index). the authentication transform and related parameters (e.g., key size) SHALL by default be the same as the ones selected for protecting the associated SRTP stream(s) 🔑
- in the last step of processing, only the sender needs to update the SRTCP index by incrementing it modulo 2^31. and for security reasons, the sender MUST also check the number of SRTCP packets processed, see Section 9.2 🚨
message authentication for RTCP is REQUIRED, because RTCP is the control protocol for RTP (it has a BYE packet, for example) 👑
precautions must be taken so the packet expansion in SRTCP (from the added fields) doesn't make SRTCP messages use more than their share of RTCP bandwidth 📊 to avoid that, the following two measures MUST be taken:
- when initializing the RTCP variable "avg_rtcp_size" defined in chapter 6.3 of [RFC3550], it MUST include the size of the fields that SRTCP will add (index, E-bit, authentication tag, and the MKI when present) 🧮
- when updating "avg_rtcp_size" using the variable "packet_size" (section 6.3.3 of [RFC3550]), the value of "packet_size" MUST include the size of the additional fields added by SRTCP 🧮
with these measures in place, SRTCP messages won't use more than the allotted bandwidth 🥰 the catch is that the added fields make messages go out with longer packet intervals, and the increase in intervals is directly proportional to the size of the added fields ⏳ for the pre-defined transforms, the added fields will be at least 14 octets, with an upper bound that depends on the MKI and authentication tag sizes 🌸
4. Pre-Defined Cryptographic Transforms ✨
there are loads of encryption and message authentication algorithms that can be used in SRTP, but we're defining default algorithms here 💅 that way we skip the headache of specifying encodings for signaling algorithm and parameter identifiers. the algorithms we picked fulfill the goals listed in Section 2 🎯 if you want to extend SRTP with new transforms, Section 6 has recommendations for that 🧚
4.1. Encryption ✨
okay so these parameters are shared by both of the pre-defined, non-NULL, encryption transforms in this section 💅
BLOCK_CIPHER-MODEindicates the block cipher used and its mode of operationn_bis the bit-size of the block for the block cipherk_eis the session encryption keyn_eis the bit-length ofk_ek_sis the session salting keyn_sis the bit-length ofk_sSRTP_PREFIX_LENGTHis the octet length of the keystream prefix, a non-negative integer, specified by the message authentication code in use.
the distinct session keys and salts for SRTP/SRTCP are derived by default as described in Section 4.3 🔑
the encryption transforms in SRTP map the SRTP packet index and secret key into a pseudo-random keystream segment 🌈 each keystream segment encrypts a single RTP packet. so encrypting a packet means generating the keystream segment for that packet, then bitwise exclusive-oring it onto the payload of the RTP packet to get the Encrypted Portion of the SRTP packet ✨ if the payload size isn't an integer multiple of n_b bits, the excess (least significant) bits of the keystream are simply discarded 🙈 decryption is basically the same thing, just with the roles of the plaintext and ciphertext swapped 🦋
+----+ +------------------+---------------------------------+
| KG |-->| Keystream Prefix | Keystream Suffix |---+
+----+ +------------------+---------------------------------+ |
|
+---------------------------------+ v
| Payload of RTP Packet |->(*)
+---------------------------------+ |
|
+---------------------------------+ |
| Encrypted Portion of SRTP Packet|<--+
+---------------------------------+Figure 3: Default SRTP Encryption Processing. Here KG denotes the keystream generator, and (*) denotes bitwise exclusive-or.
how the keystream gets generated, given the index, depends on the cipher and its mode of operation 🎀 down below we define two keystream generators. we also define the NULL cipher, for when encrypting RTP isn't required 🫶
the SRTP version of the keystream is shown in Figure 3 👑 the initial octets of each keystream segment MAY be reserved for a message authentication code. if they are, the keystream used for encryption starts right after the last reserved octet. those initial reserved octets are called the "keystream prefix" (not to be confused with the "encryption prefix" of [RFC3550, Section 6.1] 🙈), and the rest of the octets are the "keystream suffix". the keystream prefix MUST NOT be used for encryption. the whole process is in Figure 3, bestie 💖
the number of octets in the keystream prefix is denoted SRTP_PREFIX_LENGTH. a positive, non-zero value of SRTP_PREFIX_LENGTH is what tells you there's a keystream prefix. this means that even when confidentiality isn't being provided, the keystream generator output may still need to be computed for packet authentication. in that case, the default keystream generator (mode) SHALL be used 🔥
the default cipher is the Advanced Encryption Standard (AES) [AES], and we define two modes of running AES: (1) Segmented Integer Counter Mode AES and (2) AES in f8-mode 🌸 for the rest of this section, E(k,x) means AES applied to key k and input block x 🧚
4.1.1. AES in Counter Mode 💜
conceptually, counter mode [AES-CTR] is about encrypting successive integers 🍓 the real definition is a bit more complicated, because it randomizes the starting point of the integer sequence. each packet gets encrypted with a distinct keystream segment, and that segment SHALL be computed as follows 💅
a keystream segment SHALL be the concatenation of the 128-bit output blocks of the AES cipher in the encrypt direction, using key k = k_e, with the block indices in increasing order ✨ written out, each keystream segment looks like this:
E(k, IV) || E(k, IV + 1 mod 2^128) || E(k, IV + 2 mod 2^128) ...where the 128-bit integer value IV SHALL be defined by the SSRC, the SRTP packet index i, and the SRTP session salting key k_s, like so:
IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16)each of the three terms in that XOR-sum gets padded with as many leading zeros as needed to make the operation well-defined, when you treat it as a 128-bit value 🫧
including the SSRC lets the same key protect different SRTP streams inside the same RTP session 🦋 for the security caveats, check Section 9.1, no cap 🙈
for SRTCP, the SSRC of the first header of the compound packet MUST be used, i SHALL be the 31-bit SRTCP index, and k_e and k_s SHALL be replaced by the SRTCP encryption session key and salt 🌈
quick note: the initial value, IV, is fixed for each packet and is formed by "reserving" 16 zeros in the least significant bits for the counter 🎀 the number of blocks of keystream generated for any fixed value of IV MUST NOT exceed 2^16, to avoid keystream re-use (more on that below) 🚫 AES has a 128-bit block size, so 2^16 output blocks are enough to generate the 2^23 bits of keystream needed to encrypt the biggest possible RTP packet. the exception is IPv6 "jumbograms" [RFC2675], which probably won't be used for RTP-based multimedia traffic 🌸 this limit on the maximum bit-size of an encrypted packet is what keeps the method secure by limiting how well probabilistic attacks [BDJR] can work 🔐
for a particular Counter Mode key, each IV value used as an input MUST be distinct, so you don't end up with a two-time pad situation (Section 9.1) 😭 to make that happen, an implementation MUST ensure that the combination of the SRTP packet index of ROC || SEQ and the SSRC used to build the IV are distinct for any particular key. if that uniqueness fails, it could be catastrophic for Secure RTP 💀 this is different from RTP itself, which may be able to tolerate those failures. it is RECOMMENDED that, if a dedicated security module is present, the RTP sequence numbers and SSRC either get generated or checked by that module. in other words, sequence-number and SSRC processing in an SRTP system needs protecting just like the key does 🔥👑
4.1.2. AES in f8-mode 🦋
to encrypt UMTS data (Universal Mobile Telecommunications System, aka 3G networks), there's a solution known as the f8-algorithm (see [f8-a] [f8-b]) 🌈 at a high level, the proposed scheme is a variant of Output Feedback Mode (OFB) [HAC], with a more elaborate initialization and feedback function. like normal OFB, the core is a block cipher. here we also define AES as the block cipher for what we call "f8-mode of operation" RTP encryption ✨ the AES f8-mode SHALL use the same default sizes for session key and salt as AES counter mode 🍓
Figure 4 shows the structure of block cipher E running in f8-mode 🧚
IV
|
v
+------+
| |
+--->| E |
| +------+
| |
m -> (*) +-----------+-------------+-- ... ------+
| IV' | | | |
| | j=1 -> (*) j=2 -> (*) ... j=L-1 ->(*)
| | | | |
| | +-> (*) +-> (*) ... +-> (*)
| | | | | | | |
| v | v | v | v
| +------+ | +------+ | +------+ | +------+
k_e ---+--->| E | | | E | | | E | | | E |
| | | | | | | | | | |
+------+ | +------+ | +------+ | +------+
| | | | | | |
+------+ +--------+ +-- ... ----+ |
| | | |
v v v v
S(0) S(1) S(2) . . . S(L-1)Figure 4. f8-mode of operation (asterisk, (*), denotes bitwise XOR). The figure represents the KG in Figure 3, when AES-f8 is used.
4.1.2.1. f8 Keystream Generation 🌸
the Initialization Vector (IV) SHALL be determined as described in Section 4.1.2.2 (and in Section 4.1.2.3 for SRTCP) 💜
let IV', S(j), and m denote n_b-bit blocks. the keystream, S(0) ||... || S(L-1), for an N-bit message SHALL be defined by setting IV' = E(k_e XOR m, IV) and S(-1) = 00..0. for j = 0,1,..,L-1, where L = N/n_b (rounded up to the nearest integer if it isn't one already), compute:
S(j) = E(k_e, IV' XOR j XOR S(j-1))notice that the IV isn't used directly 👀 instead it gets fed through E under another key to make an internal, "masked" value (called IV') so an attacker can't get known input/output pairs 🔐
the internal counter, j, is there to prevent short keystream cycles 🌀 the value of the key mask m SHALL be:
m = k_s || 0x555..5i.e., the session salting key, appended by the binary pattern 0101.. to fill out the entire desired key size, n_e 🦋
the sender SHOULD NOT generate more than 2^32 blocks, which is enough to generate 2^39 bits of keystream 🙈 unlike counter mode, there's no absolute threshold above (or below) which f8 is guaranteed to be insecure (or secure). the bound above was picked to limit, with a good security margin, the probability of degenerative behavior in f8 keystream generation 🧚
4.1.2.2. f8 SRTP IV Formation 🎀
the point of the following IV formation is to provide a feature we call implicit header authentication (IHA), see Section 9.5 ✨
the SRTP IV for 128-bit block AES-f8 SHALL be formed like this:
IV = 0x00 || M || PT || SEQ || TS || SSRC || ROCM, PT, SEQ, TS, and SSRC SHALL be taken from the RTP header, and ROC comes from the cryptographic context 🫶
including the SSRC in the IV is what lets AES-f8 be used when a master key is shared between multiple streams in the same RTP session (see Section 9.1) 💖
4.1.2.3. f8 SRTCP IV Formation 🌈
the SRTCP IV for 128-bit block AES-f8 SHALL be formed like this:
IV= 0..0 || E || SRTCP index || V || P || RC || PT || length || SSRCwhere V, P, RC, PT, length, and SSRC SHALL be taken from the first header in the RTCP compound packet. E and SRTCP index are the 1-bit and 31-bit fields added to the packet 🍓
4.1.3. NULL Cipher 🫧
the NULL cipher is used when no confidentiality for RTP/RTCP is requested 🙈 the keystream can be thought of as "000..0", meaning the encryption SHALL simply copy the plaintext input into the ciphertext output 💅
4.2. Message Authentication and Integrity ✨
okay so throughout this section, M means the data we're protecting with integrity 🔐. For SRTP, M SHALL consist of the Authenticated Portion of the packet (see Figure 1) with the ROC tacked on the end, so M = Authenticated Portion || ROC. For SRTCP, M SHALL consist of the Authenticated Portion (see Figure 2) only 💅.
Here are the common parameters, bestie 🎀:
AUTH_ALGis the authentication algorithmk_ais the session message authentication keyn_ais the bit-length of the authentication keyn_tagis the bit-length of the output authentication tagSRTP_PREFIX_LENGTHis the octet length of the keystream prefix as defined above, a parameter ofAUTH_ALG
The distinct session authentication keys for SRTP/SRTCP are, by default, derived as specified in Section 4.3.
The values of n_a, n_tag, and SRTP_PREFIX_LENGTH MUST be fixed for any particular fixed value of the key 🔒.
Now the tag process, which is honestly so clean 🦋. The sender computes the tag of M and appends it to the packet. The SRTP receiver checks a message/tag pair by computing a brand-new tag over M using the selected algorithm and key, then comparing it to the tag that came with the message. If the two tags match, the pair is valid. If not, it's invalid and the error audit message "AUTHENTICATION FAILURE" MUST be returned 🚨.
4.2.1. HMAC-SHA1
The pre-defined authentication transform for SRTP is HMAC-SHA1 [RFC2104] 🌸. With HMAC-SHA1, the SRTP_PREFIX_LENGTH (Figure 3) SHALL be 0. For SRTP (or SRTCP, respectively), the HMAC SHALL be applied to the session authentication key and M as specified above, i.e., HMAC(k_a, M). The HMAC output SHALL then be truncated to the n_tag left-most bits ✂️.
4.3. Key Derivation ✨
4.3.1. Key Derivation Algorithm
Okay, this part is giving main character energy 👑. No matter which encryption or message authentication transform you use (it can be a pre-defined SRTP transform or a new one introduced under Section 6), interoperable SRTP implementations MUST use the SRTP key derivation to generate session keys. Once the key derivation rate is properly signaled at the start of the session, the parties that use SRTP key derivation don't need any extra communication between them 🫶.
Here's the picture, Figure 5 🧚:
packet index ---+
|
v
+-----------+ master +--------+ session encr_key
| ext | key | |---------->
| key mgmt |-------->| key | session auth_key
| (optional | | deriv |---------->
| rekey) |-------->| | session salt_key
| | master | |---------->
+-----------+ salt +--------+Figure 5: SRTP key derivation.
Let's talk about how often we do it. At least one initial key derivation SHALL be performed by SRTP. In other words, the first key derivation is REQUIRED 🔑. More key derivations MAY be performed, depending on the key_derivation_rate value in the cryptographic context. The key derivation function SHALL be invoked before the first packet, and then, when r > 0, a key derivation is performed whenever index mod r equals zero. You can think of this as "refreshing" the session keys 🔄. The value of key_derivation_rate MUST be kept fixed for the lifetime of the associated master key.
Interoperable SRTP implementations MAY also derive session salting keys for encryption transforms, the same way both pre-defined transforms do 🧂.
Next, the math, which I promise is cute 🍓. Let m and n be positive integers. A pseudo-random function family is a set of keyed functions {PRF_n(k,x)} such that, for the (secret) random key k and an m-bit x, PRF_n(k,x) is an n-bit string that's computationally indistinguishable from random n-bit strings (see [HAC]). For key derivation in SRTP, a secure PRF with m = 128 (or more) MUST be used, and a default PRF transform is defined in Section 4.3.3 🔐.
Let "a DIV t" denote integer division of a by t, rounded down, with the convention that "a DIV 0 = 0" for all a. We also treat "a DIV t" as a bit string of the same length as a, so "a DIV t" will generally have leading zeros 🌈.
Key derivation SHALL be defined as follows, in terms of <label> (an 8-bit constant, see below), master_salt and key_derivation_rate (as determined in the cryptographic context), and index (the packet index, which is the 48-bit ROC || SEQ for SRTP) 💜:
- Let
r = index DIV key_derivation_rate(with DIV as defined above). - Let
key_id = <label> || r. - Let
x = key_id XOR master_salt, where key_id and master_salt are aligned so that their least significant bits agree (right-alignment).
<label> MUST be unique for each type of key being derived. We currently define <label> values 0x00 to 0x05 (see below), and future extensions MAY specify new values in the range 0x06 to 0xff for other purposes 🏷️. The n-bit SRTP key (or salt) for this packet SHALL then be derived from the master key, k_master, like this:
PRF_n(k_master, x)(The PRF may internally specify additional formatting and padding of x. See, e.g., Section 4.3.3 for the default PRF.)
The session keys and salt SHALL now be derived using:
k_e(SRTP encryption):<label> = 0x00,n = n_e.k_a(SRTP message authentication):<label> = 0x01,n = n_a.k_s(SRTP salting key):<label> = 0x02,n = n_s.
Here, n_e, n_s, and n_a come from the cryptographic context 🎯.
The master key and master salt MUST be random, but the master salt MAY be public 🧁.
Quick note: for a key_derivation_rate of 0, the key derivation SHALL take place exactly once ☝️.
The definition of DIV above is purely for notational convenience. For a non-zero t among the allowed key derivation rates, "a DIV t" can be implemented as a right-shift by the base-2 logarithm of t. The derivation operation is further facilitated if the rates are chosen to be powers of 256, but that granularity was considered too coarse to be a requirement of this specification 🙃.
The upper limit on the number of packets that can be secured with the same master key (see Section 9.2) is independent of the key derivation 🔢.
4.3.2. SRTCP Key Derivation
SRTCP SHALL by default use the same master key (and master salt) as SRTP 🤝. To do this securely, the following changes SHALL be made to the definitions in Section 4.3.1 when applying session key derivation for SRTCP 🔐.
Replace the SRTP index with the 32-bit quantity 0 || SRTCP index (that is, excluding the E-bit and replacing it with a fixed 0-bit). Then use <label> = 0x03 for the SRTCP encryption key, <label> = 0x04 for the SRTCP authentication key, and <label> = 0x05 for the SRTCP salting key 🏷️.
4.3.3. AES-CM PRF
The currently defined PRF is keyed by a 128, 192, or 256-bit master key. It has input block size m = 128 and can produce n-bit outputs for n up to 2^23 💫. PRF_n(k_master,x) SHALL be AES in Counter Mode as described in Section 4.1.1, applied to key k_master with IV equal to (x*2^16), and with the output keystream truncated to the first (left-most) n bits. (That's n/128, rounded up, applications of AES 🔁.)
5. Default and mandatory-to-implement Transforms 🎀
The default transforms are also mandatory-to-implement transforms in SRTP. Of course, "mandatory-to-implement" does not imply "mandatory-to-use" 🙅♀️. Table 1 summarizes the pre-defined transforms, and the default values below are valid for them 📋.
mandatory-to-impl. optional default
encryption AES-CM, NULL AES-f8 AES-CM
message integrity HMAC-SHA1 - HMAC-SHA1
key derivation (PRF) AES-CM - AES-CMTable 1: Mandatory-to-implement, optional and default transforms in SRTP and SRTCP.
5.1. Encryption: AES-CM and NULL 🔐
AES running in Segmented Integer Counter Mode, as defined in Section 4.1.1, SHALL be the default encryption algorithm 🌟. The default key length SHALL be 128-bit for the session encryption key (n_e). The default session salt key-length (n_s) SHALL be 112 bits 🧂.
The NULL cipher SHALL also be mandatory-to-implement 🫶.
5.2. Message Authentication/Integrity: HMAC-SHA1 🔏
HMAC-SHA1, as defined in Section 4.2.1, SHALL be the default message authentication code 💅. The default session authentication key-length (n_a) SHALL be 160 bits, the default authentication tag length (n_tag) SHALL be 80 bits, and the SRTP_PREFIX_LENGTH SHALL be zero for HMAC-SHA1 🍓.
Now for the important part, so listen up 🚨. For SRTCP, the pre-defined HMAC-SHA1 MUST NOT be applied with an n_tag or n_a smaller than these defaults. For SRTP, smaller values are NOT RECOMMENDED, but MAY be used after careful consideration of the issues in Sections 7.5 and 9.5 🙈.
5.3. Key Derivation: AES-CM PRF 🗝️
The AES Counter Mode based key derivation and PRF defined in Sections 4.3.1 to 4.3.3, using a 128-bit master key, SHALL be the default method for generating session keys ✨. The default master salt length SHALL be 112 bits, and the default key-derivation rate SHALL be zero 🌸.
6. Adding SRTP Transforms 🧚
Section 4 gives examples of the level of detail needed to define transforms, so use it as your guide 📖. Whenever a new transform is added to SRTP, a companion standard track RFC MUST be written to exactly define how the new transform can be used with SRTP (and SRTCP) 📜. That companion RFC SHOULD avoid overlapping with the SRTP protocol document. Note, however, that it MAY be necessary to extend the SRTP or SRTCP cryptographic context definition with new parameters (including fixed or default values), add steps to the packet processing, or even add fields to the SRTP/SRTCP packets 🧩. The companion RFC SHALL explain any known issues regarding interactions between the transform and other aspects of SRTP ⚠️.
Each new transform document SHOULD specify its key attributes, e.g., the size of keys (minimum, maximum, recommended), the format of keys, the recommended/required processing of input keying material, requirements/recommendations on key lifetime, re-keying and key derivation, and whether sharing keys between SRTP and SRTCP is allowed or not, etc. 📝
An added message integrity transform SHOULD define a minimum acceptable key/tag size for SRTCP, equivalent in strength to the minimum values defined in Section 5.2 💪.
7. Rationale 🌈
This section explains the rationale behind several important features of SRTP 💖.
7.1. Key derivation ✨
Okay so key derivation is literally the MVP 🔑 bestie, up to six different keys are needed per crypto context 😭: SRTP and SRTCP encryption keys and salts, plus SRTP and SRTCP authentication keys. But they all come from ONE master key in a cryptographically secure way 🫶 So the key management protocol only has to exchange one master key (plus a master salt when it's needed), and SRTP itself derives all the session keys (via the first, mandatory application of the key derivation function). Iconic efficiency 💅
Multiple applications of the key derivation function are optional, but when you turn them on you get real security perks 🛡️ They stop an attacker from grabbing huge amounts of ciphertext made with one fixed session key. If someone collected a ton of ciphertext for a single session key, they could get a boost for certain attacks, and we don't want that 🙅♀️
Multiple applications also give backwards and forward security 🦋 A compromised session key doesn't compromise the other session keys derived from the same master key. So an attacker who recovers one session key still can't read messages protected under the previous and later session keys derived from that same master key. (Of course, a leaked master key reveals every session key derived from it. Not cute 💀)
Things get trickier with high-rate key refresh, especially in big multicast settings, so see Section 11 🌈
7.2. Salting key 🧂
The master salt keeps you safe from off-line key-collision attacks on the key derivation, which could otherwise shrink the effective key size [MF00]. Main character protection 👑
The derived session salting key, used for encryption, was introduced to protect against some attacks on additive stream ciphers, see Section 9.2. And putting the salt explicitly into the IV was picked because it's easier to build in hardware 🔧
7.3. Message Integrity from Universal Hashing 🎯
The keystream prefix defined in Section 4.1 leaves room for particular universal hash functions, which are good for message authentication in the Wegman-Carter paradigm [WC81]. These functions are provably secure, simple, and quick, and they're especially great for Digital Signal Processors and other processors with a fast multiply operation ⚡
Right now, the only authentication transform in SRTP is HMAC-SHA1. Future transforms, like the universal hash functions I just mentioned, MAY be added by following the guidelines in Section 6 🌸
7.4. Data Origin Authentication Considerations 🕵️
In pair-wise communications, integrity and data origin authentication come together 🫂 But in group scenarios, where members share the keys, the MAC tag only proves that a member of the group sent the packet. It does NOT stop one member from impersonating another 😬 Data origin authentication (DOA) for multicast and group RTP sessions is a hard problem that needs a solution. Some promising proposals are being explored [PCST1] [PCST2], but more work is needed before they can be rigorously specified. So SRTP data origin authentication in groups is for further study 📚
DOA can be done with signatures instead, but that has a big hit on bandwidth and processing time, so we don't offer this form of authentication in the pre-defined packet-integrity transform 🙈
Mixers and translators make it impossible to get data origin authentication if the RTP payload and/or RTP header gets manipulated. These middle entities also disrupt end-to-end confidentiality, because the IV formation depends on, e.g., RTP header preservation 🥲 A certain trust model may choose to trust mixers/translators to decrypt and re-encrypt the media. That would mean breaking end-to-end security, with the related security implications, so proceed with caution ⚠️
7.5. Short and Zero-length Message Authentication ⏱️
As shown in Figure 1, the authentication tag is RECOMMENDED in SRTP. A full 80-bit authentication tag SHOULD be used, but a shorter tag or even a zero-length tag (i.e., no message authentication) MAY be used under certain conditions, to support either of the following two application environments 🎀
- Strong authentication can be impractical where bandwidth preservation is imperative. The big example is wireless communication systems, where bandwidth is a scarce and expensive resource 📶 Studies have shown that for certain applications and link technologies, extra bytes can significantly decrease spectrum efficiency [SWO]. A lot of effort has gone into IP header compression to fix this [RFC3095]. A typical voice application produces 20 byte samples, and the RTP, UDP and IP headers need to be jointly compressed down to one or two bytes on average to get acceptable wireless bandwidth economy [RFC3095]. In this case, strong authentication would add nearly fifty percent overhead 😭
- Authentication is impractical for applications that use data links with fixed-width fields that can't fit the expansion from the authentication tag. This happens on some important existing wireless channels 📞 For example, zero-byte header compression is used to adapt EVRC/SMV voice to the legacy IS-95 bearer channel in CDMA2000 VoIP services. It turned out that not a single additional octet could be added to the data, which is why a zero-byte profile was created for ROHC [RFC3242] 🧚
A short tag is secure for a restricted set of applications. Take a voice telephony app, like a G.729 audio codec with a 20-millisecond packetization interval, protected by a 32-bit message authentication tag. The chance of any given packet being successfully forged is only one in 2^32. So, on average, an adversary can control no more than 20 milliseconds of audio output during a 994-day period 🤏 But the effect of a single forged packet can be much bigger if the application is stateful. A codec that uses relative or predictive compression across packets will spread the maliciously generated state, affecting a longer stretch of output 🙀
Not every SRTP or telephony application meets the criteria for short or zero-length authentication tags, so be careful 🫣 Section 9.5.1 discusses the risks of weak or no message authentication, and section 9.5 describes when it's acceptable and when it's unacceptable.
8. Key Management Considerations 🗝️
There are emerging key management standards [MIKEY] [KEYMGT] [SDMS] for establishing an SRTP cryptographic context (e.g., an SRTP master key). Both proprietary and open-standard key management methods are likely to be used for telephony applications [MIKEY] [KINK] and multicast applications [GDOI]. This section gives guidance for key management systems that service an SRTP session 💜
For initialization, an interoperable SRTP implementation SHOULD be given the SSRC, and MAY be given the initial RTP sequence number for the RTP stream by key management. (So key management has a dependency on RTP operational parameters, bestie 🤓) Sending the RTP sequence number in key management may be useful, e.g., when the initial sequence number is close to wrapping (to avoid synchronization problems), and to communicate the current sequence number to a joining endpoint (so it can properly initialize its replay list) 🔁
If the pre-defined transforms are used, SRTP allows sharing the same master key between SRTP/SRTCP streams that belong to the same RTP session 🫶
First, sharing between SRTP streams in the same RTP session is secure if the design of the synchronization mechanism (the IV) avoids keystream re-use, which is the two-time pad, see Section 9.1. This is taken care of by the fact that RTP provides unique SSRCs for streams in the same RTP session. See Section 9.1 for more on this 🙌
Second, sharing between SRTP and the corresponding SRTCP is secure. The fact that an SRTP stream and its associated SRTCP stream both carry the same SSRC does not cause a problem for the two-time pad, thanks to the key derivation. So SRTP and SRTCP for one RTP session MAY share master keys (as they do by default) ✨
Message authentication also depends on SSRC uniqueness, which is a separate issue from keystream reuse 👀 SRTP streams authenticated under the same key MUST have a distinct SSRC in order to identify the sender of the message. This is needed because the SSRC is the cryptographically authenticated field used to tell different SRTP streams apart. If two streams used identical SSRC values, an adversary could substitute messages from one stream into the other without being detected 😱
SRTP/SRTCP MUST NOT share master keys under any other circumstances than the ones above, i.e., between SRTP and its corresponding SRTCP, and between streams belonging to the same RTP session 🚫
8.1. Re-keying 🔄
The recommended way for a particular key management system to provide re-key within SRTP is to associate a master key in a crypto context with an MKI 🏷️
This gives easy master key retrieval (see Scenarios in Section 11), but has the disadvantage of adding extra bits to each packet. As noted in Section 7.5, some wireless links don't cater for added bits. So SRTP also defines a more economic way of triggering re-keying, via use of <From, To>, which works in some specific, simple scenarios (see Section 8.1.1) 💅
SRTP senders SHALL count the amount of SRTP and SRTCP traffic being used for a master key, and invoke key management to re-key if needed (Section 9.2). These interactions are defined by the key management interface to SRTP and are NOT defined by this protocol specification, so that's a key management problem, not ours 🌷
8.1.1. Use of the <From, To> for re-keying ✨
Okay so, besides the MKI, SRTP has another optional way to retrieve master keys, called the <From, To> 🎀. The <From, To> gives a range of SRTP indices (a pair of sequence number and ROC) saying when a certain master key is valid, and when it's used it's part of the crypto context 💅. Look at the 48-bit SRTP index of the current packet and you can work out which From-To interval it falls into, and that tells you the master key 🔑. For SRTCP, the most recently observed/used SRTP index is used for this instead (you can grab it from the cryptographic context), even though SRTCP has its own (31-bit) index (see caveat below) 🧚.
This method, compared to the MKI, is a big win because it identifies the master key and sets its lifetime without adding extra bits to every packet 🦋. As already noted, that's useful for some wireless links that don't cater for added bits 📶. However, its use SHOULD be limited to specific, very simple scenarios. We recommend to limit its use when the RTP session is a simple unidirectional or bi-directional stream. Why? Because with multiple streams it gets messy 🙈. It's hard to trigger a re-key based on the <From, To> of a single RTP stream. For example, if several streams share a master key, there's no simple one-to-one match between the index sequence space of a certain stream and the index sequence space the <From, To> values are based on. So when a master key is shared between streams, one of those streams MUST be designated by key management as the one whose index space defines the re-keying points 👑. Also, re-key triggering on SRTCP is based on the matching SRTP stream, meaning when the SRTP stream changes the master key, so does the matching SRTCP. This becomes obviously more and more complex with multiple streams 😭.
The default values for the <From, To> are "from the first observed packet" and "until further notice" 💜. However, the maximum limit of SRTP/SRTCP packets that are sent under each given master/session key (Section 9.2) MUST NOT be exceeded 🚫.
If the <From, To> is used for key retrieval, then the MKI is not inserted in the packet (and its indicator in the crypto context is zero) 🍓. However, using the MKI doesn't rule out using the <From, To> key lifetime at the same time. For instance, this can be handy for signalling at the sender side at which point in time an MKI is to be made active ⏰.
8.2. Key Management parameters 📋
The table below lists all the SRTP parameters that key management can supply 🎀. For reference, it also gives a summary of the default and mandatory-to-support values for an SRTP implementation, as described in Section 5 💖.
Parameter Mandatory-to-support Default
--------- -------------------- -------
SRTP and SRTCP encr transf. AES_CM, NULL AES_CM
(Other possible values: AES_f8)
SRTP and SRTCP auth transf. HMAC-SHA1 HMAC-SHA1
SRTP and SRTCP auth params:
n_tag (tag length) 80 80
SRTP prefix_length 0 0
Key derivation PRF AES_CM AES_CM
Key material params
(for each master key):
master key length 128 128
n_e (encr session key length) 128 128
n_a (auth session key length) 160 160
master salt key
length of the master salt 112 112
n_s (session salt key length) 112 112
key derivation rate 0 0
key lifetime
SRTP-packets-max-lifetime 2^48 2^48
SRTCP-packets-max-lifetime 2^31 2^31
from-to-lifetime <From, To>
MKI indicator 0 0
length of the MKI 0 0
value of the MKI
Crypto context index params:
SSRC value
ROC
SEQ
SRTCP Index
Transport address
Port number
Relation to other RTP profiles:
sender's order between FEC and SRTP FEC-SRTP FEC-SRTP
(see Section 10)9. Security Considerations 🔐
9.1. SSRC collision and two-time pad 💀
Any fixed keystream output, generated from the same key and index, MUST only be used to encrypt once. Re-using that keystream (jokingly called a "two-time pad" system by cryptographers) can seriously compromise security 😱. The NSA's VENONA project [C99] is a historical example of exactly that kind of compromise 🕵️. It is REQUIRED that automatic key management be used for establishing and maintaining SRTP and SRTCP keying material 🤖. This requirement exists to avoid keystream reuse, which is more likely to happen with manual key management. Furthermore, in SRTP, a "two-time pad" is avoided by requiring the key, or some other parameter of cryptographic significance, to be unique per RTP/RTCP stream and packet ✨. The pre-defined SRTP transforms get packet-uniqueness by including the packet index, and stream-uniqueness by including the SSRC 🦋.
The pre-defined transforms (AES-CM and AES-f8) let master keys be shared across streams belonging to the same RTP session, through the inclusion of the SSRC in the IV 🎀. A master key MUST NOT be shared among different RTP sessions 🚫.
So the SSRC MUST be unique between all the RTP streams within the same RTP session that share the same master key 🫶. RTP itself has an algorithm for detecting SSRC collisions within the same RTP session. But temporary collisions could lead to a temporary two-time pad, in the unfortunate event that SSRCs collide at a moment when the streams also have identical sequence numbers (which happens with probability roughly 2^(-48)) 😬. That's why the key management SHOULD take care of avoiding such SSRC collisions, by including the SSRCs to be used in the session as negotiation parameters and proactively making sure they're unique 🧠. This is a strong requirement in scenarios where, for example, there are multiple senders that can start transmitting at the same time, before SSRC collisions are detected at the RTP level 🚨.
Note also that even with distinct SSRCs, extensive use of the same key might improve the chances of probabilistic collision and time-memory-tradeoff attacks succeeding 🙀.
As described, master keys MAY be shared between streams belonging to the same RTP session, but it is RECOMMENDED that each SSRC have its own master key 🌸. When master keys are shared among SSRC participants, and SSRCs are managed by a key management module as recommended above, the RECOMMENDED policy for an SSRC collision error is for the participant to leave the SRTP session, because it's a sign of malfunction 🚪💅.
9.2. Key Usage 🔑
okay so the effective key size is determined (upper bounded) by the size of the master key and, for encryption, the size of the salting key 💅 Any additive stream cipher is vulnerable to attacks that use statistical knowledge about the plaintext source to enable key collision and time-memory tradeoff attacks [MF00] [H80] [BS00]. These attacks take advantage of commonalities among plaintexts, and give a cryptanalyst a way to amortize the computational effort of decryption over many keys, or over many bytes of output, which lowers the effective key size of the cipher 😭 A detailed analysis of these attacks and their applicability to the encryption of Internet traffic is provided in [MF00]. In summary, the effective key size of SRTP when used in a security system in which m distinct keys are used, is equal to the key size of the cipher less the logarithm (base two) of m.
Protection against these attacks can be provided simply by increasing the size of the keys used, and here that can be done with the salting key 🧂 Note that the salting key MUST be random but MAY be public. A salt size of (the suggested) size 112 bits protects against attacks in scenarios where at most 2^112 keys are in use. This is sufficient for all practical purposes ✨
Implementations SHOULD use keys that are as large as possible. Please note that in many cases increasing the key size of a cipher does not affect the throughput of that cipher 🌸
The use of the SRTP and SRTCP indices in the pre-defined transforms fixes the maximum number of packets that can be secured with the same key. This limit is fixed to 2^48 SRTP packets for an SRTP stream, and 2^31 SRTCP packets, when SRTP and SRTCP are considered independently. Due to for example re-keying, reaching this limit may or may not coincide with wrapping of the indices, and thus the sender MUST keep packet counts 🧮 However, when the session keys for related SRTP and SRTCP streams are derived from the same master key (the default behavior, Section 4.3), the upper bound that has to be considered is in practice the minimum of the two quantities. That is, when 2^48 SRTP packets or 2^31 SRTCP packets have been secured with the same key (whichever occurs before), the key management MUST be called to provide new master key(s) (previously stored and used keys MUST NOT be used again), or the session MUST be terminated. If a sender of RTCP discovers that the sender of SRTP (or SRTCP) has not updated the master or session key prior to sending 2^48 SRTP (or 2^31 SRTCP) packets belonging to the same SRTP (SRTCP) stream, it is up to the security policy of the RTCP sender how to behave, e.g., whether an RTCP BYE-packet should be sent and/or if the event should be logged 👀
Note: in most typical applications (assuming at least one RTCP packet for every 128,000 RTP packets), it will be the SRTCP index that first reaches the upper limit, although the time until this occurs is very long: even at 200 SRTCP packets/sec, the 2^31 index space of SRTCP is enough to secure approximately 4 months of communication 🕰️
Note that if the master key is to be shared between SRTP streams within the same RTP session (Section 9.1), although the above bounds are on a per stream (i.e., per SSRC) basis, the sender MUST base re-key decision on the stream whose sequence number space is the first to be exhausted 🎀
Key derivation limits the amount of plaintext that is encrypted with a fixed session key, and made available to an attacker for analysis, but key derivation does not extend the master key's lifetime. To see this, simply consider our requirements to avoid two-time pad: two distinct packets MUST either be processed with distinct IVs, or with distinct session keys, and both the distinctness of IV and of the session keys are (for the pre-defined transforms) dependent on the distinctness of the packet indices. Ngl this is the part that's most important, so pay attention bestie 🫶
Note that with the key derivation, the effective key size is at most that of the master key, even if the derived session key is considerably longer. With the pre-defined authentication transform, the session authentication key is 160 bits, but the master key by default is only 128 bits. This design choice was made to comply with certain recommendations in [RFC2104] so that an existing HMAC implementation can be plugged into SRTP without problems. Since the default tag size is 80 bits, it is, for the applications in mind, also considered acceptable from security point of view. Users having concerns about this are RECOMMENDED to instead use a 192 bit master key in the key derivation. It was, however, chosen not to mandate 192-bit keys since existing AES implementations to be used in the key-derivation may not always support key-lengths other than 128 bits. Since AES is not defined (or properly analyzed) for use with 160 bit keys it is NOT RECOMMENDED that ad-hoc key-padding schemes are used to pad shorter keys to 192 or 256 bits 🙅♀️
9.3. Confidentiality of the RTP Payload 🤫
SRTP's pre-defined ciphers are "seekable" stream ciphers, i.e., ciphers able to efficiently seek to arbitrary locations in their keystream (so that the encryption or decryption of one packet does not depend on preceding packets). By using seekable stream ciphers, SRTP avoids the denial of service attacks that are possible on stream ciphers that lack this property 🙌 It is important to be aware that, as with any stream cipher, the exact length of the payload is revealed by the encryption. This means that it may be possible to deduce certain "formatting bits" of the payload, as the length of the codec output might vary due to certain parameter settings etc. This, in turn, implies that the corresponding bit of the keystream can be deduced. However, if the stream cipher is secure (counter mode and f8 are provably secure under certain assumptions [BDJR] [KSYH] [IK]), knowledge of a few bits of the keystream will not aid an attacker in predicting subsequent keystream bits. Thus, the payload length (and information deducible from this) will leak, but nothing else 🧐
As some RTP packet could contain highly predictable data, e.g., SID, it is important to use a cipher designed to resist known plaintext attacks (which is the current practice) 🔐
9.4. Confidentiality of the RTP Header 👀
In SRTP, RTP headers are sent in the clear to allow for header compression. This means that data such as payload type, synchronization source identifier, and timestamp are available to an eavesdropper. Moreover, since RTP allows for future extensions of headers, we cannot foresee what kind of possibly sensitive information might also be "leaked" 😬
SRTP is a low-cost method, which allows header compression to reduce bandwidth. It is up to the endpoints' policies to decide about the security protocol to employ. If one really needs to protect headers, and is allowed to do so by the surrounding environment, then one should also look at alternatives, e.g., IPsec [RFC2401] 🛡️
9.5. Integrity of the RTP payload and header 🧾
SRTP messages are subject to attacks on their integrity and source identification, and these risks are discussed in Section 9.5.1. To protect against these attacks, each SRTP stream SHOULD be protected by HMAC-SHA1 [RFC2104] with an 80-bit output tag and a 160-bit key, or a message authentication code with equivalent strength. Secure RTP SHOULD NOT be used without message authentication, except under the circumstances described in this section. It is important to note that encryption algorithms, including AES Counter Mode and f8, do not provide message authentication. SRTCP MUST NOT be used with weak (or NULL) authentication 🚨
SRTP MAY be used with weak authentication (e.g., a 32-bit authentication tag), or with no authentication (the NULL authentication algorithm). These options allow SRTP to be used to provide confidentiality in situations where:
- weak or null authentication is an acceptable security risk, and
- it is impractical to provide strong message authentication.
These conditions are described below and in Section 7.5. Note that both conditions MUST hold in order for weak or null authentication to be used. The risks associated with exercising the weak or null authentication options need to be considered by a security audit prior to their use for a particular application or environment given the risks, which are discussed in Section 9.5.1 📋
Weak authentication is acceptable when the RTP application is such that the effect of a small fraction of successful forgeries is negligible. If the application is stateless, then the effect of a single forged RTP packet is limited to the decoding of that particular packet. Under this condition, the size of the authentication tag MUST ensure that only a negligible fraction of the packets passed to the RTP application by the SRTP receiver can be forgeries. This fraction is negligible when an adversary, if given control of the forged packets, is not able to make a significant impact on the output of the RTP application (see the example of Section 7.5) 🧠
Weak or null authentication MAY be acceptable when it is unlikely that an adversary can modify ciphertext so that it decrypts to an intelligible value. One important case is when it is difficult for an adversary to acquire the RTP plaintext data, since for many codecs, an adversary that does not know the input signal cannot manipulate the output signal in a controlled way. In many cases it may be difficult for the adversary to determine the actual value of the plaintext. For example, a hidden snooping device might be required in order to know a live audio or video signal. The adversary's signal must have a quality equivalent to or greater than that of the signal under attack, since otherwise the adversary would not have enough information to encode that signal with the codec used by the victim. Plaintext prediction may also be especially difficult for an interactive application such as a telephone call 📞
Weak or null authentication MUST NOT be used when the RTP application makes data forwarding or access control decisions based on the RTP data. In such a case, an attacker may be able to subvert confidentiality by causing the receiver to forward data to an attacker. See Section 3 of [B96] for a real-life example of such attacks 🚫
Null authentication MUST NOT be used when a replay attack, in which an adversary stores packets then replays them later in the session, could have a non-negligible impact on the receiver. An example of a successful replay attack is the storing of the output of a surveillance camera for a period of time, later followed by the injection of that output to the monitoring station to avoid surveillance. Encryption does not protect against this attack, and non-null authentication is REQUIRED in order to defeat it 🎥
If existential message forgery is an issue, i.e., when the accuracy of the received data is of non-negligible importance, null authentication MUST NOT be used 💀
9.5.1. Risks of Weak or Null Message Authentication 💀
Okay bestie, this is the scary part 😭 When you're doing a security audit and thinking about weak or null authentication, you have to keep these attacks in mind, because they're totally possible when no message authentication algorithm is used 🙈
An attacker who can't predict the plaintext is still always able to change the message sent between the sender and the receiver so that it decrypts to a random plaintext value, or send a stream of bogus packets to the receiver that decrypt to random plaintext values. This is basically a denial of service attack 🥀. Without message authentication, though, the RTP application gets inputs that are bit-wise correlated with the true value. Some multimedia codecs and common operating systems will crash when that junk gets accepted as valid video data. 💀 This DoS attack may be a much larger threat than an attacker just dropping, delaying, or re-ordering packets.
An attacker who can't predict the plaintext can still replay a previous message with certainty that the receiver will accept it. Apps with stateless codecs might be robust against this kind of attack 🦋 But for other, more complex applications, these attacks may be far more grave 😬
An attacker who can predict the plaintext can modify the ciphertext so that it decrypts to any value of her choosing. With an additive stream cipher, an attacker will always be able to change individual bits 🎀
An attacker may also be able to subvert confidentiality when the lack of authentication lets a data forwarding or access control decision get made on decrypted but unauthenticated plaintext. The receiver could be fooled into forwarding data to an attacker, which is an indirect breach of confidentiality (see Section 3 of [B96]). That's because data-forwarding decisions are made on the decrypted plaintext. The info in the plaintext decides which subnet (or process) the plaintext gets forwarded to in ESP [RFC2401] tunnel mode (or transport mode, respectively) 🧠 When Secure RTP is used without message authentication, it should be verified that the application does not make data forwarding or access control decisions based on the decrypted plaintext ✨
Some cipher modes of operation that require padding, e.g., standard cipher block chaining (CBC), are very sensitive to attacks on confidentiality if certain padding types are used without integrity. The attack [V02] shows this is indeed the case for the standard RTP padding discussed in reference to Figure 1, when it's used together with CBC mode. Later transform additions to SRTP MUST therefore carefully consider the risk of using this padding without proper integrity protection. 🚨
9.5.2. Implicit Header Authentication 🫶
The IV formation of the f8-mode gives implicit authentication (IHA) of the RTP header, even when message authentication is not used. When IHA is used, an attacker who modifies the value of the RTP header will cause the decryption process at the receiver to produce random plaintext values. This protection isn't equivalent to message authentication, but it may be useful for some applications 💜
10. Interaction with Forward Error Correction mechanisms 🌈
The default processing when using Forward Error Correction (e.g., RFC 2733) with SRTP SHALL be to perform FEC processing prior to SRTP processing on the sender side, and to perform SRTP processing prior to FEC processing on the receiver side. Any change to this ordering (reversing it, or placing FEC between SRTP encryption and SRTP authentication) SHALL be signaled out of band 📡
11. Scenarios 🧚
SRTP can be used as a security protocol for RTP/RTCP traffic in many different scenarios. It has a number of configuration options, especially around key usage, and those can affect the total performance of the application depending on how it's used. So the use of SRTP really depends on the kind of scenario and application it's used with. Below, we briefly go through some use cases for SRTP and give some guidelines for recommended settings of its options 💅
11.1. Unicast 🎀
A typical example would be a voice call or a video-on-demand application.
Consider one bi-directional RTP stream as one RTP session. It's possible for the two parties to share the same master key in both directions, following the principles of Section 9.1. The first round of key derivation splits the master key into any or all of the following session keys (depending on the security functions provided): SRTP_encr_key, SRTP_auth_key, SRTCP_encr_key, and SRTCP_auth key.
(For simplicity, we skip the salts, which are also derived.) In this scenario, it will in most cases be enough to have a single master key with the default lifetime. That guarantees a sufficiently long lifetime for the keys and a minimum set of keys in place for most practical purposes 🔑 Also, in this case RTCP protection can be applied smoothly. Under these assumptions, the MKI can be omitted. Since key derivation combined with a large difference in packet rate between the two directions may require storing several session keys at once, if storage is an issue, we recommended using low-rate key derivation 🍓
The same considerations extend to the unicast scenario with multiple RTP sessions, where each session has a distinct master key 🦋
11.2. Multicast (one sender) 📣
Just like with (unprotected) RTP, a scalability issue shows up in big groups, because the sender might have to process a very large number of SRTCP Receiver Reports. In SRTP, the sender may have to keep state (the cryptographic context) for each receiver, or more precisely, for the SRTCP used to protect Receiver Reports. The overhead grows in proportion to the size of the group. Re-keying in particular needs special concern, see below 👀
Let's start with a small group of receivers. There are a few possible setups for distributing master keys among the receivers. With a single RTP session, one possibility is that the receivers share the same master key (as per Section 9.1) to secure all of their RTCP traffic. This shared master key could be the same one the sender uses to protect its outbound SRTP traffic. Alternatively, it could be a master key shared only among the receivers and used solely for their SRTCP traffic. Both alternatives require the receivers to trust each other 🫂
When it comes to SRTCP and key storage, it is recommended to use low-rate (or zero) key_derivation (except for the mandatory initial one), so the sender doesn't need to store too many session keys. Each SRTCP stream might otherwise have a different session key at any given moment, since the SRTCP sources send at different times 😵💫 So if key derivation is wanted for SRTP, the cryptographic context for SRTP can be kept separate from the SRTCP crypto context. That makes it possible to have a key_derivation_rate of 0 for SRTCP and a non-zero value for SRTP ✨
Use of the MKI for re-keying is RECOMMENDED for most applications (see Section 8.1).
If more than one SRTP/SRTCP stream (within the same RTP session) shares the master key, the upper limit of 2^48 SRTP packets / 2^31 SRTCP packets means that, before one of the streams reaches its maximum number of packets, re-keying MUST be triggered on ALL streams sharing the master key. (From a strict security point of view, only the stream reaching the maximum would need to be re-keyed, but then the streams would no longer be sharing a master key, which is the whole point.) A local policy at the sender side should force re-keying so the maximum packet limit is never reached on any of the streams. Use of the MKI for re-keying is RECOMMENDED 🙌
In large multicast with one sender, the same considerations as for small-group multicast still hold. The biggest issue here is the extra load on the sender side, because it has to maintain state (cryptographic contexts) for each receiver that's sending back RTCP Receiver Reports. At minimum, a replay window might need to be maintained for each RTCP source 🥺
11.3. Re-keying and access control 🔐
Re-keying may happen because of access control (e.g., when a member gets removed during a multicast RTP session), or for pure cryptographic reasons (e.g., the key is at the end of its lifetime). When using SRTP default transforms, the master key MUST be replaced before any of the index spaces are exhausted for any of the streams protected by that same master key 🚫
How key management re-keys SRTP implementations is out of scope, but it's clear there are straightforward ways to manage keys for a multicast group. In one-sender multicast, for example, it's typically the sender's job to decide when a new key is needed. The sender is the one entity that can keep track of how many packets have been sent, since receivers may join and leave the session at any time, and there may be packet loss and delay, etc. In scenarios other than one-sender multicast, other methods can be used. Here, you have to keep in mind that key exchange can be a costly operation, taking several seconds for a single exchange 🐌 So some time before the master key is exhausted or expires, out-of-band key management gets started, resulting in a new master key shared with the receiver(s). In any event, to keep things in sync when switching to the new key, group policy might choose between using the MKI and the <From, To>, as described in Section 8.1 🧩
For access control purposes, the <From, To> periods are set at the desired granularity, depending on the packet rate. High-rate re-keying can be problematic for SRTCP in some large-group scenarios. As mentioned, there are potential problems with using the SRTP index, rather than the SRTCP index, for determining the master key. In particular, for short periods while master keys are switching, SRTCP packets may not be under the current master key of the correspondent SRTP. So using the MKI for re-keying in scenarios like this will produce better results 🌸
11.4. Summary of basic scenarios 📝
The description of these scenarios highlights some recommendations on the use of SRTP, mainly related to re-keying and large-scale multicast:
- Do not use fast re-keying with the
<From, To>feature. It may, in particular, cause problems retrieving the correct SRTCP key if an SRTCP packet arrives close to the re-keying time. The MKI SHOULD be used in this case 🚀 - If multiple SRTP streams in the same RTP session share the same master key, moderate-rate re-keying MAY also have the same problems, and the MKI SHOULD be used.
- Though offering increased security, a non-zero key_derivation_rate is NOT RECOMMENDED when trying to minimize the number of keys in use with multiple streams. 💖
12. IANA Considerations ✨
Okay so IANA stuff, bestie 🧚. The RTP spec has a registry of profile names that higher-level control protocols (like SDP) use to refer to transport methods, and this profile registers the name "RTP/SAVP" 💖.
SRTP uses cryptographic transforms, and a key management protocol is the one that signals them 🔐. So it's each key management protocol's job to register its transforms or suites of transforms with IANA. The key management protocol is the one that carries those protocol numbers, not SRTP, and each one picks its own numbering scheme and syntax 💅.
Specifying a key management protocol for SRTP is out of scope here 🙈. Section 8.2 does give guidance on the parameters that need to be defined for the default and mandatory transforms, though, so go check that out 🎀.
13. Acknowledgements
🫶 David Oran (Cisco) and Rolf Blom (Ericsson) are co-authors of this document, but their valuable contributions get a shoutout here so the author list doesn't get too long 😭.
The authors also want to thank Magnus Westerlund, Brian Weis, Ghyslain Pelletier, Morgan Lindqvist, Robert Fairlie-Cuninghame, Adrian Perrig, the AVT WG, and especially the chairmen Colin Perkins and Stephen Casner 👑. They also thank the Transport and Security Area Directors and Eric Rescorla for their reviews and support 🌸.
14. References
14.1. Normative References
[AES] NIST, "Advanced Encryption Standard (AES)", FIPS PUB 197, http://www.nist.gov/aes/
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for Internet Protocol", RFC 2401, November 1998.
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-time Applications", RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.
14.2. Informative References
[AES-CTR] Lipmaa, H., Rogaway, P. and D. Wagner, "CTR-Mode Encryption", NIST, http://csrc.nist.gov/encryption/modes/workshop1/papers/lipmaa-ctr.pdf
[B96] Bellovin, S., "Problem Areas for the IP Security Protocols," in Proceedings of the Sixth Usenix Unix Security Symposium, pp. 1-16, San Jose, CA, July 1996 (http://www.research.att.com/~smb/papers/index.html).
[BDJR] Bellare, M., Desai, A., Jokipii, E. and P. Rogaway, "A Concrete Treatment of Symmetric Encryption: Analysis of DES Modes of Operation", Proceedings 38th IEEE FOCS, pp. 394-403, 1997.
[BS00] Biryukov, A. and A. Shamir, "Cryptanalytic Time/Memory/Data Tradeoffs for Stream Ciphers", Proceedings, ASIACRYPT 2000, LNCS 1976, pp. 1-13, Springer Verlag.
[C99] Crowell, W. P., "Introduction to the VENONA Project", http://www.nsa.gov:8080/docs/venona/index.html.
[CTR] Dworkin, M., NIST Special Publication 800-38A, "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", 2001. http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf.
[f8-a] 3GPP TS 35.201 V4.1.0 (2001-12) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Specification of the 3GPP Confidentiality and Integrity Algorithms; Document 1: f8 and f9 Specification (Release 4).
[f8-b] 3GPP TR 33.908 V4.0.0 (2001-09) Technical Report 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; General Report on the Design, Specification and Evaluation of 3GPP Standard Confidentiality and Integrity Algorithms (Release 4).
[GDOI] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The Group Domain of Interpretation, RFC 3547, July 2003.
[HAC] Menezes, A., Van Oorschot, P. and S. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1997, ISBN 0-8493-8523-7.
[H80] Hellman, M. E., "A cryptanalytic time-memory trade-off", IEEE Transactions on Information Theory, July 1980, pp. 401-406.
[IK] T. Iwata and T. Kohno: "New Security Proofs for the 3GPP Confidentiality and Integrity Algorithms", Proceedings of FSE 2004.
[KINK] Thomas, M. and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", Work in Progress.
[KEYMGT] Arrko, J., et al., "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", Work in Progress.
[KSYH] Kang, J-S., Shin, S-U., Hong, D. and O. Yi, "Provable Security of KASUMI and 3GPP Encryption Mode f8", Proceedings Asiacrypt 2001, Springer Verlag LNCS 2248, pp. 255-271, 2001.
[MIKEY] Arrko, J., et. al., "MIKEY: Multimedia Internet KEYing", Work in Progress.
[MF00] McGrew, D. and S. Fluhrer, "Attacks on Encryption of Redundant Plaintext and Implications on Internet Security", the Proceedings of the Seventh Annual Workshop on Selected Areas in Cryptography (SAC 2000), Springer-Verlag.
[PCST1] Perrig, A., Canetti, R., Tygar, D. and D. Song, "Efficient and Secure Source Authentication for Multicast", in Proc. of Network and Distributed System Security Symposium NDSS 2001, pp. 35-46, 2001.
[PCST2] Perrig, A., Canetti, R., Tygar, D. and D. Song, "Efficient Authentication and Signing of Multicast Streams over Lossy Channels", in Proc. of IEEE Security and Privacy Symposium S&P2000, pp. 56-73, 2000.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC2675] Borman, D., Deering, S. and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukuhsima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression: Framework and Four Profiles: RTP, UDP, ESP, and uncompressed (ROHC)", RFC 3095, July 2001.
[RFC3242] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP ", RFC 3242, April 2002.
[SDMS] Andreasen, F., Baugher, M. and D. Wing, "Session Description Protocol Security Descriptions for Media Streams", Work in Progress.
[SWO] Svanbro, K., Wiorek, J. and B. Olin, "Voice-over-IP-over-wireless", Proc. PIMRC 2000, London, Sept. 2000.
[V02] Vaudenay, S., "Security Flaws Induced by CBC Padding - Application to SSL, IPsec, WTLS...", Advances in Cryptology, EUROCRYPT'02, LNCS 2332, pp. 534-545.
[WC81] Wegman, M. N., and J.L. Carter, "New Hash Functions and Their Use in Authentication and Set Equality", JCSS 22, 265-279, 1981.
Appendix A: Pseudocode for Index Determination 🧮
The following is an example of pseudo-code for the algorithm to determine the index i of an SRTP packet with sequence number SEQ. In the following, signed arithmetic is assumed.
if (s_l < 32,768)
if (SEQ - s_l > 32,768)
set v to (ROC-1) mod 2^32
else
set v to ROC
endif
else
if (s_l - 32,768 > SEQ)
set v to (ROC+1) mod 2^32
else
set v to ROC
endif
endif
return SEQ + v*65,536Appendix B: Test Vectors 🍓
All values are in hexadecimal. 💜
B.1. AES-f8 Test Vectors
SRTP PREFIX LENGTH : 0
RTP packet header : 806e5cba50681de55c621599
RTP packet payload : 70736575646f72616e646f6d6e657373
20697320746865206e65787420626573
74207468696e67
ROC : d462564a
key : 234829008467be186c3de14aae72d62c
salt key : 32f2870d
key-mask (m) : 32f2870d555555555555555555555555
key XOR key-mask : 11baae0dd132eb4d3968b41ffb278379
IV : 006e5cba50681de55c621599d462564a
IV' : 595b699bbd3bc0df26062093c1ad8f73
j = 0
IV' xor j : 595b699bbd3bc0df26062093c1ad8f73
S(-1) : 00000000000000000000000000000000
IV' xor S(-1) xor j : 595b699bbd3bc0df26062093c1ad8f73
S(0) : 71ef82d70a172660240709c7fbb19d8e
plaintext : 70736575646f72616e646f6d6e657373
ciphertext : 019ce7a26e7854014a6366aa95d4eefd
j = 1
IV' xor j : 595b699bbd3bc0df26062093c1ad8f72
S(0) : 71ef82d70a172660240709c7fbb19d8e
IV' xor S(0) xor j : 28b4eb4cb72ce6bf020129543a1c12fc
S(1) : 3abd640a60919fd43bd289a09649b5fc
plaintext : 20697320746865206e65787420626573
ciphertext : 1ad4172a14f9faf455b7f1d4b62bd08f
j = 2
IV' xor j : 595b699bbd3bc0df26062093c1ad8f71
S(1) : 3abd640a60919fd43bd289a09649b5fc
IV' xor S(1) xor j : 63e60d91ddaa5f0b1dd4a93357e43a8d
S(2) : 220c7a8715266565b09ecc8a2a62b11b
plaintext : 74207468696e67
ciphertext : 562c0eef7c4802B.2. AES-CM Test Vectors
Keystream segment length: 1044512 octets (65282 AES blocks)
Session Key: 2B7E151628AED2A6ABF7158809CF4F3C
Rollover Counter: 00000000
Sequence Number: 0000
SSRC: 00000000
Session Salt: F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000 (already shifted)
Offset: F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000
Counter Keystream
F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000 E03EAD0935C95E80E166B16DD92B4EB4
F0F1F2F3F4F5F6F7F8F9FAFBFCFD0001 D23513162B02D0F72A43A2FE4A5F97AB
F0F1F2F3F4F5F6F7F8F9FAFBFCFD0002 41E95B3BB0A2E8DD477901E4FCA894C0
... ...
F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF EC8CDF7398607CB0F2D21675EA9EA1E4
F0F1F2F3F4F5F6F7F8F9FAFBFCFDFF00 362B7C3C6773516318A077D7FC5073AE
F0F1F2F3F4F5F6F7F8F9FAFBFCFDFF01 6A2CC3787889374FBEB4C81B17BA6C44Nota Bene: this test case is contrived so that the latter part of the keystream segment coincides with the test case in Section F.5.1 of [CTR]. 🧁
B.3. Key Derivation Test Vectors ✨
okay bestie, this is the good stuff 🦋 this part shows the default key derivation function working on real numbers, so you can check your own implementation. It uses AES-128 in Counter Mode 💅 The setup is a 16 octet session encryption key and a 14 octet session salt for the cipher, plus a 94-octet session authentication key for the auth function. We call those the cipher key, the cipher salt, and the auth key. This is the initial key derivation and the key derivation rate is zero, so (index DIV key_derivation_rate) is zero. That's a six-octet string of zeros 🍓 From here on, key_derivation_rate gets shortened to kdr because we're efficient like that 🧚
Our inputs are the 16 octet master key and the 14 octet master salt:
master key: E1F97A0D3E018BE0D64FA32C06DE4139
master salt: 0EC675AD498AFEEBB6960B3AABE6Let's start with the cipher key 🔥 The AES-CM input block comes from XORing the master salt with the encryption key label 0x00 concatenated with (index DIV kdr). Then you pad on the right with two null octets, which is how you do the multiply-by-2^16 step (see Section 4.3.3). That value gets AES-CM encrypted using the master key, and boom, you have the cipher key.
index DIV kdr: 000000000000
label: 00
master salt: 0EC675AD498AFEEBB6960B3AABE6
-----------------------------------------------
xor: 0EC675AD498AFEEBB6960B3AABE6 (x, PRF input)
x*2^16: 0EC675AD498AFEEBB6960B3AABE60000 (AES-CM input)
cipher key: C61E7A93744F39EE10734AFE3FF7A087 (AES-CM output)Next up is the cipher salt 🌸 Same energy: the input block is the master salt XORed with the encryption salt label, then padded and encrypted just like before.
index DIV kdr: 000000000000
label: 02
master salt: 0EC675AD498AFEEBB6960B3AABE6
----------------------------------------------
xor: 0EC675AD498AFEE9B6960B3AABE6 (x, PRF input)
x*2^16: 0EC675AD498AFEE9B6960B3AABE60000 (AES-CM input)
30CBBC08863D8C85D49DB34A9AE17AC6 (AES-CM ouptut)
cipher salt: 30CBBC08863D8C85D49DB34A9AE1Now the auth key 🔐 It's built the same way, just with the authentication key label.
index DIV kdr: 000000000000
label: 01
master salt: 0EC675AD498AFEEBB6960B3AABE6
-----------------------------------------------
xor: 0EC675AD498AFEEAB6960B3AABE6 (x, PRF input)
x*2^16: 0EC675AD498AFEEAB6960B3AABE60000 (AES-CM input)Here's the full auth key, shown on the left, lined up with the AES input blocks on the right 👑
auth key AES input blocks
CEBE321F6FF7716B6FD4AB49AF256A15 0EC675AD498AFEEAB6960B3AABE60000
6D38BAA48F0A0ACF3C34E2359E6CDBCE 0EC675AD498AFEEAB6960B3AABE60001
E049646C43D9327AD175578EF7227098 0EC675AD498AFEEAB6960B3AABE60002
6371C10C9A369AC2F94A8C5FBCDDDC25 0EC675AD498AFEEAB6960B3AABE60003
6D6E919A48B610EF17C2041E47403576 0EC675AD498AFEEAB6960B3AABE60004
6B68642C59BBFC2F34DB60DBDFB2 0EC675AD498AFEEAB6960B3AABE60005Authors' Addresses 🎀
Questions and comments should go to the authors and avt@ietf.org, bestie. These are the people who built this 🫶
Mark Baugher
Cisco Systems, Inc.
5510 SW Orchid Street
Portland, OR 97219 USA
Phone: +1 408-853-4418
EMail: mbaugher@cisco.comElisabetta Carrara
Ericsson Research
SE-16480 Stockholm
Sweden
Phone: +46 8 50877040
EMail: elisabetta.carrara@ericsson.comDavid A. McGrew
Cisco Systems, Inc.
San Jose, CA 95134-1706
USA
Phone: +1 301-349-5815
EMail: mcgrew@cisco.comMats Naslund
Ericsson Research
SE-16480 Stockholm
Sweden
Phone: +46 8 58533739
EMail: mats.naslund@ericsson.comKarl Norrman
Ericsson Research
SE-16480 Stockholm
Sweden
Phone: +46 8 4044502
EMail: karl.norrman@ericsson.comFull Copyright Statement 💜
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth there, the authors keep all their rights.
This document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🌈
The IETF takes no position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope, or on whether any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to find such rights. Info on how rights work for RFC documents is in BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission for implementers or users to use such proprietary rights can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to implement this standard. Please send that info to the IETF at ietf-ipr@ietf.org.
Acknowledgement ⭐
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you to them, babe 🫶
📦 where this page comes from
- ietf: rfc3711 2004-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms