AVTCORE J. Lennox Internet-Draft Vidyo Updates: 3711 (if approved) January 3, 2013 Intended status: Standards Track Expires: July 7, 2013 Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP) draft-ietf-avtcore-srtp-encrypted-header-ext-04 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 7, 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 Lennox Expires July 7, 2013 [Page 1] Internet-Draft Encrypted SRTP Header Extensions January 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Encryption Mechanism . . . . . . . . . . . . . . . . . . . . . 4 3.1. Example Encryption Mask . . . . . . . . . . . . . . . . . 5 3.2. Header Extension Keystream Generation for Existing Encryption Transforms . . . . . . . . . . . . . . . . . . 7 3.3. Header Extension Keystream Generation for Future Encryption Transforms . . . . . . . . . . . . . . . . . . 7 4. Signaling (Setup) Information . . . . . . . . . . . . . . . . 7 4.1. Backward compatibility . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 12 A.1. Key derivation test vectors . . . . . . . . . . . . . . . 12 A.2. Header Encryption Test Vectors using AES-CM . . . . . . . 13 Appendix B. Changes From Earlier Versions . . . . . . . . . . . . 14 B.1. Changes from draft-ietf-avtcore -03 . . . . . . . . . . . 14 B.2. Changes from draft-ietf-avtcore -02 . . . . . . . . . . . 14 B.3. Changes from draft-ietf-avtcore -01 . . . . . . . . . . . 14 B.4. Changes from draft-ietf-avtcore -00 . . . . . . . . . . . 15 B.5. Changes from draft-lennox-avtcore -00 . . . . . . . . . . 15 B.6. Changes from draft-lennox-avt -02 . . . . . . . . . . . . 15 B.7. Changes From Individual Submission Draft -01 . . . . . . . 15 B.8. Changes From Individual Submission Draft -00 . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Lennox Expires July 7, 2013 [Page 2] Internet-Draft Encrypted SRTP Header Extensions January 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, this 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, this is not necessarily true for information carried in RTP header extensions. A number of recent proposals for header extensions using the General Mechanism for RTP Header Extensions [RFC5285] carry information for which confidentiality could be desired or essential. Notably, two recent specifications ([RFC6464] and [RFC6465]) carry information about per-packet sound levels of the media data carried in the RTP payload, and exposing this to an eavesdropper is unacceptable in many circumstances. 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], the SRTP encryption transforms defined by standards-track IETF documents 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. 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 Lennox Expires July 7, 2013 [Page 3] Internet-Draft Encrypted SRTP Header Extensions January 2013 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 extension headers are only carried in packets encrypted using the Secure Real-Time Transport Protocol [RFC3711]. To encrypt (or decrypt) encrypted extension headers, 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 pseudo-random function family as are used for the key derivation for the SRTP session. These keys are derived as follows: o k_he (SRTP header encryption):