diff options
Diffstat (limited to 'doc/rfc/rfc6904.txt')
| -rw-r--r-- | doc/rfc/rfc6904.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc6904.txt b/doc/rfc/rfc6904.txt new file mode 100644 index 0000000..4c30a4f --- /dev/null +++ b/doc/rfc/rfc6904.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Lennox +Request for Comments: 6904 Vidyo +Updates: 3711 April 2013 +Category: Standards Track +ISSN: 2070-1721 + + + Encryption of Header Extensions + in the Secure Real-time Transport Protocol (SRTP) + +Abstract + + The Secure Real-time Transport Protocol (SRTP) provides + authentication, but not encryption, of the headers of Real-time + Transport Protocol (RTP) packets. However, RTP header extensions may + carry sensitive information for which participants in multimedia + sessions want confidentiality. This document provides a mechanism, + extending the mechanisms of SRTP, to selectively encrypt RTP header + extensions in SRTP. + + This document updates RFC 3711, the Secure Real-time Transport + Protocol specification, to require that all future SRTP encryption + transforms specify how RTP header extensions are to be encrypted. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6904. + + + + + + + + + + + + + + +Lennox Standards Track [Page 1] + +RFC 6904 Encrypted SRTP Header Extensions April 2013 + + +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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided 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 . . . . . . . 14 + + + + + + + + + + + + + + + +Lennox Standards Track [Page 2] + +RFC 6904 Encrypted SRTP Header Extensions April 2013 + + +1. Introduction + + The Secure Real-time Transport Protocol [RFC3711] specification + provides confidentiality, message authentication, and replay + protection for multimedia payloads sent using the Real-time Protocol + (RTP) [RFC3550]. However, in order to preserve RTP header + compression efficiency, SRTP provides only authentication and replay + protection for the headers of RTP packets, not confidentiality. + + For the standard portions of an RTP header, providing only + authentication and replay protection does not normally present a + problem, as the information carried in an RTP header does not provide + much information beyond that which an attacker could infer by + observing the size and timing of RTP packets. Thus, there is little + need for confidentiality of the header information. + + However, the security requirements can be different for information + carried in RTP header extensions. A number of recent proposals for + header extensions using the mechanism described in "A General + Mechanism for RTP Header Extensions" [RFC5285] carry information for + which confidentiality could be desired or essential. Notably, two + recent specifications ([RFC6464] and [RFC6465]) contain information + about per-packet sound levels of the media data carried in the RTP + payload and specify that exposing this information to an eavesdropper + is unacceptable in many circumstances (as described in the Security + Considerations sections of those RFCs). + + This document, therefore, defines a mechanism by which encryption can + be applied to RTP header extensions when they are transported using + SRTP. As an RTP sender may wish some extension information to be + sent in the clear (for example, it may be useful for a network + monitoring device to be aware of RTP transmission time offsets + [RFC5450]), this mechanism can be selectively applied to a subset of + the header extension elements carried in an SRTP packet. + + The mechanism defined by this document encrypts packets' header + extensions using the same cryptographic algorithms and parameters as + are used to encrypt the packets' RTP payloads. This document defines + how this is done for the encryption transforms defined in [RFC3711], + [RFC5669], and [RFC6188], which are the SRTP encryption transforms + defined by Standards Track RFCs at the time of this writing. It also + updates [RFC3711] to indicate that specifications of future SRTP + encryption transforms must define how header extension encryption is + to be performed. + + + + + + + +Lennox Standards Track [Page 3] + +RFC 6904 Encrypted SRTP Header Extensions April 2013 + + +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] and + indicate requirement levels for compliant implementations. + +3. Encryption Mechanism + + Encrypted header extension elements are carried in the same manner as + non-encrypted header extension elements, as defined by [RFC5285]. + The one- or two-byte header of the extension elements is not + encrypted, nor is any of the header extension padding. If multiple + different header extension elements are being encrypted, they have + separate element identifier values, just as they would if they were + not encrypted. Similarly, encrypted and non-encrypted header + extension elements have separate identifier values. + + Encrypted header extension elements are carried only in packets + encrypted using the Secure Real-time Transport Protocol [RFC3711]. + To encrypt (or decrypt) encrypted header extension elements, an SRTP + participant first uses the SRTP key derivation algorithm, specified + in Section 4.3.1 of [RFC3711], to generate header encryption and + header salting keys, using the same pseudorandom function family as + is used for the key derivation for the SRTP session. These keys are + derived as follows: + + o k_he (SRTP header encryption): <label> = 0x06, n=n_e. + + o k_hs (SRTP header salting key): <label> = 0x07, n=n_s. + + where n_e and n_s are from the cryptographic context: the same size + encryption key and salting key are used as are used for the SRTP + payload. Additionally, the same master key, master salt, index, and + key_derivation_rate are used as for the SRTP payload. (Note that + since RTP headers, including header extensions, are authenticated in + SRTP, no new authentication key is needed for header extensions.) + + A header extension keystream is generated for each packet containing + encrypted header extension elements. The details of how this header + extension keystream is generated depend on the encryption transform + that is used for the SRTP packet. For encryption transforms that + have been standardized as of the date of publication of this + document, see Section 3.2; for requirements for new transforms, see + Section 3.3. + + + + + + +Lennox Standards Track [Page 4] + +RFC 6904 Encrypted SRTP Header Extensions April 2013 + + + After the header extension keystream is generated, the SRTP + participant then computes an encryption mask for the header + extension, identifying the portions of the header extension that are, + or are to be, encrypted. (For an example of this procedure, see + Section 3.1.) This encryption mask corresponds to the entire + payload of each header extension element that is encrypted. It does + not include any non-encrypted header extension elements, any + extension element headers, or any padding octets. The encryption + mask has all-bits-1 octets (i.e., hexadecimal 0xff) for header + extension octets that are to be encrypted and all-bits-0 octets for + header extension octets that are not to be encrypted. The set of + extension elements to be encrypted is communicated between the sender + and the receiver using the signaling mechanisms described in + Section 4. + + This encryption mask is computed separately for every packet that + carries a header extension. Based on the non-encrypted portions of + the headers and the signaled list of encrypted extension elements, a + receiver can always determine the correct encryption mask for any + encrypted header extension. + + The SRTP participant bitwise-ANDs the encryption mask with the + keystream to produce a masked keystream. It then bitwise + exclusive-ORs the header extension with this masked keystream to + produce the ciphertext version of the header extension. (Thus, + octets indicated as all-bits-1 in the encrypted mask are encrypted, + whereas those indicated as all-bits-0 are not.) + + The header extension encryption process does not include the "defined + by profile" or "length" fields of the header extension, only the + field that Section 5.3.1 of [RFC3550] calls "header extension" + proper, starting with the first [RFC5285] ID and length. Thus, both + the encryption mask and the keystream begin at this point. + + This header extension encryption process could, equivalently, be + computed by considering the encryption mask as a mixture of the + encrypted and unencrypted headers, i.e., as + + EncryptedHeader = (Encrypt(Key, Plaintext) AND MASK) OR + (Plaintext AND (NOT MASK)) + + where Encrypt is the encryption function, MASK is the encryption + mask, and AND, OR, and NOT are bitwise operations. This formulation + of the encryption process might be preferred by implementations for + which encryption is performed by a separate module and cannot be + modified easily. + + + + + +Lennox Standards Track [Page 5] + +RFC 6904 Encrypted SRTP Header Extensions April 2013 + + + The SRTP authentication tag is computed across the encrypted header + extension, i.e., the data that is actually transmitted on the wire. + Thus, header extension encryption MUST be done before the + authentication tag is computed, and authentication tag validation + MUST be done on the encrypted header extensions. For receivers, + header extension decryption SHOULD be done only after the receiver + has validated the packet's message authentication tag, and the + receiver MUST NOT take any actions based on decrypted headers, prior + to validating the authentication tag, that could affect the security + or proper functioning of the system. + +3.1. Example Encryption Mask + + If a sender wished to send a header extension containing 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 Extension + + + + + + + + + + + + + + + +Lennox Standards Track [Page 6] + +RFC 6904 Encrypted SRTP Header Extensions April 2013 + + + The corresponding 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 Extension + + In the mask, the octets corresponding to the payloads of the + encrypted header extension elements are set to all-1 values, and the + octets corresponding to 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 using the same + encryption transform and Initialization Vector (IV) as are used for + that packet's SRTP payload, except that the SRTP encryption and + salting keys k_e and k_s are replaced by 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. (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.) + + + + +Lennox Standards Track [Page 7] + +RFC 6904 Encrypted SRTP Header Extensions April 2013 + + + 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 are defined, this document + updates [RFC3711] as follows: in addition to the rules specified 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 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 are signaled in the Session + Description Protocol (SDP) extmap attribute using the URI + "urn:ietf:params:rtp-hdrext:encrypt" followed by the URI of the + header extension element being encrypted, as well as any + extensionattributes that extension normally takes. Figure 3 gives a + formal Augmented Backus-Naur Form (ABNF) [RFC5234] showing this + grammar extension, extending 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" extmap + + Thus, for example, to signal an SRTP session using encrypted SMPTE + timecodes [RFC5484], while simultaneously signaling plaintext + transmission time offsets [RFC5450], an SDP document could contain + the text shown in Figure 4 (line breaks have been added for + formatting). + + + + + + + +Lennox Standards Track [Page 8] + +RFC 6904 Encrypted SRTP Header Extensions April 2013 + + + 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 Headers + + This example uses SDP security descriptions [RFC4568] for SRTP + keying, but this is merely for illustration. Any SRTP keying + mechanism to establish 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 "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 do not 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. + + + + + + +Lennox Standards Track [Page 9] + +RFC 6904 Encrypted SRTP Header Extensions April 2013 + + + 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.) + + + + + +Lennox Standards Track [Page 10] + +RFC 6904 Encrypted SRTP Header Extensions April 2013 + + + 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. + + 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 + + This document defines a new extension URI to the RTP Compact Header + Extensions subregistry of the Real-Time Transport Protocol (RTP) + Parameters registry, according to the following data: + + Extension URI: urn:ietf:params:rtp-hdrext:encrypt + Description: Encrypted header extension element + Contact: jonathan@vidyo.com + Reference: RFC 6904 + +7. Acknowledgments + + Thanks 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 + in the development of this specification. + +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. + + + + +Lennox Standards Track [Page 11] + +RFC 6904 Encrypted SRTP Header Extensions April 2013 + + + [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. + + + + + + + + + + + + +Lennox Standards Track [Page 12] + +RFC 6904 Encrypted SRTP Header Extensions April 2013 + + +Appendix A. Test Vectors + +A.1. Key Derivation Test Vectors + + This section provides test data for the header extension key + derivation function, using AES-128 in Counter Mode. (The algorithms + and keys used are the same as those for the test vectors in Appendix + B.3 of [RFC3711].) + + The inputs to the key derivation function are the 16-octet master key + and the 14-octet master salt: + + master key: E1F97A0D3E018BE0D64FA32C06DE4139 + + master salt: 0EC675AD498AFEEBB6960B3AABE6 + + Following [RFC3711], the input block for AES-CM is generated by + exclusive-ORing the master salt with the concatenation of the + encryption key label 0x06 with (index DIV kdr), then padding on the + right with two null octets, which implements the multiply-by-2^16 + operation (see Section 4.3.3 of [RFC3711]). The resulting value is + then AES-CM-encrypted using 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, we show how the cipher salt is generated. The input block for + AES-CM is generated by exclusive-ORing the master salt with the + concatenation of the encryption salt label. That value is padded and + encrypted as above. + + + + + + + + + + + + + +Lennox Standards Track [Page 13] + +RFC 6904 Encrypted SRTP Header Extensions April 2013 + + + 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: AB01818174C40D39A3781F7C2D27 + +A.2. Header Encryption Test Vectors Using AES-CM + + This section provides test vectors for the encryption of a header + extension using the AES_CM cryptographic transform. + + The header extension is encrypted using the header cipher key and + header cipher salt computed in Appendix A.1. The header extension is + carried 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: AB018181BE3AB787A3781F7C3F130000 + + The SRTP session was negotiated to indicate that header extension ID + values 1, 3, and 4 are encrypted. + + In hexadecimal, the header extension being encrypted is as follows + (spaces have been added to show the internal structure of the header + extension): + + 17 414273A475262748 22 0000C8 30 8E 46 55996386B395FB 00 + + This header extension is 24 bytes long. (Its values are intended to + represent plausible values of the header extension elements shown in + Section 3.1, but their specific meaning is not important for the + example.) The header extension "defined by profile" and "length" + fields, which in this case are BEDE 0006 in hexadecimal, are not + included in the encryption process. + + + + +Lennox Standards Track [Page 14] + +RFC 6904 Encrypted SRTP Header Extensions April 2013 + + + In hexadecimal, the corresponding encryption mask selecting the + bodies of header extensions 1, 2, and 4 (corresponding to the mask in + Figure 2) is: + + 00 FFFFFFFFFFFFFFFF 00 000000 00 FF 00 FFFFFFFFFFFFFF 00 + + Finally, we compute the keystream from the session key and the + initial counter, apply the mask to the keystream, and then exclusive- + OR the keystream with the plaintext: + + Initial keystream: 1E19C8E1D481C779549ED1617AAA1B7A + FC0D933AE7ED6CC8 + Mask (hex): 00FFFFFFFFFFFFFFFF0000000000FF00 + FFFFFFFFFFFFFF00 + Masked keystream: 0019C8E1D481C7795400000000001B00 + FC0D933AE7ED6C00 + Plaintext: 17414273A475262748220000C8308E46 + 55996386B395FB00 + Ciphertext: 17588A9270F4E15E1C220000C8309546 + A994F0BC54789700 + +Author's Address + + Jonathan Lennox + Vidyo, Inc. + 433 Hackensack Avenue + Seventh Floor + Hackensack, NJ 07601 + US + + EMail: jonathan@vidyo.com + + + + + + + + + + + + + + + + + + + + +Lennox Standards Track [Page 15] + |