draft-ietf-avtcore-srtp-encrypted-header-ext-05.txt   rfc6904.txt 
AVTCORE J. Lennox Internet Engineering Task Force (IETF) J. Lennox
Internet-Draft Vidyo Request for Comments: 6904 Vidyo
Updates: 3711 (if approved) February 8, 2013 Updates: 3711 April 2013
Intended status: Standards Track Category: Standards Track
Expires: August 12, 2013 ISSN: 2070-1721
Encryption of Header Extensions in the Secure Real-Time Transport Encryption of Header Extensions
Protocol (SRTP) in the Secure Real-time Transport Protocol (SRTP)
draft-ietf-avtcore-srtp-encrypted-header-ext-05
Abstract Abstract
The Secure Real-Time Transport Protocol (SRTP) provides The Secure Real-time Transport Protocol (SRTP) provides
authentication, but not encryption, of the headers of Real-Time authentication, but not encryption, of the headers of Real-time
Transport Protocol (RTP) packets. However, RTP header extensions may Transport Protocol (RTP) packets. However, RTP header extensions may
carry sensitive information for which participants in multimedia carry sensitive information for which participants in multimedia
sessions want confidentiality. This document provides a mechanism, sessions want confidentiality. This document provides a mechanism,
extending the mechanisms of SRTP, to selectively encrypt RTP header extending the mechanisms of SRTP, to selectively encrypt RTP header
extensions in SRTP. extensions in SRTP.
This document updates RFC 3711, the Secure Real-Time Transport This document updates RFC 3711, the Secure Real-time Transport
Protocol specification, to require that all future SRTP encryption Protocol specification, to require that all future SRTP encryption
transforms specify how RTP header extensions are to be encrypted. transforms specify how RTP header extensions are to be encrypted.
Status of this Memo 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 This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on August 12, 2013. 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.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Encryption Mechanism . . . . . . . . . . . . . . . . . . . . . 4 3. Encryption Mechanism . . . . . . . . . . . . . . . . . . . . 4
3.1. Example Encryption Mask . . . . . . . . . . . . . . . . . 6 3.1. Example Encryption Mask . . . . . . . . . . . . . . . . . 6
3.2. Header Extension Keystream Generation for Existing 3.2. Header Extension Keystream Generation for Existing
Encryption Transforms . . . . . . . . . . . . . . . . . . 7 Encryption Transforms . . . . . . . . . . . . . . . . . . 7
3.3. Header Extension Keystream Generation for Future 3.3. Header Extension Keystream Generation for Future
Encryption Transforms . . . . . . . . . . . . . . . . . . 7 Encryption Transforms . . . . . . . . . . . . . . . . . . 8
4. Signaling (Setup) Information . . . . . . . . . . . . . . . . 7 4. Signaling (Setup) Information . . . . . . . . . . . . . . . . 8
4.1. Backward compatibility . . . . . . . . . . . . . . . . . . 9 4.1. Backward Compatibility . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 13
A.1. Key derivation test vectors . . . . . . . . . . . . . . . 12 A.1. Key Derivation Test Vectors . . . . . . . . . . . . . . . 13
A.2. Header Encryption Test Vectors using AES-CM . . . . . . . 13 A.2. Header Encryption Test Vectors Using AES-CM . . . . . . . 14
Appendix B. Changes From Earlier Versions . . . . . . . . . . . . 14
B.1. Changes from draft-ietf-avtcore -04 . . . . . . . . . . . 14
B.2. Changes from draft-ietf-avtcore -03 . . . . . . . . . . . 15
B.3. Changes from draft-ietf-avtcore -02 . . . . . . . . . . . 15
B.4. Changes from draft-ietf-avtcore -01 . . . . . . . . . . . 15
B.5. Changes from draft-ietf-avtcore -00 . . . . . . . . . . . 16
B.6. Changes from draft-lennox-avtcore -00 . . . . . . . . . . 16
B.7. Changes from draft-lennox-avt -02 . . . . . . . . . . . . 16
B.8. Changes From Individual Submission Draft -01 . . . . . . . 16
B.9. Changes From Individual Submission Draft -00 . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The Secure Real-Time Transport Protocol [RFC3711] specification The Secure Real-time Transport Protocol [RFC3711] specification
provides confidentiality, message authentication, and replay provides confidentiality, message authentication, and replay
protection for multimedia payloads sent using the Real-Time Protocol protection for multimedia payloads sent using the Real-time Protocol
(RTP) [RFC3550]. However, in order to preserve RTP header (RTP) [RFC3550]. However, in order to preserve RTP header
compression efficiency, SRTP provides only authentication and replay compression efficiency, SRTP provides only authentication and replay
protection for the headers of RTP packets, not confidentiality. protection for the headers of RTP packets, not confidentiality.
For the standard portions of an RTP header, this does not normally For the standard portions of an RTP header, providing only
present a problem, as the information carried in an RTP header does authentication and replay protection does not normally present a
not provide much information beyond that which an attacker could problem, as the information carried in an RTP header does not provide
infer by observing the size and timing of RTP packets. Thus, there much information beyond that which an attacker could infer by
is little need for confidentiality of the header information. 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 However, the security requirements can be different for information
header extensions. A number of recent proposals for header carried in RTP header extensions. A number of recent proposals for
extensions using the General Mechanism for RTP Header Extensions header extensions using the mechanism described in "A General
[RFC5285] carry information for which confidentiality could be Mechanism for RTP Header Extensions" [RFC5285] carry information for
desired or essential. Notably, two recent specifications ([RFC6464] which confidentiality could be desired or essential. Notably, two
and [RFC6465]) carry information about per-packet sound levels of the recent specifications ([RFC6464] and [RFC6465]) contain information
media data carried in the RTP payload, and exposing this to an about per-packet sound levels of the media data carried in the RTP
eavesdropper is unacceptable in many circumstances (as described in payload and specify that exposing this information to an eavesdropper
the respective RFCs' Security Considerations sections). 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 This document, therefore, defines a mechanism by which encryption can
be applied to RTP header extensions when they are transported using be applied to RTP header extensions when they are transported using
SRTP. As an RTP sender may wish some extension information to be 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 sent in the clear (for example, it may be useful for a network
monitoring device to be aware of RTP transmission time offsets monitoring device to be aware of RTP transmission time offsets
[RFC5450]), this mechanism can be selectively applied to a subset of [RFC5450]), this mechanism can be selectively applied to a subset of
the header extension elements carried in an SRTP packet. the header extension elements carried in an SRTP packet.
The mechanism defined by this document encrypts packets' header The mechanism defined by this document encrypts packets' header
extensions using the same cryptographic algorithms and parameters as extensions using the same cryptographic algorithms and parameters as
are used to encrypt the packets' RTP payloads. This document defines are used to encrypt the packets' RTP payloads. This document defines
how this is done for the encryption transforms defined in [RFC3711], how this is done for the encryption transforms defined in [RFC3711],
[RFC5669], and [RFC6188], the SRTP encryption transforms defined by [RFC5669], and [RFC6188], which are the SRTP encryption transforms
standards-track IETF documents at the time of this writing. It also defined by Standards Track RFCs at the time of this writing. It also
updates [RFC3711], to indicate that specifications of future SRTP updates [RFC3711] to indicate that specifications of future SRTP
encryption transforms must define how header extension encryption is encryption transforms must define how header extension encryption is
to be performed. to be performed.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119] and document are to be interpreted as described in RFC 2119 [RFC2119] and
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
3. Encryption Mechanism 3. Encryption Mechanism
Encrypted header extension elements are carried in the same manner as Encrypted header extension elements are carried in the same manner as
non-encrypted header extension elements, as defined by [RFC5285]. non-encrypted header extension elements, as defined by [RFC5285].
The (one- or two-byte) header of the extension elements is not The one- or two-byte header of the extension elements is not
encrypted, nor is any of the header extension padding. If multiple encrypted, nor is any of the header extension padding. If multiple
different header extension elements are being encrypted, they have different header extension elements are being encrypted, they have
separate element identifier values, just as they would if they were separate element identifier values, just as they would if they were
not encrypted; similarly, encrypted and non-encrypted header not encrypted. Similarly, encrypted and non-encrypted header
extension elements have separate identifier values. extension elements have separate identifier values.
Encrypted extension headers are only carried in packets encrypted Encrypted header extension elements are carried only in packets
using the Secure Real-Time Transport Protocol [RFC3711]. To encrypt encrypted using the Secure Real-time Transport Protocol [RFC3711].
(or decrypt) encrypted extension headers, an SRTP participant first To encrypt (or decrypt) encrypted header extension elements, an SRTP
uses the SRTP Key Derivation Algorithm, specified in Section 4.3.1 of participant first uses the SRTP key derivation algorithm, specified
[RFC3711], to generate header encryption and header salting keys, in Section 4.3.1 of [RFC3711], to generate header encryption and
using the same pseudo-random function family as are used for the key header salting keys, using the same pseudorandom function family as
derivation for the SRTP session. These keys are derived as follows: 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_he (SRTP header encryption): <label> = 0x06, n=n_e.
o k_hs (SRTP header salting key): <label> = 0x07, n=n_s. 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 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 encryption key and salting key are used as are used for the SRTP
payload. Additionally, the same master key, master salt, index, and payload. Additionally, the same master key, master salt, index, and
key_derivation_rate are used as are used for the SRTP payload. (Note key_derivation_rate are used as for the SRTP payload. (Note that
that since RTP headers, including extension headers, are since RTP headers, including header extensions, are authenticated in
authenticated in SRTP, no new authentication key is needed for SRTP, no new authentication key is needed for header extensions.)
extension headers.)
A header extension keystream is generated for each packet containing A header extension keystream is generated for each packet containing
encrypted header extension elements. The details of how this header encrypted header extension elements. The details of how this header
extension keystream is generated depend on the encryption transform extension keystream is generated depend on the encryption transform
that is used for the SRTP packet. For encryption transforms that that is used for the SRTP packet. For encryption transforms that
have been standardized as of the publication of this document, see have been standardized as of the date of publication of this
Section 3.2; for requirements for new transforms, see Section 3.3. document, see Section 3.2; for requirements for new transforms, see
Section 3.3.
Once the header extension keystream is generated, the SRTP After the header extension keystream is generated, the SRTP
participant then computes an encryption mask for the header participant then computes an encryption mask for the header
extension, identifying the portions of the header extension that are, extension, identifying the portions of the header extension that are,
or are to be, encrypted. (For an example of this procedure, see or are to be, encrypted. (For an example of this procedure, see
Section 3.1 below.) This encryption mask corresponds to the entire Section 3.1.) This encryption mask corresponds to the entire
payload of each header extension element that is encrypted. It does payload of each header extension element that is encrypted. It does
not include any non-encrypted header extension elements, any not include any non-encrypted header extension elements, any
extension element headers, or any padding octets. The encryption extension element headers, or any padding octets. The encryption
mask has all-bits-1 octets (i.e., hexadecimal 0xff) for header mask has all-bits-1 octets (i.e., hexadecimal 0xff) for header
extension octets which are to be encrypted, and all-bits-0 octets for extension octets that are to be encrypted and all-bits-0 octets for
header extension octets which are not to be. The set of extension header extension octets that are not to be encrypted. The set of
elements to be encrypted is communicated between the sender and the extension elements to be encrypted is communicated between the sender
receiver using the signaling mechanisms described in Section 4. and the receiver using the signaling mechanisms described in
Section 4.
This encryption mask is computed separately for every packet that This encryption mask is computed separately for every packet that
carries a header extension. Based on the non-encrypted portions of carries a header extension. Based on the non-encrypted portions of
the headers and the signaled list of encrypted extension elements, a the headers and the signaled list of encrypted extension elements, a
receiver can always determine the correct encryption mask for any receiver can always determine the correct encryption mask for any
encrypted header extension. encrypted header extension.
The SRTP participant bitwise-ANDs the encryption mask with the The SRTP participant bitwise-ANDs the encryption mask with the
keystream to produce a masked keystream. It then bitwise exclusive- keystream to produce a masked keystream. It then bitwise
ors the header extension with this masked keystream to produce the exclusive-ORs the header extension with this masked keystream to
ciphertext version of the header extension. (Thus, octets indicated produce the ciphertext version of the header extension. (Thus,
as all-bits-1 in the encrypted mask are encrypted, whereas those octets indicated as all-bits-1 in the encrypted mask are encrypted,
indicated as all-bits-0 are not.) whereas those indicated as all-bits-0 are not.)
The header extension encryption process does not include the "defined The header extension encryption process does not include the "defined
by profile" or "length" fields of the header extension, only the by profile" or "length" fields of the header extension, only the
field that [RFC3550] Section 5.3.1 calls "header extension" proper, field that Section 5.3.1 of [RFC3550] calls "header extension"
starting with the first [RFC5285] ID and length. Thus, both the proper, starting with the first [RFC5285] ID and length. Thus, both
encryption mask and the keystream begin at this point. the encryption mask and the keystream begin at this point.
This header extension encryption process could, equivalently, be This header extension encryption process could, equivalently, be
computed by considering the encryption mask as a mixture of the computed by considering the encryption mask as a mixture of the
encrypted and unencrypted headers, i.e. as encrypted and unencrypted headers, i.e., as
EncryptedHeader = (Encrypt(Key, Plaintext) AND MASK) OR EncryptedHeader = (Encrypt(Key, Plaintext) AND MASK) OR
(Plaintext AND (NOT MASK)) (Plaintext AND (NOT MASK))
where Encrypt is the encryption function, MASK is the encryption where Encrypt is the encryption function, MASK is the encryption
mask, and AND, OR, and NOT are bitwise operations. This formulation mask, and AND, OR, and NOT are bitwise operations. This formulation
of the encryption process might be preferred by implementations for of the encryption process might be preferred by implementations for
which encryption is performed by a separate module, and cannot easily which encryption is performed by a separate module and cannot be
be modified. modified easily.
The SRTP authentication tag is computed across the encrypted header The SRTP authentication tag is computed across the encrypted header
extension, i.e., the data that is actually transmitted on the wire. extension, i.e., the data that is actually transmitted on the wire.
Thus, header extension encryption MUST be done before the Thus, header extension encryption MUST be done before the
authentication tag is computed, and authentication tag validation authentication tag is computed, and authentication tag validation
MUST be done on the encrypted header extensions. For receivers, MUST be done on the encrypted header extensions. For receivers,
header extension decryption SHOULD be done only after the receiver header extension decryption SHOULD be done only after the receiver
has validated the packet's message authentication tag, and the has validated the packet's message authentication tag, and the
receiver MUST NOT take any actions based on decrypted headers that receiver MUST NOT take any actions based on decrypted headers, prior
could affect the security or proper functioning of the system, prior to validating the authentication tag, that could affect the security
to validating the authentication tag. or proper functioning of the system.
3.1. Example Encryption Mask 3.1. Example Encryption Mask
If a sender wished to send a header extension containing an encrypted If a sender wished to send a header extension containing an encrypted
SMPTE timecode [RFC5484] with ID 1, a plaintext transmission time SMPTE timecode [RFC5484] with ID 1, a plaintext transmission time
offset [RFC5450] with ID 2, an encrypted audio level indication offset [RFC5450] with ID 2, an encrypted audio level indication
[RFC6464] with ID 3, and an encrypted NTP Timestamp [RFC6051] with ID [RFC6464] with ID 3, and an encrypted NTP timestamp [RFC6051] with ID
4, the plaintext RTP header extension might look like this: 4, the plaintext RTP header extension might look like this:
0 1 2 3 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 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) | | ID=1 | len=7 | SMTPE timecode (long form) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMTPE timecode (continued) | | SMTPE timecode (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMTPE (cont'd)| ID=2 | len=2 | toffset | | SMTPE (cont'd)| ID=2 | len=2 | toffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| toffset (ct'd)| ID=3 | len=0 | audio level | ID=4 | len=6 | | toffset (ct'd)| ID=3 | len=0 | audio level | ID=4 | len=6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp (Variant B) | | NTP timestamp (Variant B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp (Variant B, cont.) | padding = 0 | | NTP timestamp (Variant B, cont'd) | padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Figure 1: Structure of Plaintext Example Header Extension
The corresponding encryption mask would then be: The corresponding encryption mask would then be:
0 1 2 3 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 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| |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|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| |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| |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|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| |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 Figure 2: Encryption Mask for Example Header Extension
In the mask, the octets corresponding to the payloads of the In the mask, the octets corresponding to the payloads of the
encrypted header extension elements are set to all-1 values, and encrypted header extension elements are set to all-1 values, and the
octets corresponding to non-encrypted header extension elements, octets corresponding to non-encrypted header extension elements,
element headers, and header extension padding are set to all-0 element headers, and header extension padding are set to all-zero
values. values.
3.2. Header Extension Keystream Generation for Existing Encryption 3.2. Header Extension Keystream Generation for Existing Encryption
Transforms Transforms
For the AES-CM and AES-f8 transforms [RFC3711], the SEED-CTR For the AES-CM and AES-f8 transforms [RFC3711], the SEED-CTR
transform [RFC5669], and the AES_192_CM and AES_256_CM transforms transform [RFC5669], and the AES_192_CM and AES_256_CM transforms
[RFC6188], the header extension keystream SHALL be generated for each [RFC6188], the header extension keystream SHALL be generated for each
packet containing encrypted header extension elements, using the same packet containing encrypted header extension elements using the same
encryption transform and Initialization Vector (IV) as is used for encryption transform and Initialization Vector (IV) as are used for
that packet's SRTP payload, except that the SRTP encryption and 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 salting keys k_e and k_s are replaced by the SRTP header encryption
and header salting keys k_he and k_hs, defined above, respectively. and header salting keys k_he and k_hs, respectively, as defined
above.
For the SEED-CCM and SEED-GCM transforms [RFC5669], the header For the SEED-CCM and SEED-GCM transforms [RFC5669], the header
extension keystream SHALL be generated using the algorithm specified extension keystream SHALL be generated using the algorithm specified
above for the SEED-CTR algorithm. (Because the AEAD transform used above for the SEED-CTR algorithm. (Because the Authenticated
on the payload in these algorithms includes the RTP header, including Encryption with Associated Data (AEAD) transform used on the payload
the RTP header extension, in its Associated Authenticated Data (AAD), in these algorithms includes the RTP header, including the RTP header
counter-mode encryption for the header extension is believed to be of extension, in its Associated Authenticated Data (AAD), counter-mode
equivalent cryptographic strength to the CCM and GCM transforms.) encryption for the header extension is believed to be of equivalent
cryptographic strength to the CCM and GCM transforms.)
For the NULL encryption transform [RFC3711], the header extension For the NULL encryption transform [RFC3711], the header extension
keystream SHALL be all-zero. keystream SHALL be all-zero.
3.3. Header Extension Keystream Generation for Future Encryption 3.3. Header Extension Keystream Generation for Future Encryption
Transforms Transforms
When new SRTP encryption transforms are defined, this document When new SRTP encryption transforms are defined, this document
updates [RFC3711] as follows: in addition to the rules specified in updates [RFC3711] as follows: in addition to the rules specified in
Section 6 of RFC 3711, the standard track RFC defining the new Section 6 of RFC 3711, the Standards Track RFC defining the new
transform MUST specify how the encryption transform is to be used transform MUST specify how the encryption transform is to be used
with header extension encryption. with header extension encryption.
It is RECOMMENDED that new transformations follow the same mechanisms It is RECOMMENDED that new transformations follow the same mechanisms
as are defined in Section 3.2, if these are applicable and are as are defined in Section 3.2 of this document if they are applicable
believed to be cryptographically adequate for the transform in and are believed to be cryptographically adequate for the transform
question. in question.
4. Signaling (Setup) Information 4. Signaling (Setup) Information
Encrypted header extension elements are signaled in the SDP extmap Encrypted header extension elements are signaled in the Session
attribute, using the URI "urn:ietf:params:rtp-hdrext:encrypt", Description Protocol (SDP) extmap attribute using the URI
followed by the URI of the header extension element being encrypted "urn:ietf:params:rtp-hdrext:encrypt" followed by the URI of the
as well as any extensionattributes that extension normally takes. header extension element being encrypted, as well as any
Figure 3 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] extensionattributes that extension normally takes. Figure 3 gives a
showing this grammar extension, extending the grammar defined in formal Augmented Backus-Naur Form (ABNF) [RFC5234] showing this
[RFC5285]. 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 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 %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 ; "urn:ietf:params:rtp-hdrext:encrypt" in lower case
extmap /= mapentry SP enc-extensionname SP extensionname extmap =/ mapentry SP enc-extensionname SP extensionname
[SP extensionattributes] [SP extensionattributes]
; extmap, mapentry, extensionname and extensionattributes ; extmap, mapentry, extensionname, and extensionattributes
; are defined in [RFC5285] ; are defined in [RFC5285]
Figure 3: Syntax of the "encrypt" extmap Figure 3: Syntax of the "encrypt" extmap
Thus, for example, to signal an SRTP session using encrypted SMPTE Thus, for example, to signal an SRTP session using encrypted SMPTE
timecodes [RFC5484], while simultaneously signaling plaintext timecodes [RFC5484], while simultaneously signaling plaintext
transmission time offsets [RFC5450], an SDP document could contain transmission time offsets [RFC5450], an SDP document could contain
(line breaks added for formatting): the text shown in Figure 4 (line breaks have been added for
formatting).
m=audio 49170 RTP/SAVP 0 m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32 \ a=crypto:1 AES_CM_128_HMAC_SHA1_32 \
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=extmap:1 urn:ietf:params:rtp-hdrext:encrypt \ a=extmap:1 urn:ietf:params:rtp-hdrext:encrypt \
urn:ietf:params:rtp-hdrext:smpte-tc 25@600/24 urn:ietf:params:rtp-hdrext:smpte-tc 25@600/24
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
Figure 4 Figure 4: Sample SDP Document Offering Encrypted Headers
This example uses SDP Security Descriptions [RFC4568] for SRTP This example uses SDP security descriptions [RFC4568] for SRTP
keying, but this is merely for illustration; any SRTP keying keying, but this is merely for illustration. Any SRTP keying
mechanism to establish session keys will work. mechanism to establish session keys will work.
The extmap SDP attribute is defined in [RFC5285] as being either a The extmap SDP attribute is defined in [RFC5285] as being either a
session or media attribute. If the extmap for an encrypted header session or media attribute. If the extmap for an encrypted header
extension is specified as a media attribute, it MUST only be extension is specified as a media attribute, it MUST be specified
specified for media which use SRTP-based RTP profiles. If such an only for media that use SRTP-based RTP profiles. If such an extmap
extmap is specified as a session attribute, there MUST be at least is specified as a session attribute, there MUST be at least one media
one media in the SDP session which uses an SRTP-based RTP profile; in the SDP session that uses an SRTP-based RTP profile. The session-
the session-level extmap applies to all the SRTP-based media in the level extmap applies to all the SRTP-based media in the session and
session, and MUST be ignored for all other (non-SRTP or non-RTP) MUST be ignored for all other (non-SRTP or non-RTP) media.
media.
The "urn:ietf:params:rtp-hdrext:encrypt" extension MUST NOT be The "urn:ietf:params:rtp-hdrext:encrypt" extension MUST NOT be
recursively applied to itself. recursively applied to itself.
4.1. Backward compatibility 4.1. Backward Compatibility
Following the procedures in [RFC5285], an SDP endpoint which does not Following the procedures in [RFC5285], an SDP endpoint that does not
understand the "urn:ietf:params:rtp-hdrext:encrypt" extension URI understand the "urn:ietf:params:rtp-hdrext:encrypt" extension URI
will ignore the extension, and (for SDP offer/answer) negotiate not will ignore the extension and, for SDP offer/answer, will negotiate
to use it. not to use it.
For backward compatibility with endpoints which do not implement this For backward compatibility with endpoints that do not implement this
specification, in a negotiated session (whether using offer/answer or specification, in a negotiated session (whether using offer/answer or
some other means), best-effort encryption of a header extension some other means), best-effort encryption of a header extension
element is possible: an endpoint MAY offer the same header extension element is possible: an endpoint MAY offer the same header extension
element both encrypted and unencrypted. An offerer MUST only offer element both encrypted and unencrypted. An offerer MUST offer only
best-effort negotiation when lack of confidentiality would be best-effort negotiation when lack of confidentiality would be
acceptable in the backward-compatible case. Answerers (or equivalent acceptable in the backward-compatible case. Answerers (or equivalent
peers in a negotiation) which understand header extension encryption peers in a negotiation) that understand header extension encryption
SHOULD choose the encrypted form of the offered header extension SHOULD choose the encrypted form of the offered header extension
element, and mark the unencrypted form "inactive", unless they have element and mark the unencrypted form "inactive", unless they have an
an explicit reason to prefer the unencrypted form. In all cases, explicit reason to prefer the unencrypted form. In all cases,
answerers MUST NOT negotiate the use of, and senders MUST NOT send, answerers MUST NOT negotiate the use of, and senders MUST NOT send,
both encrypted and unencrypted forms of the same header extension. both encrypted and unencrypted forms of the same header extension.
Note that, as always, users of best-effort encryption MUST be Note that, as always, users of best-effort encryption MUST be
cautious of bid-down attacks, where a man-in-the-middle attacker cautious of bid-down attacks, where a man-in-the-middle attacker
removes a higher-security option, forcing endpoints to negotiate a removes a higher-security option, forcing endpoints to negotiate a
lower-security one. Appropriate countermeasures depend on the lower-security one. Appropriate countermeasures depend on the
signaling protocol in use, but users can ensure, for example, that signaling protocol in use, but users can ensure, for example, that
signaling is integrity-protected. signaling is integrity-protected.
skipping to change at page 9, line 45 skipping to change at page 10, line 24
The security properties of header extension elements protected by the The security properties of header extension elements protected by the
mechanism in this document are equivalent to those for SRTP payloads. mechanism in this document are equivalent to those for SRTP payloads.
The mechanism defined in this document does not provide The mechanism defined in this document does not provide
confidentiality about which header extension elements are used for a confidentiality about which header extension elements are used for a
given SRTP packet, only for the content of those header extension given SRTP packet, only for the content of those header extension
elements. This appears to be in the spirit of SRTP itself, which elements. This appears to be in the spirit of SRTP itself, which
does not encrypt RTP headers. If this is a concern, an alternate does not encrypt RTP headers. If this is a concern, an alternate
mechanism would be needed to provide confidentiality. mechanism would be needed to provide confidentiality.
For the two-byte-header form of header extension elements (0x100x), For the two-byte-header form of header extension elements (0x100N,
this mechanism does not provide any protection to zero-length header where "N" is the appbits field), this mechanism does not provide any
extension elements (for which their presence or absence is the only protection to zero-length header extension elements (for which their
information they carry). It also does not provide any protection for presence or absence is the only information they carry). It also
the two-byte-headers' app bits (field 256, the lowest four bits of does not provide any protection for the appbits (field 256, the
the "defined by profile" field). Neither of these features are lowest four bits of the "defined by profile" field) of the two-byte
present in for one-byte-header form of header extension elements headers. Neither of these features is present in the one-byte-header
(0xBEDE), so these limitations do not apply in that case. form of header extension elements (0xBEDE), so these limitations do
not apply in that case.
This mechanism cannot protect RTP header extensions which do not use This mechanism cannot protect RTP header extensions that do not use
the mechanism defined in [RFC5285]. the mechanism defined in [RFC5285].
This document does not specify the circumstances in which extension This document does not specify the circumstances in which extension
header encryption should be used. Documents defining specific header header encryption should be used. Documents defining specific header
extension elements should provide guidance on when encryption is extension elements should provide guidance on when encryption is
appropriate for these elements. appropriate for these elements.
If a middlebox does not have access to the SRTP authentication keys, If a middlebox does not have access to the SRTP authentication keys,
it has no way to verify the authenticity of unencrypted RTP header it has no way to verify the authenticity of unencrypted RTP header
extension elements (or the unencrypted RTP header), even though it extension elements (or the unencrypted RTP header), even though it
can monitor them. Therefore, such middleboxes MUST treat such can monitor them. Therefore, such middleboxes MUST treat such
headers as untrusted and potentially generated by an attacker, in the headers as untrusted and potentially generated by an attacker, in the
same way as unauthenticated traffic. (This does not mean that same way as they treat unauthenticated traffic. (This does not mean
middleboxes cannot view and interpret such traffic, of course, only that middleboxes cannot view and interpret such traffic, of course,
that appropriate skepticism needs to be maintained about the results only that appropriate skepticism needs to be maintained about the
of such interpretation.). results of such interpretation.)
There is no mechanism defined to protect header extensions with There is no mechanism defined to protect header extensions with
different algorithms or encryption keys than are used to protect the different algorithms or encryption keys than are used to protect the
RTP payloads. In particular, it is not possible to provide RTP payloads. In particular, it is not possible to provide
confidentiality for a header extension while leaving the payload in confidentiality for a header extension while leaving the payload in
cleartext. cleartext.
The dangers of using weak or NULL authentication with SRTP, described The dangers of using weak or NULL authentication with SRTP, described
in [RFC3711] Section 9.5, apply to encrypted header extensions as in Section 9.5 of [RFC3711], apply to encrypted header extensions as
well. In particular, since some header extension elements will have well. In particular, since some header extension elements will have
some easily-guessed plaintext bits, strong authentication is REQUIRED some easily guessed plaintext bits, strong authentication is REQUIRED
if an attacker setting such bits could have a meaningful effect on if an attacker setting such bits could have a meaningful effect on
the behavior of the system. the behavior of the system.
The technique defined in this document can only be applied to The technique defined in this document can be applied only to
encryption transforms that work by generating a pseudorandom encryption transforms that work by generating a pseudorandom
keystream and bitwise exclusive-oring it with the plaintext, such as 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 CTR or f8. It will not work with ECB, CBC, or any other encryption
method that does not use a keystream. method that does not use a keystream.
6. IANA Considerations 6. IANA Considerations
This document defines a new extension URI to the RTP Compact Header This document defines a new extension URI to the RTP Compact Header
Extensions subregistry of the Real-Time Transport Protocol (RTP) Extensions subregistry of the Real-Time Transport Protocol (RTP)
Parameters registry, according to the following data: Parameters registry, according to the following data:
Extension URI: urn:ietf:params:rtp-hdrext:encrypt Extension URI: urn:ietf:params:rtp-hdrext:encrypt
Description: Encrypted extension header element Description: Encrypted header extension element
Contact: jonathan@vidyo.com Contact: jonathan@vidyo.com
Reference: RFC XXXX Reference: RFC 6904
(Note to the RFC-Editor: please replace "XXXX" with the number of
this document prior to publication as an RFC.)
7. Acknowledgments 7. Acknowledgments
Thanks to Benoit Claise, Roni Even, Stephen Farrell, Kevin Igoe, Joel Thanks to Benoit Claise, Roni Even, Stephen Farrell, Kevin Igoe, Joel
Jaeggli, David McGrew, Magnus Westerlund, David Singer, Robert Jaeggli, David McGrew, David Singer, Robert Sparks, Magnus
Sparks, Qin Wu, and Felix Wyss for their comments and suggestions in Westerlund, Qin Wu, and Felix Wyss for their comments and suggestions
the development of this specification. in the development of this specification.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
skipping to change at page 12, line 14 skipping to change at page 12, line 31
8.2. Informative References 8.2. Informative References
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in
RTP Streams", RFC 5450, March 2009. RTP Streams", RFC 5450, March 2009.
[RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", RFC
RFC 5484, March 2009. 5484, March 2009.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, November 2010. Flows", RFC 6051, November 2010.
[RFC6464] Lennox, J., Ivov, E., and E. Marocco, "A Real-time [RFC6464] Lennox, J., Ivov, E., and E. Marocco, "A Real-time
Transport Protocol (RTP) Header Extension for Client-to- Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", RFC 6464, December 2011. Mixer Audio Level Indication", RFC 6464, December 2011.
[RFC6465] Ivov, E., Marocco, E., and J. Lennox, "A Real-time [RFC6465] Ivov, E., Marocco, E., and J. Lennox, "A Real-time
Transport Protocol (RTP) Header Extension for Mixer-to- Transport Protocol (RTP) Header Extension for Mixer-to-
Client Audio Level Indication", RFC 6465, December 2011. Client Audio Level Indication", RFC 6465, December 2011.
Appendix A. Test Vectors Appendix A. Test Vectors
A.1. Key derivation test vectors A.1. Key Derivation Test Vectors
This section provides test data for the header extension key This section provides test data for the header extension key
derivation function, using AES-128 in Counter Mode. (The algorithms derivation function, using AES-128 in Counter Mode. (The algorithms
and keys used are the same as those for the the test vectors in and keys used are the same as those for the test vectors in Appendix
Appendix B.3 of [RFC3711].) B.3 of [RFC3711].)
The inputs to the key derivation function are the 16-octet master key
and the 14-octet master salt:
The inputs to the key derivation function are the 16 octet master key
and the 14 octet master salt:
master key: E1F97A0D3E018BE0D64FA32C06DE4139 master key: E1F97A0D3E018BE0D64FA32C06DE4139
master salt: 0EC675AD498AFEEBB6960B3AABE6 master salt: 0EC675AD498AFEEBB6960B3AABE6
Following [RFC3711], the input block for AES-CM is generated by Following [RFC3711], the input block for AES-CM is generated by
exclusive-oring the master salt with the concatenation of the exclusive-ORing the master salt with the concatenation of the
encryption key label 0x06 with (index DIV kdr), then padding on 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 right with two null octets, which implements the multiply-by-2^16
operation, see Section 4.3.3 of [RFC3711]). The resulting value is 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. then AES-CM-encrypted using the master key to get the cipher key.
index DIV kdr: 000000000000 index DIV kdr: 000000000000
label: 06 label: 06
master salt: 0EC675AD498AFEEBB6960B3AABE6 master salt: 0EC675AD498AFEEBB6960B3AABE6
-------------------------------------------------- --------------------------------------------------
xor: 0EC675AD498AFEEDB6960B3AABE6 (x, PRF input) XOR: 0EC675AD498AFEEDB6960B3AABE6 (x, PRF input)
x*2^16: 0EC675AD498AFEEDB6960B3AABE60000 (AES-CM input) x*2^16: 0EC675AD498AFEEDB6960B3AABE60000 (AES-CM input)
hdr. cipher key: 549752054D6FB708622C4A2E596A1B93 (AES-CM output) hdr. cipher key: 549752054D6FB708622C4A2E596A1B93 (AES-CM output)
Next, we show how the cipher salt is generated. The input block for 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 AES-CM is generated by exclusive-ORing the master salt with the
concatenation of the encryption salt label. That value is padded and concatenation of the encryption salt label. That value is padded and
encrypted as above. encrypted as above.
index DIV kdr: 000000000000 index DIV kdr: 000000000000
label: 07 label: 07
master salt: 0EC675AD498AFEEBB6960B3AABE6 master salt: 0EC675AD498AFEEBB6960B3AABE6
-------------------------------------------------- --------------------------------------------------
xor: 0EC675AD498AFEECB6960B3AABE6 (x, PRF input) XOR: 0EC675AD498AFEECB6960B3AABE6 (x, PRF input)
x*2^16: 0EC675AD498AFEECB6960B3AABE60000 (AES-CM input) x*2^16: 0EC675AD498AFEECB6960B3AABE60000 (AES-CM input)
AB01818174C40D39A3781F7C2D270733 (AES-CM ouptut) AB01818174C40D39A3781F7C2D270733 (AES-CM ouptut)
hdr. cipher salt: AB01818174C40D39A3781F7C2D27 hdr. cipher salt: AB01818174C40D39A3781F7C2D27
A.2. Header Encryption Test Vectors using AES-CM A.2. Header Encryption Test Vectors Using AES-CM
This section provides test vectors for the encryption of a header This section provides test vectors for the encryption of a header
extension, using the AES_CM cryptographic transform. extension using the AES_CM cryptographic transform.
The header extension is encrypted using the header cipher key and The header extension is encrypted using the header cipher key and
header cipher salt computed in Appendix A.1. The header extension is header cipher salt computed in Appendix A.1. The header extension is
carried in an SRTP-encrypted RTP packet with SSRC 0xCAFEBABE, carried in an SRTP-encrypted RTP packet with SSRC 0xCAFEBABE,
sequence number 0x1234, and an all-zero rollover counter. sequence number 0x1234, and an all-zero rollover counter.
Session Key: 549752054D6FB708622C4A2E596A1B93 Session Key: 549752054D6FB708622C4A2E596A1B93
Session Salt: AB01818174C40D39A3781F7C2D27 Session Salt: AB01818174C40D39A3781F7C2D27
SSRC: CAFEBABE SSRC: CAFEBABE
Rollover Counter: 00000000 Rollover Counter: 00000000
Sequence Number: 1234 Sequence Number: 1234
---------------------------------------------- ----------------------------------------------
Init. Counter: AB018181BE3AB787A3781F7C3F130000 Init. Counter: AB018181BE3AB787A3781F7C3F130000
The SRTP session was negotiated to indicate that header extension ID The SRTP session was negotiated to indicate that header extension ID
values 1, 3 and 4 are encrypted. values 1, 3, and 4 are encrypted.
In hexadecimal, the header extension being encrypted is (spaces added In hexadecimal, the header extension being encrypted is as follows
to show the internal structure of the header extension): (spaces have been added to show the internal structure of the header
extension):
17 414273A475262748 22 0000C8 30 8E 46 55996386B395FB 00 17 414273A475262748 22 0000C8 30 8E 46 55996386B395FB 00
This header extension is 24 bytes long. (Its values are intended to This header extension is 24 bytes long. (Its values are intended to
represent plausible values of the header extension elements shown in represent plausible values of the header extension elements shown in
Section 3.1, but their specific meaning is not important for the Section 3.1, but their specific meaning is not important for the
example.) The header extension "defined by profile" and "length" example.) The header extension "defined by profile" and "length"
fields, which in this case are BEDE 0006 in hexadecimal, are not fields, which in this case are BEDE 0006 in hexadecimal, are not
included in the encryption process. included in the encryption process.
In hexadecimal, the corresponding encryption mask selecting the In hexadecimal, the corresponding encryption mask selecting the
bodies of header extensions 1, 2, and 4 (corresponding to the mask in bodies of header extensions 1, 2, and 4 (corresponding to the mask in
Figure 2) is: Figure 2) is:
00 FFFFFFFFFFFFFFFF 00 000000 00 FF 00 FFFFFFFFFFFFFF 00 00 FFFFFFFFFFFFFFFF 00 000000 00 FF 00 FFFFFFFFFFFFFF 00
Finally, we compute the keystream from the session key and the Finally, we compute the keystream from the session key and the
initial counter, apply the mask to the keystream, and then xor the initial counter, apply the mask to the keystream, and then exclusive-
keystream with the plaintext: OR the keystream with the plaintext:
Initial keystream: 1E19C8E1D481C779549ED1617AAA1B7A Initial keystream: 1E19C8E1D481C779549ED1617AAA1B7A
FC0D933AE7ED6CC8 FC0D933AE7ED6CC8
Mask (Hex): 00FFFFFFFFFFFFFFFF0000000000FF00 Mask (hex): 00FFFFFFFFFFFFFFFF0000000000FF00
FFFFFFFFFFFFFF00 FFFFFFFFFFFFFF00
Masked keystream: 0019C8E1D481C7795400000000001B00 Masked keystream: 0019C8E1D481C7795400000000001B00
FC0D933AE7ED6C00 FC0D933AE7ED6C00
Plaintext: 17414273A475262748220000C8308E46 Plaintext: 17414273A475262748220000C8308E46
55996386B395FB00 55996386B395FB00
Ciphertext: 17588A9270F4E15E1C220000C8309546 Ciphertext: 17588A9270F4E15E1C220000C8309546
A994F0BC54789700 A994F0BC54789700
Appendix B. Changes From Earlier Versions
Note to the RFC-Editor: please remove this section prior to
publication as an RFC.
B.1. Changes from draft-ietf-avtcore -04
o Clarified that simultaneous offer of encrypted and unencrypted
headers is only to be used for backward compatibility, and that
endpoints must never actually negotiate or send encrypted and
unencrypted versions of the same header extension simultaneously.
o Clarified that the same master key, master salt, index, and key
derivation rate are to be used for the header keys and salt as for
the payload keys.
o Added a paragraph to the security consideration emphasizing the
dangers of weak or NULL authentication.
o Editorial changes.
o Added Benoit Claise, Stephen Farrell, and Joel Jaeggli to the
Acknowledgments.
B.2. Changes from draft-ietf-avtcore -03
o Modified the ABNF syntax to avoid rule recursion.
o Added Robert Sparks to the Acknowledgments.
B.3. Changes from draft-ietf-avtcore -02
o Clarified that the header extension encryption mask must be
calculated separately for each packet, and can always be derived
from the plaintext portions of the encrypted header extension.
o Presented an alternate formulation of the header extension
encryption process, so implementations can use their existing
encryption algorithms unmodified.
o Added a security consideration emphasizing that this mechanism
must only be used with keystream-based encryption algorithms.
B.4. Changes from draft-ietf-avtcore -01
o Made the draft update RFC 3711, and added a section specifying
that all future SRTP encryption transforms must specify how header
extension encryption is to be done.
o Explicitly distinguished the processing of existing encryption
transforms from future ones.
o Clarified description of the process by which the encryption mask
is applied, and that encryption does not apply to the header
extension "defined by profile" or "length" fields.
o Defined how header extension encryption is to be done with the
SEED algorithms defined in RFC 5669, and with the NULL algorithm.
o Added ABNF grammar for the SDP syntax.
o Clarified that header extension encryption must not be applied to
itself.
o Expanded discussion of bid-down attacks.
o Pointed out that this mechanism can't protect non-RFC5285 header
extensions, and that there's no way to give different protection
to header extensions than to payloads.
o Updated references to now-published RFCs.
o Editorial clarifications.
o Added Magnus Westerlund to the Acknowledgments.
B.5. Changes from draft-ietf-avtcore -00
o Clarified usage of Key Derivation Algorithm
o Provided non-normative guidance for how to use this mechanism with
Authenticated Encryption with Associated Data (AEAD) transforms.
o Corrected SMPTE Timecode header extension element in example
header extension (it's eight bytes, not sixteen). Added an NTP
timestamp to the example to fill it back out to original size.
o Specified applicability of the extmap attribute if it's specified
as a session-level attribute.
o Added description of backward compatibility, including a
description of how you can negotiate best-effort encryption.
o Added a note to the security considerations about the dangers for
middleboxes observing unencrypted headers (both header extension
elements and RTP headers) without being able to verify the
authentication keys.
o Added test vectors.
o Added acknowledgments section.
B.6. Changes from draft-lennox-avtcore -00
o Published as working group item.
o Added discussion of limitations when used with the two-byte-header
form of header extension elements.
o Added open issue about how to use this mechanism with
Authenticated Encryption with Associated Data (AEAD) transforms.
o Updated references.
B.7. Changes from draft-lennox-avt -02
o Retargeted at AVTCORE working group.
o Updated references.
B.8. Changes From Individual Submission Draft -01
o Minor editorial changes.
B.9. Changes From Individual Submission Draft -00
o Clarified description of encryption mask creation.
o Added example encryption mask.
o Editorial changes.
Author's Address Author's Address
Jonathan Lennox Jonathan Lennox
Vidyo, Inc. Vidyo, Inc.
433 Hackensack Avenue 433 Hackensack Avenue
Seventh Floor Seventh Floor
Hackensack, NJ 07601 Hackensack, NJ 07601
US US
Email: jonathan@vidyo.com EMail: jonathan@vidyo.com
 End of changes. 84 change blocks. 
309 lines changed or deleted 198 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/