RFC 6904
Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)
RFC 6904: Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP) ✨
Okay bestie, let's start with the vibes 🦋. This is RFC 6904, written by J. Lennox from Vidyo in April 2013. It's a Standards Track doc (ISSN 2070-1721) from the IETF, which is the crew that defines how the Internet's protocols work 💅. It updates RFC 3711, so it's a tweak to that spec, and there's no Obsoletes line in the header, so it doesn't replace anything 🌸.
Abstract
okay so SRTP gives you authentication but not encryption for the headers of RTP packets 🙈. The thing is, RTP header extensions can hold sensitive info that people in calls really don't want anyone reading. This doc adds a way, built on top of SRTP's existing machinery, to selectively encrypt RTP header extensions in SRTP 🔐.
It also updates RFC 3711, the Secure Real-time Transport Protocol spec, so that every future SRTP encryption transform has to say how RTP header extensions get encrypted. Main character energy for future-proofing 👑.
Status of This Memo
This is an Internet Standards Track document 🎀.
It's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 ✨.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6904 🌈.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved 💜.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📜. Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⚠️.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Encryption Mechanism . . . . . . . . . . . . . . . . . . . . 4
3.1. Example Encryption Mask . . . . . . . . . . . . . . . . . 6
3.2. Header Extension Keystream Generation for Existing
Encryption Transforms . . . . . . . . . . . . . . . . . . 7
3.3. Header Extension Keystream Generation for Future
Encryption Transforms . . . . . . . . . . . . . . . . . . 8
4. Signaling (Setup) Information . . . . . . . . . . . . . . . . 8
4.1. Backward Compatibility . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 13
A.1. Key Derivation Test Vectors . . . . . . . . . . . . . . . 13
A.2. Header Encryption Test Vectors Using AES-CM . . . . . . . 141. Introduction 🌷
So the Secure Real-time Transport Protocol [RFC3711] gives you confidentiality, message authentication, and replay protection for multimedia payloads sent over the Real-time Protocol (RTP) [RFC3550] 🎬. BUT, to keep RTP header compression efficient, SRTP only gives authentication and replay protection to RTP packet headers, not confidentiality 🤷♀️.
For the standard parts of an RTP header, that's usually fine 💅. The info in there doesn't reveal much beyond what an attacker could already guess by watching packet sizes and timing, so there's not much reason to keep header info confidential.
Header extensions are a different story 😭. A bunch of recent proposals use the mechanism from "A General Mechanism for RTP Header Extensions" [RFC5285], and some of them carry info where confidentiality could be wanted or even essential. Two recent specs, [RFC6464] and [RFC6465], are the big examples: they carry per-packet sound levels for the media in the RTP payload, and they say exposing that to an eavesdropper is unacceptable in many situations (see the Security Considerations sections of those RFCs) 🙉.
So this document defines a way to encrypt RTP header extensions when they're sent using SRTP 🔥. An RTP sender might want some extension info to go out in the clear, though. For example, a network monitoring device may find it useful to know RTP transmission time offsets [RFC5450] 🧚. So this mechanism can be applied selectively to a subset of the header extension elements in an SRTP packet 💖.
The mechanism encrypts packet header extensions with the same cryptographic algorithms and parameters used to encrypt the RTP payloads of those packets 🔐. This document spells out how that works for the encryption transforms defined in [RFC3711], [RFC5669], and [RFC6188]. Those are the SRTP encryption transforms defined by Standards Track RFCs at the time of writing ✨. It also updates [RFC3711] to say that specs for future SRTP encryption transforms must define how header extension encryption gets done 👑.
2. Terminology 📚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. They indicate requirement levels for compliant implementations 🫶.
3. Encryption Mechanism 🦋
Encrypted header extension elements get carried the same way as non-encrypted ones, as defined by [RFC5285] 💜. The one- or two-byte header of each extension element is NOT encrypted, and neither is any header extension padding 🙈. If you're encrypting several different header extension elements, they each get their own element identifier values, just like they would if they weren't encrypted. Encrypted and non-encrypted elements also have separate identifier values from each other 🍓.
Encrypted header extension elements only show up in packets encrypted with the Secure Real-time Transport Protocol [RFC3711] 🔐. To encrypt (or decrypt) them, an SRTP participant first runs the SRTP key derivation algorithm from Section 4.3.1 of [RFC3711] to generate the header encryption and header salting keys 🗝️. It uses the same pseudorandom function family that's used for key derivation for the SRTP session. The keys are derived like this:
k_he (SRTP header encryption): <label> = 0x06, n=n_e.k_hs (SRTP header salting key): <label> = 0x07, n=n_s.
Here n_e and n_s come from the cryptographic context. The header encryption key and header salting key are the same size as the encryption key and salting key used for the SRTP payload 🌸. Also, the same master key, master salt, index, and key_derivation_rate are used as for the SRTP payload ✨. (Heads up: since RTP headers, header extensions included, are authenticated in SRTP, no new authentication key is needed for header extensions 🔑.)
A header extension keystream gets generated for each packet that contains encrypted header extension elements 🌈. How that keystream is generated depends on the encryption transform used for the SRTP packet. For transforms standardized as of this document's publication date, see Section 3.2. For requirements on new transforms, see Section 3.3 📖.
Once the header extension keystream exists, the SRTP participant computes an encryption mask for the header extension 🎭. The mask marks which parts of the header extension are, or are going to be, encrypted. (Want an example of this? See Section 3.1.) The mask covers the entire payload of each header extension element that's encrypted. It does NOT include non-encrypted header extension elements, extension element headers, or padding octets 🙅♀️. Encrypted octets are marked with all-bits-1 octets (hexadecimal 0xff), and octets that stay unencrypted are marked with all-bits-0 octets 💅. The sender and receiver agree on the set of extension elements to encrypt using the signaling mechanisms described in Section 4 📡.
The mask gets computed separately for every packet that carries a header extension ✨. Based on the non-encrypted parts of the headers and the signaled list of encrypted extension elements, a receiver can always work out the correct encryption mask for any encrypted header extension 🧠.
Next, the SRTP participant bitwise-ANDs the encryption mask with the keystream to get a masked keystream 🎀. Then it bitwise exclusive-ORs the header extension with that masked keystream to make the ciphertext version of the header extension 💫. (So octets marked all-bits-1 in the mask get encrypted, and the ones marked all-bits-0 don't.)
Important detail: the header extension encryption process does NOT touch the "defined by profile" or "length" fields of the header extension 🙌. It only covers the field that Section 5.3.1 of [RFC3550] calls "header extension" proper, starting from the first [RFC5285] ID and length. Both the encryption mask and the keystream start at that same point 🦋.
You can also think of this same header extension encryption process as a mix of encrypted and unencrypted headers, written like this 🧩:
EncryptedHeader = (Encrypt(Key, Plaintext) AND MASK) OR
(Plaintext AND (NOT MASK))In that formula, Encrypt is the encryption function, MASK is the encryption mask, and AND, OR, and NOT are bitwise operations. Implementations where encryption happens in a separate module that can't easily be changed might prefer this version 🛠️.
Now the security-critical bit 🚨. The SRTP authentication tag gets computed across the encrypted header extension, meaning the data that's actually sent on the wire 🔒. So header extension encryption MUST be done before the authentication tag is computed, and authentication tag validation MUST be done on the encrypted header extensions. On the receiving end, header extension decryption SHOULD only happen after the receiver has validated the packet's message authentication tag. Also, before validating the authentication tag, the receiver MUST NOT take any actions based on decrypted headers that could affect the security or proper functioning of the system 🚫💀.
3.1. Example Encryption Mask ✨
okay so say a sender wants to send a header extension with an encrypted SMPTE timecode [RFC5484] with ID 1, a plaintext transmission time offset [RFC5450] with ID 2, an encrypted audio level indication [RFC6464] with ID 3, and an encrypted NTP timestamp [RFC6051] with ID 4. the plaintext RTP header extension might look like this 👀💖
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=1 | len=7 | SMTPE timecode (long form) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMTPE timecode (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMTPE (cont'd)| ID=2 | len=2 | toffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| toffset (ct'd)| ID=3 | len=0 | audio level | ID=4 | len=6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp (Variant B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp (Variant B, cont'd) | padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Structure of Plaintext Example Header Extensionthe matching encryption mask would then be 🎭
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Encryption Mask for Example Header Extensionso in the mask, the octets for the payloads of the encrypted header extension elements are set to all-1 values 🔒, and the octets for non-encrypted header extension elements, element headers, and header extension padding are set to all-zero values 🫧
3.2. Header Extension Keystream Generation for Existing Encryption Transforms 🔑
for the AES-CM and AES-f8 transforms [RFC3711], the SEED-CTR transform [RFC5669], and the AES_192_CM and AES_256_CM transforms [RFC6188], the header extension keystream SHALL be generated for each packet containing encrypted header extension elements. it uses the same encryption transform and Initialization Vector (IV) as that packet's SRTP payload 💅, except the SRTP encryption and salting keys k_e and k_s get swapped out for the SRTP header encryption and header salting keys k_he and k_hs, respectively, as defined above.
for the SEED-CCM and SEED-GCM transforms [RFC5669], the header extension keystream SHALL be generated using the algorithm specified above for the SEED-CTR algorithm. (this part is so iconic 🥹 because the Authenticated Encryption with Associated Data (AEAD) transform used on the payload in these algorithms includes the RTP header, including the RTP header extension, in its Associated Authenticated Data (AAD), counter-mode encryption for the header extension is believed to be of equivalent cryptographic strength to the CCM and GCM transforms.)
and for the NULL encryption transform [RFC3711], the header extension keystream SHALL be all-zero 🤍
3.3. Header Extension Keystream Generation for Future Encryption Transforms 🔮
when new SRTP encryption transforms get defined, this document updates [RFC3711] like this: in addition to the rules in Section 6 of RFC 3711, the Standards Track RFC defining the new transform MUST specify how the encryption transform is to be used with header extension encryption. it's a must, bestie 📜
it is RECOMMENDED that new transformations follow the same mechanisms as are defined in Section 3.2 of this document, if they are applicable and are believed to be cryptographically adequate for the transform in question ✨
4. Signaling (Setup) Information 📣
encrypted header extension elements get signaled in the Session Description Protocol (SDP) extmap attribute. you use the URI "urn:ietf:params:rtp-hdrext:encrypt", then the URI of the header extension element being encrypted, plus any extensionattributes that extension normally takes 🎀 Figure 3 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar showing this extension, which builds on the grammar defined in [RFC5285] 🧠
enc-extensionname = %x75.72.6e.3a.69.65.74.66.3a.70.61.72.61.6d.73.3a
%x72.74.70.2d.68.64.72.65.78.74.3a.65.6e.63.72.79.70.74
; "urn:ietf:params:rtp-hdrext:encrypt" in lower case
extmap =/ mapentry SP enc-extensionname SP extensionname
[SP extensionattributes]
; extmap, mapentry, extensionname, and extensionattributes
; are defined in [RFC5285]
Figure 3: Syntax of the "encrypt" extmapso for example, if you want an SRTP session with encrypted SMPTE timecodes [RFC5484] while also signaling plaintext transmission time offsets [RFC5450] 🍓, an SDP document could contain the text shown in Figure 4 (line breaks have been added for formatting).
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32 \
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=extmap:1 urn:ietf:params:rtp-hdrext:encrypt \
urn:ietf:params:rtp-hdrext:smpte-tc 25@600/24
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
Figure 4: Sample SDP Document Offering Encrypted Headersthis example uses SDP security descriptions [RFC4568] for SRTP keying, but that's just for illustration 🙈 any SRTP keying mechanism that establishes session keys will work 🗝️
the extmap SDP attribute is defined in [RFC5285] as being either a session or media attribute. if the extmap for an encrypted header extension is specified as a media attribute, it MUST be specified only for media that use SRTP-based RTP profiles. if such an extmap is specified as a session attribute, there MUST be at least one media in the SDP session that uses an SRTP-based RTP profile. the session-level extmap applies to all the SRTP-based media in the session and MUST be ignored for all other (non-SRTP or non-RTP) media. the vibe is: know where you put it 🗺️
the "urn:ietf:params:rtp-hdrext:encrypt" extension MUST NOT be recursively applied to itself 🙅♀️
4.1. Backward Compatibility 🤝
following the procedures in [RFC5285], an SDP endpoint that does not understand the "urn:ietf:params:rtp-hdrext:encrypt" extension URI will ignore the extension and, for SDP offer/answer, will negotiate not to use it 🫠
for backward compatibility with endpoints that don't implement this specification, in a negotiated session (whether using offer/answer or some other means), best-effort encryption of a header extension element is possible: an endpoint MAY offer the same header extension element both encrypted and unencrypted. an offerer MUST offer only best-effort negotiation when lack of confidentiality would be acceptable in the backward-compatible case. answerers (or equivalent peers in a negotiation) that understand header extension encryption SHOULD choose the encrypted form of the offered header extension element and mark the unencrypted form "inactive", unless they have an explicit reason to prefer the unencrypted form. in all cases, answerers MUST NOT negotiate the use of, and senders MUST NOT send, both encrypted and unencrypted forms of the same header extension 🙅
note that, as always, users of best-effort encryption MUST be cautious of bid-down attacks, where a man-in-the-middle attacker removes a higher-security option, forcing endpoints to negotiate a lower-security one. appropriate countermeasures depend on the signaling protocol in use, but users can ensure, for example, that signaling is integrity-protected 🚨
5. Security Considerations 🚨
the security properties of header extension elements protected by the mechanism in this document are equivalent to those for SRTP payloads 🔐
the mechanism defined in this document does not provide confidentiality about which header extension elements are used for a given SRTP packet, only for the content of those header extension elements. this appears to be in the spirit of SRTP itself, which does not encrypt RTP headers. if this is a concern, an alternate mechanism would be needed to provide confidentiality 👀
for the two-byte-header form of header extension elements (0x100N, where "N" is the appbits field), this mechanism does not provide any protection to zero-length header extension elements (for which their presence or absence is the only information they carry). it also does not provide any protection for the appbits (field 256, the lowest four bits of the "defined by profile" field) of the two-byte headers. neither of these features is present in the one-byte-header form of header extension elements (0xBEDE), so these limitations do not apply in that case 💫
this mechanism cannot protect RTP header extensions that do not use the mechanism defined in [RFC5285] 🫣
this document does not specify the circumstances in which extension header encryption should be used. documents defining specific header extension elements should provide guidance on when encryption is appropriate for these elements 📝
if a middlebox does not have access to the SRTP authentication keys, it has no way to verify the authenticity of unencrypted RTP header extension elements (or the unencrypted RTP header), even though it can monitor them. therefore, such middleboxes MUST treat such headers as untrusted and potentially generated by an attacker, in the same way as they treat unauthenticated traffic. (this does not mean that middleboxes cannot view and interpret such traffic, of course, only that appropriate skepticism needs to be maintained about the results of such interpretation.) 🕵️♀️
there is no mechanism defined to protect header extensions with different algorithms or encryption keys than are used to protect the RTP payloads. in particular, it is not possible to provide confidentiality for a header extension while leaving the payload in cleartext 🙃
the dangers of using weak or NULL authentication with SRTP, described in Section 9.5 of [RFC3711], apply to encrypted header extensions as well. in particular, since some header extension elements will have some easily guessed plaintext bits, strong authentication is REQUIRED if an attacker setting such bits could have a meaningful effect on the behavior of the system. this one is serious, bestie 😭
the technique defined in this document can be applied only to encryption transforms that work by generating a pseudorandom keystream and bitwise exclusive-ORing it with the plaintext, such as CTR or f8. it will not work with ECB, CBC, or any other encryption method that does not use a keystream 🧁
6. IANA Considerations 📋✨
okay so IANA gets a new entry, bestie 💅 this doc adds a new extension URI to the RTP Compact Header Extensions subregistry of the Real-Time Transport Protocol (RTP) Parameters registry. here's the exact entry:
Extension URI: urn:ietf:params:rtp-hdrext:encrypt
Description: Encrypted header extension element
Contact: jonathan@vidyo.com
Reference: RFC 69047. Acknowledgments 🫶
shoutout to everyone who helped shape this spec, it's giving teamwork 🌸 thank you to Benoit Claise, Roni Even, Stephen Farrell, Kevin Igoe, Joel Jaeggli, David McGrew, David Singer, Robert Sparks, Magnus Westerlund, Qin Wu, and Felix Wyss for their comments and suggestions while this was being developed. literally the dream team 👑
8. References 📚
8.1. Normative References 💜
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008.
[RFC5669] Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)", RFC 5669, August 2010.
[RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure RTP", RFC 6188, March 2011.
8.2. Informative References 🦋
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in RTP Streams", RFC 5450, March 2009.
[RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", RFC 5484, March 2009.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, November 2010.
[RFC6464] Lennox, J., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication", RFC 6464, December 2011.
[RFC6465] Ivov, E., Marocco, E., and J. Lennox, "A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication", RFC 6465, December 2011.
Appendix A. Test Vectors 🧪🎀
A.1. Key Derivation Test Vectors 🔑
okay this section is the test data for the header extension key derivation function 🌈 it uses AES-128 in Counter Mode. (same algorithms and keys as the test vectors in Appendix B.3 of [RFC3711], so it's all connected 🫶)
the inputs are the 16-octet master key and the 14-octet master salt:
master key: E1F97A0D3E018BE0D64FA32C06DE4139
master salt: 0EC675AD498AFEEBB6960B3AABE6following [RFC3711], the AES-CM input block is made by XORing the master salt with the encryption key label 0x06 concatenated with (index DIV kdr). then you pad on the right with two null octets, which does the multiply-by-2^16 operation (see Section 4.3.3 of [RFC3711]) ✨. the result gets AES-CM-encrypted with the master key to get the cipher key.
index DIV kdr: 000000000000
label: 06
master salt: 0EC675AD498AFEEBB6960B3AABE6
--------------------------------------------------
XOR: 0EC675AD498AFEEDB6960B3AABE6 (x, PRF input)
x*2^16: 0EC675AD498AFEEDB6960B3AABE60000 (AES-CM input)
hdr. cipher key: 549752054D6FB708622C4A2E596A1B93 (AES-CM output)next up is the cipher salt 💖. same deal: the AES-CM input block is the master salt XORed with the encryption salt label, then padded and encrypted just like above.
index DIV kdr: 000000000000
label: 07
master salt: 0EC675AD498AFEEBB6960B3AABE6
--------------------------------------------------
XOR: 0EC675AD498AFEECB6960B3AABE6 (x, PRF input)
x*2^16: 0EC675AD498AFEECB6960B3AABE60000 (AES-CM input)
AB01818174C40D39A3781F7C2D270733 (AES-CM ouptut)
hdr. cipher salt: AB01818174C40D39A3781F7C2D27A.2. Header Encryption Test Vectors Using AES-CM 🦋💅
this part has test vectors for encrypting a header extension with the AES_CM cryptographic transform 🌸. it uses the header cipher key and header cipher salt from Appendix A.1. the header extension rides in an SRTP-encrypted RTP packet with SSRC 0xCAFEBABE, sequence number 0x1234, and an all-zero rollover counter.
Session Key: 549752054D6FB708622C4A2E596A1B93
Session Salt: AB01818174C40D39A3781F7C2D27
SSRC: CAFEBABE
Rollover Counter: 00000000
Sequence Number: 1234
----------------------------------------------
Init. Counter: AB018181BE3AB787A3781F7C3F130000the SRTP session was negotiated to say header extension ID values 1, 3, and 4 are encrypted 🔐.
here's the header extension being encrypted, in hexadecimal (spaces added so you can see the internal structure 🧚):
17 414273A475262748 22 0000C8 30 8E 46 55996386B395FB 00this header extension is 24 bytes long ✨. (its values are meant to be plausible values of the header extension elements in Section 3.1, but the specific meaning doesn't matter for the example.) the "defined by profile" and "length" fields, which here are BEDE 0006 in hexadecimal, are NOT included in the encryption process 🙈. wait, sorry, not capitals, these are just not included, sorry bestie 💀.
the matching encryption mask, which selects the bodies of header extensions 1, 2, and 4 (the mask in Figure 2), is:
00 FFFFFFFFFFFFFFFF 00 000000 00 FF 00 FFFFFFFFFFFFFF 00last step 👑: compute the keystream from the session key and the initial counter, apply the mask to the keystream, and then XOR the keystream with the plaintext:
Initial keystream: 1E19C8E1D481C779549ED1617AAA1B7A
FC0D933AE7ED6CC8
Mask (hex): 00FFFFFFFFFFFFFFFF0000000000FF00
FFFFFFFFFFFFFF00
Masked keystream: 0019C8E1D481C7795400000000001B00
FC0D933AE7ED6C00
Plaintext: 17414273A475262748220000C8308E46
55996386B395FB00
Ciphertext: 17588A9270F4E15E1C220000C8309546
A994F0BC54789700Author's Address 🖊️
Jonathan Lennox
Vidyo, Inc.
433 Hackensack Avenue
Seventh Floor
Hackensack, NJ 07601
US
EMail: jonathan@vidyo.com📦 where this page comes from
- ietf: rfc6904 2013-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms