AVTCORE J. Lennox Internet-Draft Vidyo Intended status: Standards Track October 28, 2011 Expires: April 30, 2012 Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP) draft-ietf-avtcore-srtp-encrypted-header-ext-01 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. 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 April 30, 2012. Copyright Notice Copyright (c) 2011 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 Lennox Expires April 30, 2012 [Page 1] Internet-Draft Encrypted SRTP Header Extensions October 2011 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 . . . . . . . . . . . . . . . . . . . . . 3 3.1. Example Encryption Mask . . . . . . . . . . . . . . . . . 5 4. Signaling (Setup) Information . . . . . . . . . . . . . . . . 6 4.1. Backward compatibility . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 10 A.1. Key derivation test vectors . . . . . . . . . . . . . . . 10 A.2. Header Encryption Test Vectors using AES-CM . . . . . . . 11 Appendix B. Changes From Earlier Versions . . . . . . . . . . . . 12 B.1. Changes from draft-ietf-avtcore -00 . . . . . . . . . . . 12 B.2. Changes from draft-lennox-avtcore -00 . . . . . . . . . . 13 B.3. Changes from draft-lennox-avt -02 . . . . . . . . . . . . 13 B.4. Changes From Individual Submission Draft -01 . . . . . . . 13 B.5. Changes From Individual Submission Draft -00 . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Lennox Expires April 30, 2012 [Page 2] Internet-Draft Encrypted SRTP Header Extensions October 2011 1. Introduction The Secure Real-Time Transport Protocol [RFC3711] specification provides confidentiality, message authentication, and replay protection for multimedia payloads sent using of 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 drafts ([I-D.ietf-avtext-client-to-mixer-audio-level] and [I-D.ietf-avtext-mixer-to-client-audio-level]) carry information about per-packet sound levels of the media data carried in the RTP payload, and exposing this to an eavesdropper may be 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. 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 Lennox Expires April 30, 2012 [Page 3] Internet-Draft Encrypted SRTP Header Extensions October 2011 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):