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):