draft-ietf-avtcore-srtp-encrypted-header-ext-02.txt   draft-ietf-avtcore-srtp-encrypted-header-ext-03.txt 
AVTCORE J. Lennox AVTCORE J. Lennox
Internet-Draft Vidyo Internet-Draft Vidyo
Updates: 3711 (if approved) July 16, 2012 Updates: 3711 (if approved) October 22, 2012
Intended status: Standards Track Intended status: Standards Track
Expires: January 17, 2013 Expires: April 25, 2013
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-02 draft-ietf-avtcore-srtp-encrypted-header-ext-03
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 42 skipping to change at page 1, line 42
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 January 17, 2013. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . . . . 4 3. Encryption Mechanism . . . . . . . . . . . . . . . . . . . . . 4
3.1. Example Encryption Mask . . . . . . . . . . . . . . . . . 5 3.1. Example Encryption Mask . . . . . . . . . . . . . . . . . 5
3.2. Header Extension Keystream Generation for Existing 3.2. Header Extension Keystream Generation for Existing
Encryption Transforms . . . . . . . . . . . . . . . . . . 6 Encryption Transforms . . . . . . . . . . . . . . . . . . 7
3.3. Header Extension Keystream Generation for Future 3.3. Header Extension Keystream Generation for Future
Encryption Transforms . . . . . . . . . . . . . . . . . . 7 Encryption Transforms . . . . . . . . . . . . . . . . . . 7
4. Signaling (Setup) Information . . . . . . . . . . . . . . . . 7 4. Signaling (Setup) Information . . . . . . . . . . . . . . . . 7
4.1. Backward compatibility . . . . . . . . . . . . . . . . . . 8 4.1. Backward compatibility . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 11
A.1. Key derivation test vectors . . . . . . . . . . . . . . . 11 A.1. Key derivation test vectors . . . . . . . . . . . . . . . 11
A.2. Header Encryption Test Vectors using AES-CM . . . . . . . 12 A.2. Header Encryption Test Vectors using AES-CM . . . . . . . 12
Appendix B. Changes From Earlier Versions . . . . . . . . . . . . 13 Appendix B. Changes From Earlier Versions . . . . . . . . . . . . 14
B.1. Changes from draft-ietf-avtcore -01 . . . . . . . . . . . 13 B.1. Changes from draft-ietf-avtcore -02 . . . . . . . . . . . 14
B.2. Changes from draft-ietf-avtcore -00 . . . . . . . . . . . 14 B.2. Changes from draft-ietf-avtcore -01 . . . . . . . . . . . 14
B.3. Changes from draft-lennox-avtcore -00 . . . . . . . . . . 14 B.3. Changes from draft-ietf-avtcore -00 . . . . . . . . . . . 14
B.4. Changes from draft-lennox-avt -02 . . . . . . . . . . . . 15 B.4. Changes from draft-lennox-avtcore -00 . . . . . . . . . . 15
B.5. Changes From Individual Submission Draft -01 . . . . . . . 15 B.5. Changes from draft-lennox-avt -02 . . . . . . . . . . . . 15
B.6. Changes From Individual Submission Draft -00 . . . . . . . 15 B.6. Changes From Individual Submission Draft -01 . . . . . . . 15
B.7. Changes From Individual Submission Draft -00 . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
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 5, line 5 skipping to change at page 5, line 5
or are to be, encrypted. This encryption mask corresponds to the or are to be, encrypted. This encryption mask corresponds to the
entire payload of each header extension element that is encrypted. entire payload of each header extension element that is encrypted.
It does not include any non-encrypted header extension elements, any It does 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 which 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 which are not to be. 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.
This encryption mask is computed separately for every packet that
carries a header extension. Based on the non-encrypted portions of
the headers and the signaled list of encrypted extension elements, a
receiver can always determine the correct encryption mask for any
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 exclusive-
ors the header extension with this masked keystream to produce the ors the header extension with this masked keystream to produce the
ciphertext version of the header extension. (Thus, octets indicated ciphertext version of the header extension. (Thus, octets indicated
as all-bits-1 in the encrypted mask are encrypted, whereas those as all-bits-1 in the encrypted mask are encrypted, whereas those
indicated as all-bits-0 are not.) 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 [RFC3550] Section 5.3.1 calls "header extension" proper,
starting with the first [RFC5285] ID and length. Thus, both the starting with the first [RFC5285] ID and length. Thus, both the
encryption mask and the keystream begin at this point. encryption mask and the keystream begin at this point.
This header extension encryption process could, equivalently, be
computed by considering the encryption mask as a mixture of the
encrypted and unencrypted headers, i.e. as
EncryptedHeader = (Encrypt(Key, Plaintext) AND MASK) OR
(Plaintext AND (NOT MASK))
where Encrypt is the encryption function, MASK is the encryption
mask, and AND, OR, and NOT are bitwise operations. This formulation
of the encryption process might be preferred by implementations for
which encryption is performed by a separate module, and cannot easily
be modified.
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 that
could affect the security or proper functioning of the system, prior could affect the security or proper functioning of the system, prior
to validating the authentication tag. to validating the authentication tag.
skipping to change at page 9, line 39 skipping to change at page 10, line 12
middleboxes cannot view and interpret such traffic, of course, only middleboxes cannot view and interpret such traffic, of course, only
that appropriate skepticism needs to be maintained about the results that appropriate skepticism needs to be maintained about the results
of such interpretation.). 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 technique defined in this document can only be applied to
encryption transforms that work by generating a pseudorandom
keystream and bitwise exclusive-oring it with the plaintext, such as
CTR or f8. It MUST NOT be used with ECB, CBC, or any other
encryption method that does not use a keystream, or a loss of
security will entail.
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
skipping to change at page 13, line 34 skipping to change at page 14, line 10
Plaintext: 17414273A475262748220000C8308E46 Plaintext: 17414273A475262748220000C8308E46
55996386B395FB00 55996386B395FB00
Ciphertext: 17588A9270F4E15E1C220000C8309546 Ciphertext: 17588A9270F4E15E1C220000C8309546
A994F0BC54789700 A994F0BC54789700
Appendix B. Changes From Earlier Versions 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.
B.1. Changes from draft-ietf-avtcore -01 B.1. Changes from draft-ietf-avtcore -02
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.
Explicitly distinguished the processing of existing encryption
transforms from future ones.
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.
Defined how header extension encryption is to be done with the SEED
algorithms defined in RFC 5669, and with the NULL algorithm.
Added ABNF grammar for the SDP syntax.
Clarified that header extension encryption must not be applied to
itself.
Expanded discussion of bid-down attacks.
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.
Updated references to now-published RFCs.
Editorial clarifications.
Added Magnus Westerlund to the Acknowledgments.
B.2. 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 o Clarified that the header extension encryption mask must be
extension (it's eight bytes, not sixteen). Added an NTP timestamp to calculated separately for each packet, and can always be derived
the example to fill it back out to original size. 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.
Specified applicability of the extmap attribute if it's specified as B.2. Changes from draft-ietf-avtcore -01
a session-level attribute.
Added description of backward compatibility, including a description o Made the draft update RFC 3711, and added a section specifying
of how you can negotiate best-effort encryption. 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.
Added a note to the security considerations about the dangers for B.3. Changes from draft-ietf-avtcore -00
middleboxes observing unencrypted headers (both header extension
elements and RTP headers) without being able to verify the
authentication keys.
Added test vectors. 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.
Added acknowledgments section. 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.3. Changes from draft-lennox-avtcore -00 B.4. 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.
B.4. Changes from draft-lennox-avt -02 B.5. Changes from draft-lennox-avt -02
o Retargeted at AVTCORE working group. o Retargeted at AVTCORE working group.
o Updated references. o Updated references.
B.5. Changes From Individual Submission Draft -01 B.6. Changes From Individual Submission Draft -01
o Minor editorial changes. o Minor editorial changes.
B.6. Changes From Individual Submission Draft -00 B.7. 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. 23 change blocks. 
72 lines changed or deleted 93 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/