RFC 9335
Completely Encrypting RTP Header Extensions and Contributing Sources
RFC 9335: Completely Encrypting RTP Header Extensions and Contributing Sources 🎀
okay bestie, this one is a Standards Track doc from the IETF, dated January 2023 and published as ISSN 2070-1721 🦋. It's written by three people: J. Uberti, C. Jennings (both at Cisco), and S. Garcia Murillo (at Millicast). It updates RFC 3711, which is the SRTP spec, and the header doesn't list anything it obsoletes. So this is the RFC that adds new stuff onto SRTP, and it's called Cryptex 💜
Abstract ✨
okay so SRTP (the secure version of RTP, the protocol for real-time media) encrypts the actual media payload, but a bunch of metadata just sits there in plain text 👀 That includes RTP header extensions and CSRCs (contributing sources). ngl that data can be kind of sensitive in lots of apps. People tried to fix this before, but it never really caught on because it was complicated and had technical issues 💀
So this doc updates RFC 3711 and defines Cryptex, a new mechanism that fully encrypts header extensions and CSRCs. It also uses simpler SDP signaling so people actually deploy it 🫶
Status of This Memo 📜
This is an Internet Standards Track document 🔥
It's a product of the IETF, so it represents the consensus of the IETF community. It went through public review and got approved for publication by the IESG (Internet Engineering Steering Group). If you want more on Internet Standards, check out Section 2 of RFC 7841.
For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9335 🌸
Copyright Notice 💅
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Read them carefully, because they explain your rights and restrictions with respect to this document. If you pull Code Components out of this doc, they must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 📝
Table of Contents 🧚
1. Introduction
1.1. Problem Statement
1.2. Previous Solutions
1.3. Goals
2. Terminology
3. Design
4. SDP Considerations
5. RTP Header Processing
5.1. Sending
5.2. Receiving
6. Encryption and Decryption
6.1. Packet Structure
6.2. Encryption Procedure
6.3. Decryption Procedure
7. Backward Compatibility
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Test Vectors
A.1. AES-CTR
A.1.1. RTP Packet with One-Byte Header Extension
A.1.2. RTP Packet with Two-Byte Header Extension
A.1.3. RTP Packet with One-Byte Header Extension and CSRC
Fields
A.1.4. RTP Packet with Two-Byte Header Extension and CSRC
Fields
A.1.5. RTP Packet with Empty One-Byte Header Extension and
CSRC Fields
A.1.6. RTP Packet with Empty Two-Byte Header Extension and
CSRC Fields
A.2. AES-GCM
A.2.1. RTP Packet with One-Byte Header Extension
A.2.2. RTP Packet with Two-Byte Header Extension
A.2.3. RTP Packet with One-Byte Header Extension and CSRC
Fields
A.2.4. RTP Packet with Two-Byte Header Extension and CSRC
Fields
A.2.5. RTP Packet with Empty One-Byte Header Extension and
CSRC Fields
A.2.6. RTP Packet with Empty Two-Byte Header Extension and
CSRC Fields
Acknowledgements
Authors' Addresses1. Introduction ✨
1.1. Problem Statement 🔍
okay so SRTP [RFC3711] gives you message authentication for the whole RTP packet, but it only encrypts the RTP payload. Historically that was fine, because most of what's in the header isn't very sensitive (the RTP timestamp, for example). Some fields also have to stay in cleartext because they're used for key scheduling, like the RTP synchronization source (SSRC) and the sequence number 🧠
BUT, as [RFC6904] points out, header extensions can have different security needs. That includes the per-packet sound levels from [RFC6464] and [RFC6465], which those RFCs themselves call out as sensitive in their Security Considerations sections 👀
And it's not just the extension contents. There are now so many header extensions in active use that the extension identifiers alone can tell someone which endpoint or app they're looking at. So those identifiers count as a fingerprinting issue 🫣
Last one: CSRCs in RTP packets can be sensitive too. A network eavesdropper could figure out who was talking and when during an otherwise secure conference call 🙈
1.2. Previous Solutions 🕰️
So [RFC6904], Encryption of Header Extensions in SRTP, was proposed back in 2013 to fix the problem of unprotected header extension values. It never got much adoption though, and it has a few technical shortcomings 😬
First, it's complicated. It lets you negotiate encryption on a per-extension basis, which means a fair amount of signaling logic. On the SRTP layer, you also need a somewhat complex transform so that only the selected header extension values get encrypted. One of the most popular SRTP implementations had a significant bug in this area that went undetected for five years 💀
Second, it only protects the header extension values. It doesn't protect their identifiers or lengths, and it doesn't protect the CSRCs either. As mentioned above, that leaves a lot of potentially sensitive info exposed 🫠
Third, it bloats the header extension space. Every extension has to be offered in both unencrypted and encrypted forms, so you end up offering twice as many header extensions. In lots of cases that pushes implementations past the 14-extension limit for one-byte extension headers from [RFC8285]. So a bunch of implementations would have to switch to two-byte headers, and some existing implementations don't support those well 😩
Finally, all that bloat plus the need for backward compatibility adds wire overhead. Two-byte extension headers might not be handled well by existing implementations, so the unencrypted (backward-compatible) forms have to use one-byte extension identifiers, and the encrypted forms use two-byte ones. So deploying header extension encryption with [RFC6904] usually adds several extra bytes to every RTP packet, compared to today 📦
1.3. Goals 🎯
From that analysis, here's what a good solution needs:
- Built on the existing SRTP framework [RFC3711] (simple to understand)
- Built on the existing header extension framework [RFC8285] (simple to implement)
- Protection of header extension identifiers, lengths, and values
- Protection of CSRCs when present
- Simple signaling
- Simple crypto transform and SRTP interactions
- Backward compatibility with unencrypted endpoints, if desired
- Backward compatibility with existing RTP tooling
The last point needs more explanation 🧐 Other solutions that would have encrypted more of the RTP header (like the number of CSRCs) were considered too. But the inability to parse the resulting packets with current tools, plus a generally higher level of complexity, outweighed the small confidentiality gain. So the doc went with a more pragmatic approach to the problem from Section 1.1 💅
2. Terminology 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🔑
3. Design 🏗️
This spec proposes a way to negotiate encryption of all RTP header extensions (ids, lengths, and values) as well as CSRC values. It reuses the existing SRTP framework, so it's simple to implement, and it stays backward compatible with existing RTP packet parsing code, even when the mechanism has been negotiated 🦋
Unless it explicitly says otherwise, Cryptex reuses all the framework procedures, transforms, and considerations described in [RFC3711] ✨
4. SDP Considerations 📞
Cryptex support gets indicated through a new a=cryptex SDP attribute, which this spec defines 💜
The new a=cryptex attribute is a property attribute, as defined in Section 5.13 of [RFC8866]. That means it takes no value and can be used at the session level or the media level 🌷
If an endpoint has a=cryptex in its SDP (in either an offer or an answer), that means it can receive RTP packets encrypted with Cryptex, as defined below 🫶
Once each peer has verified that the other party supports receiving Cryptex-encrypted RTP packets, senders can unilaterally decide whether or not to use Cryptex on a per-packet basis 🔥
If BUNDLE is in use as per [RFC9143] and the a=cryptex attribute is present for a media line, it MUST be present for all RTP-based m= sections belonging to the same bundle group. This makes sure the encrypted Media Identifier (MID) header extensions can be processed, so RTP streams get associated with the correct m= section in each BUNDLE group, as specified in Section 9.2 of [RFC9143] 🧩 When used with BUNDLE, this attribute is assigned to the TRANSPORT category [RFC8859].
Both endpoints can change their Cryptex support status by modifying the session, as specified in Section 8 of [RFC3264]. Generating subsequent SDP offers and answers MUST use the same procedures for including the a=cryptex attribute as the ones used on the initial offer and answer 💖
Up next: 5. RTP Header Processing 💅🌈
5. RTP Header Processing 🎀
okay bestie, so [RFC8285] (the "General Mechanism for RTP Header Extensions") already defines two magic values for the "defined by profile" field, one for one-byte header extensions and one for two-byte ones 💅. To let a receiver spot an incoming packet that's using the encryption scheme in this spec, we get two brand new values:
- 0xC0DE for the encrypted version of the one-byte header extensions (instead of 0xBEDE). 🫶
- 0xC2DE for the encrypted versions of the two-byte header extensions (instead of 0x100). ✨
Quick heads up for the two-byte case 🚨: the extension identifier with value 256 MUST NOT be negotiated, because that value is meant to live in the "appbits" of the "defined by profile" field, and those appbits aren't available when you're using the values above. no cap, that's a whole vibe-killer if you get it wrong 💀
Also, as per [RFC8285], you can't mix one-byte and two-byte headers on the same RTP packet 🙅♀️. If you want to mix them on the same RTP stream, you have to negotiate the "extmap-allow-mixed" SDP attribute, which is defined in Section 6 of [RFC8285]. iykyk 🌸
Peers MAY negotiate both Cryptex and the Encryption of Header Extensions mechanism defined in [RFC6904] through SDP offer/answer (see Section 4 for the deets 🦋). If both mechanisms are supported, either one can be used for any given packet. BUT, if a packet is encrypted with Cryptex, it MUST NOT also use header extension encryption [RFC6904], and vice versa. Pick one per packet, no double dipping 🙅♀️💜
If one of the peers has advertised that it can receive both Cryptex and header extensions encrypted as per [RFC6904] in the SDP exchange, it is RECOMMENDED that the other peer use Cryptex rather than the [RFC6904] mechanism when sending RTP packets. The reason is that this way all the header extensions and CSRCS get encrypted 🔐✨. However, if there's a compelling reason to use the [RFC6904] mechanism (for example, some header extensions need to stay in the clear so RTP middleboxes can process them 📦), the other peer SHOULD use the [RFC6904] mechanism instead. ngl that's a very reasonable exception 🙌
5.1. Sending 📤
When the mechanism in this spec has been negotiated, sending an RTP packet that has any CSRCs or contains any header extensions [RFC8285] follows the steps below. Also, this mechanism MUST NOT be used with header extensions other than the variety described in [RFC8285]. Strict, but fair 💅
If the RTP packet contains one-byte headers, the 16-bit RTP header extension tag MUST be set to 0xC0DE. This tells everyone the encryption has been applied AND the one-byte framing is in use. If the RTP packet contains two-byte headers, the header extension tag MUST be set to 0xC2DE, meaning encryption has been applied and the two-byte framing is in use. Two tags, two vibes 🎀
If the packet has CSRCs but no header extensions, we append an empty extension block 🧺. That block is the 0xC0DE tag plus a 16-bit length field set to zero (which [RFC3550] explicitly permits). The X bit MUST be set to 1 to show an extension block is present. This is necessary so the receiver knows the CSRCs in the packet are encrypted 🙈
Then the RTP packet MUST be encrypted as described in Section 6.2 ("Encryption Procedure"). 🔒
5.2. Receiving 📥
When receiving an RTP packet that contains header extensions, the "defined by profile" field MUST be checked to make sure the payload is formatted according to this spec 🔍. If the field doesn't match one of the values defined above, the implementation MUST instead handle it according to whatever spec defines that value. Main character energy for the other spec 👑
Alternatively, if the implementation considers this specification mandatory and the "defined by profile" field doesn't match one of the values defined above, it MUST stop processing the RTP packet and report an error for the RTP stream. 🚫 Not it.
If the RTP packet passes this check, it gets decrypted as described in Section 6.3 ("Decryption Procedure") and then passed to the next layer to process the packet and its extensions. And if a zero-length extension block was added as described above, it can be left as is and will be processed normally ✨
6. Encryption and Decryption 🔐
6.1. Packet Structure 🧩
When this mechanism is active, the SRTP packet is protected as follows:
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 | |
| | .... | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
X | 0xC0 or 0xC2 | 0xDE | length | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | RFC 8285 header extensions | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | payload ... | |
| | +-------------------------------+ |
| | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTP Master Key Identifier (MKI) (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag (RECOMMENDED) : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+- Encrypted Portion Authenticated Portion ---+
Figure 1: A Protected SRTP PacketNote that, as required by [RFC8285], the 4 bytes at the start of the extension block are not encrypted. 👀
Specifically, the Encrypted Portion MUST include any CSRC identifiers, any RTP header extension (except for the first 4 bytes), and the RTP payload. Big list of stuff to encrypt, very important 🫶
6.2. Encryption Procedure 🗝️
The encryption procedure is identical to that of [RFC3711] except for the Encrypted Portion of the SRTP packet. The plaintext input to the cipher looks like this:
Plaintext = CSRC identifiers (if used) || header extension data ||
RTP payload || RTP padding (if used) || RTP pad count (if used)Here "header extension data" means the content of the RTP extension field, excluding the first four bytes (the extension header [RFC8285]). The first 4 * CSRC count (CC) bytes of the ciphertext go into the CSRC field of the RTP header. The rest of the ciphertext is the RTP payload of the encrypted packet 🌈
To minimize changes to surrounding code, the encryption mechanism can choose to replace a "defined by profile" field from [RFC8285] with its counterpart defined in Section 5 ("RTP Header Processing") and encrypt at the same time. Smart shortcut 💅
For Authenticated Encryption with Associated Data (AEAD) ciphers (e.g., AES-GCM), the 12-byte fixed header and the four-byte header extension header (the "defined by profile" field and the length) are considered additional authenticated data (AAD), even though they're non-contiguous in the packet if CSRCs are present 🧠
Associated Data: fixed header || extension header (if X=1)Here "fixed header" means the 12-byte fixed portion of the RTP header, and "extension header" means the four-byte extension header [RFC8285] ("defined by profile" and extension length). 📝
Implementations can rearrange a packet so the AAD and plaintext are contiguous, by swapping the order of the extension header and the CSRC identifiers. That gives an intermediate representation like Figure 2 below. After encryption, the CSRCs (now encrypted) and extension header need to be swapped back to their original positions. A similar operation can be done when decrypting, to create contiguous ciphertext and AAD inputs. Swap swap swap 🔄
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 0xC0 or 0xC2 | 0xDE | length | |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+<+
| | contributing source (CSRC) identifiers | |
| | .... | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | RFC 8285 header extensions | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | payload ... | |
| | +-------------------------------+ |
| | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+- Plaintext Input AAD Input ---+
Figure 2: An RTP Packet Transformed to Make Cryptex Cipher Inputs
ContiguousNote that this intermediate representation is only shown as a reference for implementations and is NOT meant to be sent on the wire. 🚫📡
6.3. Decryption Procedure 🔓
The decryption procedure is identical to that of [RFC3711] except for the Encrypted Portion of the SRTP packet, which is as shown in the section above. ✅
To minimize changes to surrounding code, the decryption mechanism can choose to replace the "defined by profile" field with its no-encryption counterpart from [RFC8285] and decrypt at the same time. Same trick, other direction 🔁
7. Backward Compatibility 🕰️
This specification tries to encrypt as much as possible without messing up backward compatibility for systems that expect a certain structure from an RTPv2 packet. That includes systems that demultiplex based on packet headers. So, the first two bytes of the RTP packet are not encrypted. 🫶
This specification also tries to reuse the key scheduling from SRTP, which depends on the RTP packet sequence number and SSRC identifier. So these values are not encrypted either 🔑
8. Security Considerations 🔐✨
Okay bestie, this section is where we get serious. Everything in Section 9 of [RFC3711] still applies to this spec 💅, with one exception: Section 9.4, because keeping the RTP Header confidential is literally the whole point of Cryptex 🙈.
The risks of using weak or NULL authentication with SRTP, which are covered in Section 9.5 of [RFC3711], also apply to encrypted header extensions. So no skipping auth, not even a little 💀.
This spec extends SRTP by expanding the Encrypted Portion of the RTP packet, as shown in Section 6.1 ("Packet Structure") 📦. It does not change how SRTP authentication works in any way 🔒. Since more of the packet is getting encrypted than before, this is necessarily an improvement 💖.
The RTP fields that are left unencrypted (see rationale above) are:
- RTP version
- padding bit
- extension bit
- number of CSRCs
- marker bit
- payload type
- sequence number
- timestamp
- SSRC identifier
- number of header extensions [RFC8285]
These values are a fixed set (meaning one that extensions won't change) of information that, for now, is observed to have low sensitivity 🦋. If any of these values ever need to be encrypted, SRTP is probably the wrong protocol to use, and a fully encapsulating protocol such as DTLS is preferred, even with its attendant per-packet overhead 🧚.
Main character warning: if you need to hide those fields, don't reach for SRTP. Reach for DTLS and accept the extra per-packet overhead 😭.
9. IANA Considerations 🗂️🌸
Okay so this doc updates the "attribute-name (formerly "att-field")" subregistry of the "Session Description Protocol (SDP) Parameters" registry (see Section 8.2.4 of [RFC8866]) 💜. Specifically, it adds the SDP "a=cryptex" attribute, usable at both the media level and the session level ✨. Here's the template, verbatim:
Contact name: IETF AVT Working Group or IESG if the AVT Working
Group is closed
Contact email address: avt@ietf.org
Attribute name: cryptex
Attribute syntax: This attribute takes no values.
Attribute semantics: N/A
Attribute value: N/A
Usage level: session, media
Charset dependent: No
Purpose: The presence of this attribute in the SDP indicates that
the endpoint is capable of receiving RTP packets encrypted with
Cryptex as described in this document.
O/A procedures: SDP O/A procedures are described in Section 4 of
this document.
Mux Category: TRANSPORT10. References 📚🎀
10.1. Normative References
Here are the normative references, the ones you absolutely need to read to get this spec 🤓:
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General
Mechanism for RTP Header Extensions", RFC 8285,
DOI 10.17487/RFC8285, October 2017,
<https://www.rfc-editor.org/info/rfc8285>.
[RFC8859] Nandakumar, S., "A Framework for Session Description
Protocol (SDP) Attributes When Multiplexing", RFC 8859,
DOI 10.17487/RFC8859, January 2021,
<https://www.rfc-editor.org/info/rfc8859>.
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
Session Description Protocol", RFC 8866,
DOI 10.17487/RFC8866, January 2021,
<https://www.rfc-editor.org/info/rfc8866>.
[RFC9143] Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", RFC 9143,
DOI 10.17487/RFC9143, February 2022,
<https://www.rfc-editor.org/info/rfc9143>.10.2. Informative References
And these are the informative ones, nice to know, not strictly required 🌈:
[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", RFC 6464,
DOI 10.17487/RFC6464, December 2011,
<https://www.rfc-editor.org/info/rfc6464>.
[RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-
time Transport Protocol (RTP) Header Extension for Mixer-
to-Client Audio Level Indication", RFC 6465,
DOI 10.17487/RFC6465, December 2011,
<https://www.rfc-editor.org/info/rfc6465>.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
Real-time Transport Protocol (SRTP)", RFC 6904,
DOI 10.17487/RFC6904, April 2013,
<https://www.rfc-editor.org/info/rfc6904>.
[RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption
in the Secure Real-time Transport Protocol (SRTP)",
RFC 7714, DOI 10.17487/RFC7714, December 2015,
<https://www.rfc-editor.org/info/rfc7714>.Appendix A. Test Vectors 🧪💖
All values are in hexadecimal and represented in network order (big endian) 🔢. These are the test vectors, so you can check your work and feel like a whole genius 🧠✨.
A.1. AES-CTR
The following subsections list the test vectors for using Cryptex with AES-CTR as per [RFC3711] 💜.
Common values are organized as follows:
Rollover Counter: 00000000
Master Key: e1f97a0d3e018be0d64fa32c06de4139
Master Salt: 0ec675ad498afeebb6960b3aabe6
Crypto Suite: AES_CM_128_HMAC_SHA1_80
Session Key: c61e7a93744f39ee10734afe3ff7a087
Session Salt: 30cbbc08863d8c85d49db34a9ae1
Authentication Key: cebe321f6ff7716b6fd4ab49af256a156d38baa4A.1.1. RTP Packet with One-Byte Header Extension
RTP Packet:
900f1235
decafbad
cafebabe
bede0001
51000200
abababab
abababab
abababab
ababababEncrypted RTP Packet:
900f1235
decafbad
cafebabe
c0de0001
eb923652
51c3e036
f8de27e9
c27ee3e0
b4651d9f
bc4218a7
0244522f
34a5A.1.2. RTP Packet with Two-Byte Header Extension
RTP Packet:
900f1236
decafbad
cafebabe
10000001
05020002
abababab
abababab
abababab
ababababEncrypted RTP Packet:
900f1236
decafbad
cafebabe
c2de0001
4ed9cc4e
6a712b30
96c5ca77
339d4204
ce0d7739
6cab6958
5fbce381
94a5A.1.3. RTP Packet with One-Byte Header Extension and CSRC Fields
RTP Packet:
920f1238
decafbad
cafebabe
0001e240
0000b26e
bede0001
51000200
abababab
abababab
abababab
ababababEncrypted RTP Packet:
920f1238
decafbad
cafebabe
8bb6e12b
5cff16dd
c0de0001
92838c8c
09e58393
e1de3a9a
74734d67
45671338
c3acf11d
a2df8423
bee0A.1.4. RTP Packet with Two-Byte Header Extension and CSRC Fields
RTP Packet:
920f1239
decafbad
cafebabe
0001e240
0000b26e
10000001
05020002
abababab
abababab
abababab
ababababEncrypted RTP Packet:
920f1239
decafbad
cafebabe
f70e513e
b90b9b25
c2de0001
bbed4848
faa64466
5f3d7f34
125914e9
f4d0ae92
3c6f479b
95a0f7b5
3133A.1.5. RTP Packet with Empty One-Byte Header Extension and CSRC Fields
RTP Packet:
920f123a
decafbad
cafebabe
0001e240
0000b26e
bede0000
abababab
abababab
abababab
ababababEncrypted RTP Packet:
920f123a
decafbad
cafebabe
7130b6ab
fe2ab0e3
c0de0000
e3d9f64b
25c9e74c
b4cf8e43
fb92e378
1c2c0cea
b6b3a499
a14cA.1.6. RTP Packet with Empty Two-Byte Header Extension and CSRC Fields
RTP Packet:
920f123b
decafbad
cafebabe
0001e240
0000b26e
10000000
abababab
abababab
abababab
ababababEncrypted RTP Packet:
920f123b
decafbad
cafebabe
cbf24c12
4330e1c8
c2de0000
599dd45b
c9d687b6
03e8b59d
771fd38e
88b170e0
cd31e125
eabeA.2. AES-GCM
The following subsections list the test vectors for using Cryptex with AES-GCM as per [RFC7714] 🌸.
Common values are organized as follows:
Rollover Counter: 00000000
Master Key: 000102030405060708090a0b0c0d0e0f
Master Salt: a0a1a2a3a4a5a6a7a8a9aaab
Crypto Suite: AEAD_AES_128_GCM
Session Key: 077c6143cb221bc355ff23d5f984a16e
Session Salt: 9af3e95364ebac9c99c5a7c4A.2.1. RTP Packet with One-Byte Header Extension
RTP Packet:
900f1235
decafbad
cafebabe
bede0001
51000200
abababab
abababab
abababab
ababababEncrypted RTP Packet:
900f1235
decafbad
cafebabe
c0de0001
39972dc9
572c4d99
e8fc355d
e743fb2e
94f9d8ff
54e72f41
93bbc5c7
4ffab0fa
9fa0fbebA.2.2. RTP Packet with Two-Byte Header Extension
RTP Packet:
900f1236
decafbad
cafebabe
10000001
05020002
abababab
abababab
abababab
ababababEncrypted RTP Packet:
900f1236
decafbad
cafebabe
c2de0001
bb75a4c5
45cd1f41
3bdb7daa
2b1e3263
de313667
c9632490
81b35a65
f5cb6c88
b394235fA.2.3. RTP Packet with One-Byte Header Extension and CSRC Fields
RTP Packet:
920f1238
decafbad
cafebabe
0001e240
0000b26e
bede0001
51000200
abababab
abababab
abababab
ababababEncrypted RTP Packet:
920f1238
decafbad
cafebabe
63bbccc4
a7f695c4
c0de0001
8ad7c71f
ac70a80c
92866b4c
6ba98546
ef913586
e95ffaaf
fe956885
bb0647a8
bc094ac8A.2.4. RTP Packet with Two-Byte Header Extension and CSRC Fields
RTP Packet:
920f1239
decafbad
cafebabe
0001e240
0000b26e
10000001
05020002
abababab
abababab
abababab
ababababEncrypted RTP Packet:
920f1239
decafbad
cafebabe
3680524f
8d312b00
c2de0001
c78d1200
38422bc1
11a7187a
18246f98
0c059cc6
bc9df8b6
26394eca
344e4b05
d80fea83A.2.5. RTP Packet with Empty One-Byte Header Extension and CSRC Fields 🌸
okay so this one is the empty one-byte header extension, but with CSRC fields tossed in too 💅 the RTP Packet: comes first, then the Encrypted RTP Packet: (the same packet after encryption) ✨
RTP Packet:
920f123a
decafbad
cafebabe
0001e240
0000b26e
bede0000
abababab
abababab
abababab
ababababEncrypted RTP Packet:
920f123a
decafbad
cafebabe
15b6bb43
37906fff
c0de0000
b7b96453
7a2b03ab
7ba5389c
e9331712
6b5d974d
f30c6884
dcb651c5
e120c1daA.2.6. RTP Packet with Empty Two-Byte Header Extension and CSRC Fields 🦋
and last but not least, the empty two-byte header extension version with CSRC fields 🫶 same deal: plain packet first, then the encrypted one underneath 🔥
RTP Packet:
920f123b
decafbad
cafebabe
0001e240
0000b26e
10000000
abababab
abababab
abababab
ababababEncrypted RTP Packet:
920f123b
decafbad
cafebabe
dcb38c9e
48bf95f4
c2de0000
61ee432c
f9203170
76613258
d3ce4236
c06ac429
681ad084
13512dc9
8b5207d8Acknowledgements 💖
the authors wanted to give a shoutout to Lennart Grahl for pointing out a bunch of the issues with the existing header encryption mechanism 👑 and for suggestions on this proposal too 🙈 thanks also to Jonathan Lennox, Inaki Castillo, and Bernard Aboba for their reviews and suggestions 🧚 literally the whole squad 🫶
Authors' Addresses 💜
Justin Uberti Email: justin@uberti.name
Cullen Jennings Cisco Email: fluffy@iii.ca
Sergio Garcia Murillo Millicast Email: sergio.garcia.murillo@cosmosoftware.io
that's the whole doc, bestie 🎀✨ you made it through all four parts 😭💅
📦 where this page comes from
- ietf: rfc9335 2023-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms