draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt   draft-ietf-avtcore-srtp-encrypted-header-ext-01.txt 
AVTCORE J. Lennox AVTCORE J. Lennox
Internet-Draft Vidyo Internet-Draft Vidyo
Intended status: Standards Track June 1, 2011 Intended status: Standards Track October 28, 2011
Expires: December 3, 2011 Expires: April 30, 2012
Encryption of Header Extensions in the Secure Real-Time Transport Encryption of Header Extensions in the Secure Real-Time Transport
Protocol (SRTP) Protocol (SRTP)
draft-ietf-avtcore-srtp-encrypted-header-ext-00 draft-ietf-avtcore-srtp-encrypted-header-ext-01
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.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 3, 2011. This Internet-Draft will expire on April 30, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Encryption Mechanism . . . . . . . . . . . . . . . . . . . . . 3 3. Encryption Mechanism . . . . . . . . . . . . . . . . . . . . . 3
3.1. Example Encryption Mask . . . . . . . . . . . . . . . . . . 5 3.1. Example Encryption Mask . . . . . . . . . . . . . . . . . 5
4. Signaling (Setup) Information . . . . . . . . . . . . . . . . . 6 4. Signaling (Setup) Information . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4.1. Backward compatibility . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
Appendix B. Open issues . . . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix C. Changes From Earlier Versions . . . . . . . . . . . . 8 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 10
C.1. Changes from draft-lennox-avtcore -00 . . . . . . . . . . . 9 A.1. Key derivation test vectors . . . . . . . . . . . . . . . 10
C.2. Changes from draft-lennox-avt -02 . . . . . . . . . . . . . 9 A.2. Header Encryption Test Vectors using AES-CM . . . . . . . 11
C.3. Changes From Individual Submission Draft -01 . . . . . . . 9 Appendix B. Changes From Earlier Versions . . . . . . . . . . . . 12
C.4. Changes From Individual Submission Draft -00 . . . . . . . 9 B.1. Changes from draft-ietf-avtcore -00 . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 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
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 of the Real-Time protection for multimedia payloads sent using of the Real-Time
Protocol (RTP) [RFC3550]. However, in order to preserve RTP header Protocol (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.
skipping to change at page 4, line 10 skipping to change at page 4, line 10
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.
To encrypt (or decrypt) an encrypted extension header, an SRTP Encrypted extension headers are only carried in packets encrypted
participant first generates a keystream for the SRTP extension using the Secure Real-Time Transport Protocol [RFC3711]. To encrypt
header. This keystream is generated in the same manner as the (or decrypt) encrypted extension headers, an SRTP participant first
encryption keystream for the corresponding SRTP payload, except the uses the SRTP Key Derivation Algorithm, specified in Section 4.3.1 of
the SRTP encryption and salting keys k_e and k_s are replaced by the [RFC3711], to generate header encryption and header salting keys,
keys k_he and k_hs, respectively. The keys k_he and k_hs are using the same pseudo-random function family as are used for the key
computed in the same manner as k_e and k_s, except that the <label> derivation for the SRTP session. These keys are derived as follows:
values used are 0x06 for k_he and and 0x07 for k_hs. (Note that o k_he (SRTP header encryption): <label> = 0x06, n=n_e.
since RTP headers, including extension headers, are authenticated in o k_hs (SRTP header salting key): <label> = 0x07, n=n_s.
SRTP, no new authentication key is needed for extension headers.) 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. (Note that since RTP headers, including extension headers,
are authenticated in SRTP, no new authentication key is needed for
extension headers.)
The SRTP participant then computes an encryption mask for the header For SRTP encryption transforms that operate by generating a
extension, identifying the portions of the header extension that are, keystream, a header keystream is generated for each packet containing
or are to be, encrypted. This encryption mask corresponds to the an encrypted header, using the same encryption transform and
entire payload of each header extension element that is encrypted. Initialization Vector (IV) as is used for the SRTP payload, except
It does not include any non-encrypted header extension elements, any that the SRTP encryption and salting keys k_e and k_s are replaced by
extension element headers, or any padding octets. The encryption the SRTP header encryption and header salting keys k_he and k_hs,
mask has all-bits-1 octets (i.e., hexadecimal 0xff) for header respectively.
extension octets which are to be encrypted, and all-bits-0 octets for
header extension octets which are not to be. The AES-CM and AES-f8 transforms defined in [RFC3711] both operate in
this keystream mode, as do the AES_192_CM and AES_256_CM transforms
defined in [RFC6188]. For other transforms (for example,
Authenticated Encryption with Associated Data (AEAD) cryptographic
transforms, such as AES_GCM and AES_CCM [I-D.ietf-avt-srtp-aes-gcm])
their usage of header extensions MUST be specified explicitly. (As
of this writing, it is believed that it will be sufficient for SRTP
packets protected with AEAD transforms to use a CM transform with
equivalent algorithms and key lengths for their encrypted headers;
however, this guidance is not normative.)
Once the header 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.
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 which are to be
encrypted, and all-bits-0 octets for header extension octets which
are not to be.
For those octets indicated in the encryption mask, the SRTP For those octets indicated in the encryption mask, the SRTP
participant bitwise exclusive-ors the header extension with the participant bitwise exclusive-ors the header extension with the
keystream to produce the ciphertext version of the header extension. keystream to produce the ciphertext version of the header extension.
Those octets not indicated in the encryption mask are left Those octets not indicated in the encryption mask are left
unmodified. Thus, conceptually, the encryption mask is logically unmodified. Thus, conceptually, the encryption mask is logically
ANDed with the keystream to produce a masked keystream. The sender ANDed with the keystream to produce a masked keystream. The sender
and receiver MUST use the same encryption mask. The set of extension and receiver MUST use the same encryption mask. The set of extension
elements to be encrypted is communicated between the sender and the elements to be encrypted is communicated between the sender and the
receiver using the signaling mechanisms described in Section 4. receiver using the signaling mechanisms described in Section 4.
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. has validated the packet's message authentication tag, and the
receiver MUST NOT take any actions based on decrypted headers that
could affect the security or proper functioning of the system, prior
to validating the authentication tag.
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, and an encrypted audio level indication offset [RFC5450] with ID 2, an encrypted audio level indication
[I-D.ietf-avtext-client-to-mixer-audio-level] with ID 3, the [I-D.ietf-avtext-client-to-mixer-audio-level] with ID 3, and an
plaintext RTP header extension might look like this: encrypted NTP Timestamp [RFC6051] with ID 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=15| SMTPE timecode (long form) | | ID=1 | len=7 | SMTPE timecode (long form) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMTPE timecode (continued) | | SMTPE timecode (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMTPE timecode (continued) | | SMTPE (cont'd)| ID=2 | len=2 | toffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMTPE timecode (continued) | | toffset (ct'd)| ID=3 | len=0 | audio level | ID=4 | len=6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMTPE (cont'd)| ID=2 | len=2 | toffset | | NTP Timestamp (Variant B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| toffset (ct'd)| ID=3 | len=0 | audio level | padding = 0 | | NTP Timestamp (Variant B, cont.) | padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Figure 1
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|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|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Figure 2
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
octets corresponding to non-encrypted elements, element headers, and octets corresponding to non-encrypted elements, element headers, and
header extension padding are set to all-0 values. header extension padding are set to all-0 values.
4. Signaling (Setup) Information 4. Signaling (Setup) Information
skipping to change at page 6, line 31 skipping to change at page 7, line 25
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 3 Figure 3
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
session or media attribute. If the extmap for an encrypted header
extension is specified as a media attribute, it MUST only be
specified for media which 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 which 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.
4.1. Backward compatibility
Following the procedures in [RFC5285], an SDP endpoint which does not
understand the "urn:ietf:params:rtp-hdrext:encrypt" extension URI
will ignore the extension, and (for SDP offer/answer) negotiate not
to use it.
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. Receivers which understand header
extension encryption SHOULD choose the encrypted form and mark the
unencrypted form "inactive", unless they have an explicit reason to
prefer the unencrypted form. (Note that, as always, users of best-
effort encryption MUST be cautious of bid-down attacks, and ensure,
for example, that signaling is integrity-protected.)
5. Security Considerations 5. Security Considerations
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
skipping to change at page 7, line 12 skipping to change at page 8, line 31
the two-byte-headers' app bits (field 256, the lowest four bits of the two-byte-headers' app bits (field 256, the lowest four bits of
the "defined by profile" field). Neither of these features are used the "defined by profile" field). Neither of these features are used
in for one-byte-header form of header extension elements (0xBEDE), so in for one-byte-header form of header extension elements (0xBEDE), so
these limitations do not apply in that case. these limitations do not apply in that case.
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,
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.
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 extension header element
Contact: jonathan@vidyo.com Contact: jonathan@vidyo.com
Reference: RFC XXXX Reference: RFC XXXX
(Note to the RFC-Editor: please replace "XXXX" with the number of (Note to the RFC-Editor: please replace "XXXX" with the number of
this document prior to publication as an RFC.) this document prior to publication as an RFC.)
7. References 7. Acknowledgments
7.1. Normative References Thanks to Roni Even, Kevin Igoe, David McGrew, David Singer, 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 [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
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008. Header Extensions", RFC 5285, July 2008.
7.2. Informative References [RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure
RTP", RFC 6188, March 2011.
8.2. Informative References
[I-D.ietf-avt-srtp-aes-gcm] [I-D.ietf-avt-srtp-aes-gcm]
McGrew, D., "AES-GCM and AES-CCM Authenticated Encryption McGrew, D., "AES-GCM and AES-CCM Authenticated Encryption
in Secure RTP (SRTP)", draft-ietf-avt-srtp-aes-gcm-01 in Secure RTP (SRTP)", draft-ietf-avt-srtp-aes-gcm-01
(work in progress), January 2011. (work in progress), January 2011.
[I-D.ietf-avtext-client-to-mixer-audio-level] [I-D.ietf-avtext-client-to-mixer-audio-level]
Lennox, J., Ivov, E., and E. Marocco, "A Real-Time 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", Mixer Audio Level Indication",
draft-ietf-avtext-client-to-mixer-audio-level-01 (work in draft-ietf-avtext-client-to-mixer-audio-level-05 (work in
progress), March 2011. progress), September 2011.
[I-D.ietf-avtext-mixer-to-client-audio-level] [I-D.ietf-avtext-mixer-to-client-audio-level]
Ivov, E., Marocco, E., and J. Lennox, "A Real-Time 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", Client Audio Level Indication",
draft-ietf-avtext-mixer-to-client-audio-level-02 (work in draft-ietf-avtext-mixer-to-client-audio-level-05 (work in
progress), May 2011. progress), September 2011.
[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 5484, March 2009. RFC 5484, March 2009.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, November 2010.
Appendix A. Test Vectors Appendix A. Test Vectors
TODO A.1. Key derivation test vectors
Appendix B. Open issues 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 the test vectors in
Appendix B.3 of [RFC3711].)
o It is not clear how best to create the keystream for extension The inputs to the key derivation function are the 16 octet master key
headers carried in SRTP packets protected with Authenticated and the 14 octet master salt:
Encryption with Associated Data (AEAD) cryptographic transforms, master key: E1F97A0D3E018BE0D64FA32C06DE4139
such as AES_GCM and AES_CCM [I-D.ietf-avt-srtp-aes-gcm]. Header master salt: 0EC675AD498AFEEBB6960B3AABE6
extensions are already protected as ancillary data by AEAD
mechanisms, and the mechanism defined in this document does not
have any location to insert an additional authentication tag.
Appendix C. Changes From Earlier Versions 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.
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 element is encrypted using the header cipher key
and header cipher salt computed in Appendix A.1.
Session Key: 549752054D6FB708622C4A2E596A1B93
Session Salt: AB01818174C40D39A3781F7C2D27
SSRC: CAFEBABE
Rollover Counter: 00000000
Sequence Number: 1234
----------------------------------------------
Init. Counter: AB018181BE3AB787A3781F7C3F130000
The RTP session was negotiated to indicate that header extension ID
values 1, 3 and 4 are encrypted.
In hexidecimal, the header extension being encrypted is (spaces 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.)
In hexidecimal, 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 xor the
keystream with the plaintext:
Initial keystream: 1E19C8E1D481C779549ED1617AAA1B7A
FC0D933AE7ED6CC8
Mask (Hex): 00FFFFFFFFFFFFFFFF0000000000FF00
FFFFFFFFFFFFFF00
Masked keystream: 0019C8E1D481C7795400000000001B00
FC0D933AE7ED6C00
Plaintext: 17414273A475262748220000C8308E46
55996386B395FB00
Ciphertext: 17588A9270F4E15E1C220000C8309546
A994F0BC54789700
Appendix B. Changes From Earlier Versions
Note to the RFC-Editor: please remove this section prior to Note to the RFC-Editor: please remove this section prior to
publication as an RFC. publication as an RFC.
C.1. Changes from draft-lennox-avtcore -00 B.1. Changes from draft-ietf-avtcore -00
Clarified usage of Key Derivation Algorithm
Provided non-normative guidance for how to use this mechanism with
Authenticated Encryption with Associated Data (AEAD) transforms.
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.
Specified applicability of the extmap attribute if it's specified as
a session-level attribute.
Added description of backward compatibility, including a description
of how you can negotiate best-effort encryption.
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.
Added test vectors.
Added acknowledgments section.
B.2. Changes from draft-lennox-avtcore -00
o Published as working group item. o Published as working group item.
o Added discussion of limitations when used with the two-byte-header o Added discussion of limitations when used with the two-byte-header
form of header extension elements. form of header extension elements.
o Added open issue about how to use this mechanism with o Added open issue about how to use this mechanism with
Authenticated Encryption with Associated Data (AEAD) transforms. Authenticated Encryption with Associated Data (AEAD) transforms.
o Updated references. o Updated references.
C.2. Changes from draft-lennox-avt -02 B.3. Changes from draft-lennox-avt -02
o Retargeted at AVTCORE working group. o Retargeted at AVTCORE working group.
o Updated references. o Updated references.
C.3. Changes From Individual Submission Draft -01 B.4. Changes From Individual Submission Draft -01
o Minor editorial changes. o Minor editorial changes.
C.4. Changes From Individual Submission Draft -00 B.5. Changes From Individual Submission Draft -00
o Clarified description of encryption mask creation. o Clarified description of encryption mask creation.
o Added example encryption mask. o Added example encryption mask.
o Editorial changes. o Editorial changes.
Author's Address Author's Address
Jonathan Lennox Jonathan Lennox
Vidyo, Inc. Vidyo, Inc.
433 Hackensack Avenue 433 Hackensack Avenue
 End of changes. 31 change blocks. 
75 lines changed or deleted 264 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/