draft-ietf-avtcore-srtp-encrypted-header-ext-04.txt   draft-ietf-avtcore-srtp-encrypted-header-ext-05.txt 
AVTCORE J. Lennox AVTCORE J. Lennox
Internet-Draft Vidyo Internet-Draft Vidyo
Updates: 3711 (if approved) January 3, 2013 Updates: 3711 (if approved) February 8, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: July 7, 2013 Expires: August 12, 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-04 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.
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 July 7, 2013. This Internet-Draft will expire on August 12, 2013.
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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . . 4 3. Encryption Mechanism . . . . . . . . . . . . . . . . . . . . . 4
3.1. Example Encryption Mask . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 7
4. Signaling (Setup) Information . . . . . . . . . . . . . . . . 7 4. Signaling (Setup) Information . . . . . . . . . . . . . . . . 7
4.1. Backward compatibility . . . . . . . . . . . . . . . . . . 8 4.1. Backward compatibility . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 12
A.1. Key derivation test vectors . . . . . . . . . . . . . . . 12 A.1. Key derivation test vectors . . . . . . . . . . . . . . . 12
A.2. Header Encryption Test Vectors using AES-CM . . . . . . . 13 A.2. Header Encryption Test Vectors using AES-CM . . . . . . . 13
Appendix B. Changes From Earlier Versions . . . . . . . . . . . . 14 Appendix B. Changes From Earlier Versions . . . . . . . . . . . . 14
B.1. Changes from draft-ietf-avtcore -03 . . . . . . . . . . . 14 B.1. Changes from draft-ietf-avtcore -04 . . . . . . . . . . . 14
B.2. Changes from draft-ietf-avtcore -02 . . . . . . . . . . . 14 B.2. Changes from draft-ietf-avtcore -03 . . . . . . . . . . . 15
B.3. Changes from draft-ietf-avtcore -01 . . . . . . . . . . . 14 B.3. Changes from draft-ietf-avtcore -02 . . . . . . . . . . . 15
B.4. Changes from draft-ietf-avtcore -00 . . . . . . . . . . . 15 B.4. Changes from draft-ietf-avtcore -01 . . . . . . . . . . . 15
B.5. Changes from draft-lennox-avtcore -00 . . . . . . . . . . 15 B.5. Changes from draft-ietf-avtcore -00 . . . . . . . . . . . 16
B.6. Changes from draft-lennox-avt -02 . . . . . . . . . . . . 15 B.6. Changes from draft-lennox-avtcore -00 . . . . . . . . . . 16
B.7. Changes From Individual Submission Draft -01 . . . . . . . 15 B.7. Changes from draft-lennox-avt -02 . . . . . . . . . . . . 16
B.8. Changes From Individual Submission Draft -00 . . . . . . . 16 B.8. Changes From Individual Submission Draft -01 . . . . . . . 16
B.9. Changes From Individual Submission Draft -00 . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 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.
skipping to change at page 3, line 27 skipping to change at page 3, line 27
infer by observing the size and timing of RTP packets. Thus, there infer by observing the size and timing of RTP packets. Thus, there
is little need for confidentiality of the header information. is little need for confidentiality of the header information.
However, this is not necessarily true for information carried in RTP However, this is not necessarily true for information carried in RTP
header extensions. A number of recent proposals for header header extensions. A number of recent proposals for header
extensions using the General Mechanism for RTP Header Extensions extensions using the General Mechanism for RTP Header Extensions
[RFC5285] carry information for which confidentiality could be [RFC5285] carry information for which confidentiality could be
desired or essential. Notably, two recent specifications ([RFC6464] desired or essential. Notably, two recent specifications ([RFC6464]
and [RFC6465]) carry information about per-packet sound levels of the and [RFC6465]) carry information about per-packet sound levels of the
media data carried in the RTP payload, and exposing this to an media data carried in the RTP payload, and exposing this to an
eavesdropper is unacceptable in many circumstances. eavesdropper is unacceptable in many circumstances (as described in
the respective RFCs' Security Considerations sections).
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
skipping to change at page 4, line 28 skipping to change at page 4, line 29
using the Secure Real-Time Transport Protocol [RFC3711]. To encrypt using the Secure Real-Time Transport Protocol [RFC3711]. To encrypt
(or decrypt) encrypted extension headers, an SRTP participant first (or decrypt) encrypted extension headers, an SRTP participant first
uses the SRTP Key Derivation Algorithm, specified in Section 4.3.1 of uses the SRTP Key Derivation Algorithm, specified in Section 4.3.1 of
[RFC3711], to generate header encryption and header salting keys, [RFC3711], to generate header encryption and header salting keys,
using the same pseudo-random function family as are used for the key using the same pseudo-random function family as are used for the key
derivation for the SRTP session. These keys are derived as follows: 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. (Note that since RTP headers, including extension headers, payload. Additionally, the same master key, master salt, index, and
are authenticated in SRTP, no new authentication key is needed for key_derivation_rate 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.) 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 publication of this document, see
Section 3.2; for requirements for new transforms, see Section 3.3. Section 3.2; for requirements for new transforms, see Section 3.3.
Once the header extension keystream is generated, the SRTP Once 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. This encryption mask corresponds to the or are to be, encrypted. (For an example of this procedure, see
entire payload of each header extension element that is encrypted. Section 3.1 below.) This encryption mask corresponds to the entire
It does not include any non-encrypted header extension elements, any 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 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 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
skipping to change at page 9, line 7 skipping to change at page 9, line 12
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 which 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) negotiate not
to use it. to use it.
In a negotiated session (whether using offer/answer or some other For backward compatibility with endpoints which do not implement this
means), best-effort encryption of a header extension element is specification, in a negotiated session (whether using offer/answer or
possible: an endpoint MAY offer the same header extension element some other means), best-effort encryption of a header extension
both encrypted and unencrypted. Receivers which understand header element is possible: an endpoint MAY offer the same header extension
extension encryption SHOULD choose the encrypted form and mark the element both encrypted and unencrypted. An offerer MUST only offer
unencrypted form "inactive", unless they have an explicit reason to best-effort negotiation when lack of confidentiality would be
prefer the unencrypted form. (Note that, as always, users of best- acceptable in the backward-compatible case. Answerers (or equivalent
effort encryption MUST be cautious of bid-down attacks, where a man- peers in a negotiation) which understand header extension encryption
in-the-middle attacker removes a higher-security option, forcing SHOULD choose the encrypted form of the offered header extension
endpoints to negotiate a lower-security one. Appropriate element, and mark the unencrypted form "inactive", unless they have
countermeasures depend on the signaling protocol in use, but users an explicit reason to prefer the unencrypted form. In all cases,
can ensure, for example, that signaling is integrity-protected.) answerers MUST NOT negotiate the use of, and senders MUST NOT send,
both encrypted and unencrypted forms of the same header extension.
Note that, as always, users of best-effort encryption MUST be
cautious of bid-down attacks, where a man-in-the-middle attacker
removes a higher-security option, forcing endpoints to negotiate a
lower-security one. Appropriate countermeasures depend on the
signaling protocol in use, but users can 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
skipping to change at page 10, line 18 skipping to change at page 10, line 30
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 dangers of using weak or NULL authentication with SRTP, described
in [RFC3711] Section 9.5, apply to encrypted header extensions as
well. In particular, since some header extension elements will have
some easily-guessed plaintext bits, strong authentication is REQUIRED
if an attacker setting such bits could have a meaningful effect on
the behavior of the system.
The technique defined in this document can only be applied to The technique defined in this document can only be applied 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 MUST NOT be used with ECB, CBC, or any other CTR or f8. It will not work with ECB, CBC, or any other encryption
encryption method that does not use a keystream, or a loss of method that does not use a keystream.
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
(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. Acknowledgments 7. Acknowledgments
Thanks to Roni Even, Kevin Igoe, David McGrew, Magnus Westerlund, Thanks to Benoit Claise, Roni Even, Stephen Farrell, Kevin Igoe, Joel
David Singer, Robert Sparks, Qin Wu, and Felix Wyss for their Jaeggli, David McGrew, Magnus Westerlund, David Singer, Robert
comments and suggestions in the development of this specification. Sparks, Qin Wu, and Felix Wyss for their comments and suggestions 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
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.
skipping to change at page 14, line 21 skipping to change at page 14, line 44
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 -03 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 Modified the ABNF syntax to avoid rule recursion.
o Added Robert Sparks to the Acknowledgments. o Added Robert Sparks to the Acknowledgments.
B.2. Changes from draft-ietf-avtcore -02 B.3. Changes from draft-ietf-avtcore -02
o Clarified that the header extension encryption mask must be o Clarified that the header extension encryption mask must be
calculated separately for each packet, and can always be derived calculated separately for each packet, and can always be derived
from the plaintext portions of the encrypted header extension. from the plaintext portions of the encrypted header extension.
o Presented an alternate formulation of the header extension o Presented an alternate formulation of the header extension
encryption process, so implementations can use their existing encryption process, so implementations can use their existing
encryption algorithms unmodified. encryption algorithms unmodified.
o Added a security consideration emphasizing that this mechanism o Added a security consideration emphasizing that this mechanism
must only be used with keystream-based encryption algorithms. must only be used with keystream-based encryption algorithms.
B.3. Changes from draft-ietf-avtcore -01 B.4. Changes from draft-ietf-avtcore -01
o Made the draft update RFC 3711, and added a section specifying o Made the draft update RFC 3711, and added a section specifying
that all future SRTP encryption transforms must specify how header that all future SRTP encryption transforms must specify how header
extension encryption is to be done. extension encryption is to be done.
o Explicitly distinguished the processing of existing encryption o Explicitly distinguished the processing of existing encryption
transforms from future ones. transforms from future ones.
o Clarified description of the process by which the encryption mask o Clarified description of the process by which the encryption mask
is applied, and that encryption does not apply to the header is applied, and that encryption does not apply to the header
extension "defined by profile" or "length" fields. extension "defined by profile" or "length" fields.
o Defined how header extension encryption is to be done with the o Defined how header extension encryption is to be done with the
skipping to change at page 15, line 4 skipping to change at page 15, line 43
that all future SRTP encryption transforms must specify how header that all future SRTP encryption transforms must specify how header
extension encryption is to be done. extension encryption is to be done.
o Explicitly distinguished the processing of existing encryption o Explicitly distinguished the processing of existing encryption
transforms from future ones. transforms from future ones.
o Clarified description of the process by which the encryption mask o Clarified description of the process by which the encryption mask
is applied, and that encryption does not apply to the header is applied, and that encryption does not apply to the header
extension "defined by profile" or "length" fields. extension "defined by profile" or "length" fields.
o Defined how header extension encryption is to be done with the o Defined how header extension encryption is to be done with the
SEED algorithms defined in RFC 5669, and with the NULL algorithm. SEED algorithms defined in RFC 5669, and with the NULL algorithm.
o Added ABNF grammar for the SDP syntax. o Added ABNF grammar for the SDP syntax.
o Clarified that header extension encryption must not be applied to o Clarified that header extension encryption must not be applied to
itself. itself.
o Expanded discussion of bid-down attacks. o Expanded discussion of bid-down attacks.
o Pointed out that this mechanism can't protect non-RFC5285 header o Pointed out that this mechanism can't protect non-RFC5285 header
extensions, and that there's no way to give different protection extensions, and that there's no way to give different protection
to header extensions than to payloads. to header extensions than to payloads.
o Updated references to now-published RFCs. o Updated references to now-published RFCs.
o Editorial clarifications. o Editorial clarifications.
o Added Magnus Westerlund to the Acknowledgments. o Added Magnus Westerlund to the Acknowledgments.
B.4. Changes from draft-ietf-avtcore -00 B.5. Changes from draft-ietf-avtcore -00
o Clarified usage of Key Derivation Algorithm o Clarified usage of Key Derivation Algorithm
o Provided non-normative guidance for how to use this mechanism with o Provided non-normative guidance for how to use this mechanism with
Authenticated Encryption with Associated Data (AEAD) transforms. Authenticated Encryption with Associated Data (AEAD) transforms.
o Corrected SMPTE Timecode header extension element in example o Corrected SMPTE Timecode header extension element in example
header extension (it's eight bytes, not sixteen). Added an NTP header extension (it's eight bytes, not sixteen). Added an NTP
timestamp to the example to fill it back out to original size. timestamp to the example to fill it back out to original size.
o Specified applicability of the extmap attribute if it's specified o Specified applicability of the extmap attribute if it's specified
as a session-level attribute. as a session-level attribute.
o Added description of backward compatibility, including a o Added description of backward compatibility, including a
description of how you can negotiate best-effort encryption. description of how you can negotiate best-effort encryption.
o Added a note to the security considerations about the dangers for o Added a note to the security considerations about the dangers for
middleboxes observing unencrypted headers (both header extension middleboxes observing unencrypted headers (both header extension
elements and RTP headers) without being able to verify the elements and RTP headers) without being able to verify the
authentication keys. authentication keys.
o Added test vectors. o Added test vectors.
o Added acknowledgments section. o Added acknowledgments section.
B.5. Changes from draft-lennox-avtcore -00 B.6. 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.6. Changes from draft-lennox-avt -02 B.7. 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.7. Changes From Individual Submission Draft -01 B.8. Changes From Individual Submission Draft -01
o Minor editorial changes. o Minor editorial changes.
B.8. Changes From Individual Submission Draft -00 B.9. 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. 27 change blocks. 
49 lines changed or deleted 86 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/