doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc6904.txt b/doc/rfc/rfc6904.txt
new file mode 100644
index 0000000..4c30a4f
--- /dev/null
+++ b/doc/rfc/rfc6904.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         J. Lennox
+Request for Comments: 6904                                         Vidyo
+Updates: 3711                                                 April 2013
+Category: Standards Track
+ISSN: 2070-1721
+
+
+                    Encryption of Header Extensions
+           in the Secure Real-time Transport Protocol (SRTP)
+
+Abstract
+
+   The Secure Real-time Transport Protocol (SRTP) provides
+   authentication, but not encryption, of the headers of Real-time
+   Transport Protocol (RTP) packets.  However, RTP header extensions may
+   carry sensitive information for which participants in multimedia
+   sessions want confidentiality.  This document provides a mechanism,
+   extending the mechanisms of SRTP, to selectively encrypt RTP header
+   extensions in SRTP.
+
+   This document updates RFC 3711, the Secure Real-time Transport
+   Protocol specification, to require that all future SRTP encryption
+   transforms specify how RTP header extensions are to be encrypted.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lennox                       Standards Track                    [Page 1]
+
+RFC 6904            Encrypted SRTP Header Extensions          April 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  Encryption Mechanism  . . . . . . . . . . . . . . . . . . . .   4
+     3.1.  Example Encryption Mask . . . . . . . . . . . . . . . . .   6
+     3.2.  Header Extension Keystream Generation for Existing
+           Encryption Transforms . . . . . . . . . . . . . . . . . .   7
+     3.3.  Header Extension Keystream Generation for Future
+           Encryption Transforms . . . . . . . . . . . . . . . . . .   8
+   4.  Signaling (Setup) Information . . . . . . . . . . . . . . . .   8
+     4.1.  Backward Compatibility  . . . . . . . . . . . . . . . . .   9
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
+   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
+     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
+   Appendix A.  Test Vectors . . . . . . . . . . . . . . . . . . . .  13
+     A.1.  Key Derivation Test Vectors . . . . . . . . . . . . . . .  13
+     A.2.  Header Encryption Test Vectors Using AES-CM . . . . . . .  14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lennox                       Standards Track                    [Page 2]
+
+RFC 6904            Encrypted SRTP Header Extensions          April 2013
+
+
+1.  Introduction
+
+   The Secure Real-time Transport Protocol [RFC3711] specification
+   provides confidentiality, message authentication, and replay
+   protection for multimedia payloads sent using the Real-time Protocol
+   (RTP) [RFC3550].  However, in order to preserve RTP header
+   compression efficiency, SRTP provides only authentication and replay
+   protection for the headers of RTP packets, not confidentiality.
+
+   For the standard portions of an RTP header, providing only
+   authentication and replay protection does not normally present a
+   problem, as the information carried in an RTP header does not provide
+   much information beyond that which an attacker could infer by
+   observing the size and timing of RTP packets.  Thus, there is little
+   need for confidentiality of the header information.
+
+   However, the security requirements can be different for information
+   carried in RTP header extensions.  A number of recent proposals for
+   header extensions using the mechanism described in "A General
+   Mechanism for RTP Header Extensions" [RFC5285] carry information for
+   which confidentiality could be desired or essential.  Notably, two
+   recent specifications ([RFC6464] and [RFC6465]) contain information
+   about per-packet sound levels of the media data carried in the RTP
+   payload and specify that exposing this information to an eavesdropper
+   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
+   be applied to RTP header extensions when they are transported using
+   SRTP.  As an RTP sender may wish some extension information to be
+   sent in the clear (for example, it may be useful for a network
+   monitoring device to be aware of RTP transmission time offsets
+   [RFC5450]), this mechanism can be selectively applied to a subset of
+   the header extension elements carried in an SRTP packet.
+
+   The mechanism defined by this document encrypts packets' header
+   extensions using the same cryptographic algorithms and parameters as
+   are used to encrypt the packets' RTP payloads.  This document defines
+   how this is done for the encryption transforms defined in [RFC3711],
+   [RFC5669], and [RFC6188], which are the SRTP encryption transforms
+   defined by Standards Track RFCs at the time of this writing.  It also
+   updates [RFC3711] to indicate that specifications of future SRTP
+   encryption transforms must define how header extension encryption is
+   to be performed.
+
+
+
+
+
+
+
+Lennox                       Standards Track                    [Page 3]
+
+RFC 6904            Encrypted SRTP Header Extensions          April 2013
+
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119] and
+   indicate requirement levels for compliant implementations.
+
+3.  Encryption Mechanism
+
+   Encrypted header extension elements are carried in the same manner as
+   non-encrypted header extension elements, as defined by [RFC5285].
+   The one- or two-byte header of the extension elements is not
+   encrypted, nor is any of the header extension padding.  If multiple
+   different header extension elements are being encrypted, they have
+   separate element identifier values, just as they would if they were
+   not encrypted.  Similarly, encrypted and non-encrypted header
+   extension elements have separate identifier values.
+
+   Encrypted header extension elements are carried only in packets
+   encrypted using the Secure Real-time Transport Protocol [RFC3711].
+   To encrypt (or decrypt) encrypted header extension elements, an SRTP
+   participant first uses the SRTP key derivation algorithm, specified
+   in Section 4.3.1 of [RFC3711], to generate header encryption and
+   header salting keys, using the same pseudorandom function family as
+   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_hs (SRTP header salting key): <label> = 0x07, n=n_s.
+
+   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.  Additionally, the same master key, master salt, index, and
+   key_derivation_rate are used as for the SRTP payload.  (Note that
+   since RTP headers, including header extensions, are authenticated in
+   SRTP, no new authentication key is needed for header extensions.)
+
+   A header extension keystream is generated for each packet containing
+   encrypted header extension elements.  The details of how this header
+   extension keystream is generated depend on the encryption transform
+   that is used for the SRTP packet.  For encryption transforms that
+   have been standardized as of the date of publication of this
+   document, see Section 3.2; for requirements for new transforms, see
+   Section 3.3.
+
+
+
+
+
+
+Lennox                       Standards Track                    [Page 4]
+
+RFC 6904            Encrypted SRTP Header Extensions          April 2013
+
+
+   After the header extension 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.  (For an example of this procedure, see
+   Section 3.1.)  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 that are to be encrypted and all-bits-0 octets for
+   header extension octets that are not to be encrypted.  The set of
+   extension elements to be encrypted is communicated between the sender
+   and the 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
+   keystream to produce a masked keystream.  It then bitwise
+   exclusive-ORs the header extension with this masked keystream to
+   produce the ciphertext version of the header extension.  (Thus,
+   octets indicated as all-bits-1 in the encrypted mask are encrypted,
+   whereas those indicated as all-bits-0 are not.)
+
+   The header extension encryption process does not include the "defined
+   by profile" or "length" fields of the header extension, only the
+   field that Section 5.3.1 of [RFC3550] calls "header extension"
+   proper, starting with the first [RFC5285] ID and length.  Thus, both
+   the 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 be
+   modified easily.
+
+
+
+
+
+Lennox                       Standards Track                    [Page 5]
+
+RFC 6904            Encrypted SRTP Header Extensions          April 2013
+
+
+   The SRTP authentication tag is computed across the encrypted header
+   extension, i.e., the data that is actually transmitted on the wire.
+   Thus, header extension encryption MUST be done before the
+   authentication tag is computed, and authentication tag validation
+   MUST be done on the encrypted header extensions.  For receivers,
+   header extension decryption SHOULD be done only after the receiver
+   has validated the packet's message authentication tag, and the
+   receiver MUST NOT take any actions based on decrypted headers, prior
+   to validating the authentication tag, that could affect the security
+   or proper functioning of the system.
+
+3.1.  Example Encryption Mask
+
+   If a sender wished to send a header extension containing an encrypted
+   SMPTE timecode [RFC5484] with ID 1, a plaintext transmission time
+   offset [RFC5450] with ID 2, an encrypted audio level indication
+   [RFC6464] with ID 3, and an encrypted NTP timestamp [RFC6051] with ID
+   4, the plaintext RTP header extension might look like this:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  ID=1 | len=7 |     SMTPE timecode (long form)                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       SMTPE timecode (continued)                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | SMTPE (cont'd)|  ID=2 | len=2 | toffset                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | toffset (ct'd)|  ID=3 | len=0 | audio level   |  ID=4 | len=6 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       NTP timestamp (Variant B)                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       NTP timestamp (Variant B, cont'd)       | padding = 0   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+         Figure 1: Structure of Plaintext Example Header Extension
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lennox                       Standards Track                    [Page 6]
+
+RFC 6904            Encrypted SRTP Header Extensions          April 2013
+
+
+   The corresponding encryption mask would then be:
+
+    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 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|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|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |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: Encryption Mask for Example Header Extension
+
+   In the mask, the octets corresponding to the payloads of the
+   encrypted header extension elements are set to all-1 values, and the
+   octets corresponding to non-encrypted header extension elements,
+   element headers, and header extension padding are set to all-zero
+   values.
+
+3.2.  Header Extension Keystream Generation for Existing Encryption
+      Transforms
+
+   For the AES-CM and AES-f8 transforms [RFC3711], the SEED-CTR
+   transform [RFC5669], and the AES_192_CM and AES_256_CM transforms
+   [RFC6188], the header extension keystream SHALL be generated for each
+   packet containing encrypted header extension elements using the same
+   encryption transform and Initialization Vector (IV) as are used for
+   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
+   and header salting keys k_he and k_hs, respectively, as defined
+   above.
+
+   For the SEED-CCM and SEED-GCM transforms [RFC5669], the header
+   extension keystream SHALL be generated using the algorithm specified
+   above for the SEED-CTR algorithm.  (Because the Authenticated
+   Encryption with Associated Data (AEAD) transform used on the payload
+   in these algorithms includes the RTP header, including the RTP header
+   extension, in its Associated Authenticated Data (AAD), counter-mode
+   encryption for the header extension is believed to be of equivalent
+   cryptographic strength to the CCM and GCM transforms.)
+
+
+
+
+Lennox                       Standards Track                    [Page 7]
+
+RFC 6904            Encrypted SRTP Header Extensions          April 2013
+
+
+   For the NULL encryption transform [RFC3711], the header extension
+   keystream SHALL be all-zero.
+
+3.3.  Header Extension Keystream Generation for Future Encryption
+      Transforms
+
+   When new SRTP encryption transforms are defined, this document
+   updates [RFC3711] as follows: in addition to the rules specified in
+   Section 6 of RFC 3711, the Standards Track RFC defining the new
+   transform MUST specify how the encryption transform is to be used
+   with header extension encryption.
+
+   It is RECOMMENDED that new transformations follow the same mechanisms
+   as are defined in Section 3.2 of this document if they are applicable
+   and are believed to be cryptographically adequate for the transform
+   in question.
+
+4.  Signaling (Setup) Information
+
+   Encrypted header extension elements are signaled in the Session
+   Description Protocol (SDP) extmap attribute using the URI
+   "urn:ietf:params:rtp-hdrext:encrypt" followed by the URI of the
+   header extension element being encrypted, as well as any
+   extensionattributes that extension normally takes.  Figure 3 gives a
+   formal Augmented Backus-Naur Form (ABNF) [RFC5234] showing this
+   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
+       %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
+
+   extmap =/ mapentry SP enc-extensionname SP extensionname
+       [SP extensionattributes]
+
+   ; extmap, mapentry, extensionname, and extensionattributes
+   ; are defined in [RFC5285]
+
+                 Figure 3: Syntax of the "encrypt" extmap
+
+   Thus, for example, to signal an SRTP session using encrypted SMPTE
+   timecodes [RFC5484], while simultaneously signaling plaintext
+   transmission time offsets [RFC5450], an SDP document could contain
+   the text shown in Figure 4 (line breaks have been added for
+   formatting).
+
+
+
+
+
+
+
+Lennox                       Standards Track                    [Page 8]
+
+RFC 6904            Encrypted SRTP Header Extensions          April 2013
+
+
+   m=audio 49170 RTP/SAVP 0
+   a=crypto:1 AES_CM_128_HMAC_SHA1_32 \
+     inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
+   a=extmap:1 urn:ietf:params:rtp-hdrext:encrypt \
+       urn:ietf:params:rtp-hdrext:smpte-tc 25@600/24
+   a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
+
+         Figure 4: Sample SDP Document Offering Encrypted Headers
+
+   This example uses SDP security descriptions [RFC4568] for SRTP
+   keying, but this is merely for illustration.  Any SRTP keying
+   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 be specified
+   only for media that 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 that 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.
+
+   The "urn:ietf:params:rtp-hdrext:encrypt" extension MUST NOT be
+   recursively applied to itself.
+
+4.1.  Backward Compatibility
+
+   Following the procedures in [RFC5285], an SDP endpoint that does not
+   understand the "urn:ietf:params:rtp-hdrext:encrypt" extension URI
+   will ignore the extension and, for SDP offer/answer, will negotiate
+   not to use it.
+
+   For backward compatibility with endpoints that do not implement this
+   specification, 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.  An offerer MUST offer only
+   best-effort negotiation when lack of confidentiality would be
+   acceptable in the backward-compatible case.  Answerers (or equivalent
+   peers in a negotiation) that understand header extension encryption
+   SHOULD choose the encrypted form of the offered header extension
+   element and mark the unencrypted form "inactive", unless they have an
+   explicit reason to prefer the unencrypted form.  In all cases,
+   answerers MUST NOT negotiate the use of, and senders MUST NOT send,
+   both encrypted and unencrypted forms of the same header extension.
+
+
+
+
+
+
+Lennox                       Standards Track                    [Page 9]
+
+RFC 6904            Encrypted SRTP Header Extensions          April 2013
+
+
+   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
+
+   The security properties of header extension elements protected by the
+   mechanism in this document are equivalent to those for SRTP payloads.
+
+   The mechanism defined in this document does not provide
+   confidentiality about which header extension elements are used for a
+   given SRTP packet, only for the content of those header extension
+   elements.  This appears to be in the spirit of SRTP itself, which
+   does not encrypt RTP headers.  If this is a concern, an alternate
+   mechanism would be needed to provide confidentiality.
+
+   For the two-byte-header form of header extension elements (0x100N,
+   where "N" is the appbits field), this mechanism does not provide any
+   protection to zero-length header extension elements (for which their
+   presence or absence is the only information they carry).  It also
+   does not provide any protection for the appbits (field 256, the
+   lowest four bits of the "defined by profile" field) of the two-byte
+   headers.  Neither of these features is present in the one-byte-header
+   form of header extension elements (0xBEDE), so these limitations do
+   not apply in that case.
+
+   This mechanism cannot protect RTP header extensions that do not use
+   the mechanism defined in [RFC5285].
+
+   This document does not specify the circumstances in which extension
+   header encryption should be used.  Documents defining specific header
+   extension elements should provide guidance on when encryption is
+   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, in the
+   same way as they treat unauthenticated traffic.  (This does not mean
+   that middleboxes cannot view and interpret such traffic, of course,
+   only that appropriate skepticism needs to be maintained about the
+   results of such interpretation.)
+
+
+
+
+
+Lennox                       Standards Track                   [Page 10]
+
+RFC 6904            Encrypted SRTP Header Extensions          April 2013
+
+
+   There is no mechanism defined to protect header extensions with
+   different algorithms or encryption keys than are used to protect the
+   RTP payloads.  In particular, it is not possible to provide
+   confidentiality for a header extension while leaving the payload in
+   cleartext.
+
+   The dangers of using weak or NULL authentication with SRTP, described
+   in Section 9.5 of [RFC3711], 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 be applied only to
+   encryption transforms that work by generating a pseudorandom
+   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
+   method that does not use a keystream.
+
+6.  IANA Considerations
+
+   This document defines a new extension URI to the RTP Compact Header
+   Extensions subregistry of the Real-Time Transport Protocol (RTP)
+   Parameters registry, according to the following data:
+
+      Extension URI:  urn:ietf:params:rtp-hdrext:encrypt
+      Description:    Encrypted header extension element
+      Contact:        jonathan@vidyo.com
+      Reference:      RFC 6904
+
+7.  Acknowledgments
+
+   Thanks to Benoit Claise, Roni Even, Stephen Farrell, Kevin Igoe, Joel
+   Jaeggli, David McGrew, David Singer, Robert Sparks, Magnus
+   Westerlund, 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
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, July 2003.
+
+
+
+
+Lennox                       Standards Track                   [Page 11]
+
+RFC 6904            Encrypted SRTP Header Extensions          April 2013
+
+
+   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+              RFC 3711, March 2004.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [RFC5285]  Singer, D. and H. Desineni, "A General Mechanism for RTP
+              Header Extensions", RFC 5285, July 2008.
+
+   [RFC5669]  Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The
+              SEED Cipher Algorithm and Its Use with the Secure Real-
+              Time Transport Protocol (SRTP)", RFC 5669, August 2010.
+
+   [RFC6188]  McGrew, D., "The Use of AES-192 and AES-256 in Secure
+              RTP", RFC 6188, March 2011.
+
+8.2.  Informative References
+
+   [RFC4568]  Andreasen, F., Baugher, M., and D. Wing, "Session
+              Description Protocol (SDP) Security Descriptions for Media
+              Streams", RFC 4568, July 2006.
+
+   [RFC5450]  Singer, D. and H. Desineni, "Transmission Time Offsets in
+              RTP Streams", RFC 5450, March 2009.
+
+   [RFC5484]  Singer, D., "Associating Time-Codes with RTP Streams", RFC
+              5484, March 2009.
+
+   [RFC6051]  Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
+              Flows", RFC 6051, November 2010.
+
+   [RFC6464]  Lennox, J., Ivov, E., and E. Marocco, "A Real-time
+              Transport Protocol (RTP) Header Extension for Client-to-
+              Mixer Audio Level Indication", RFC 6464, December 2011.
+
+   [RFC6465]  Ivov, E., Marocco, E., and J. Lennox, "A Real-time
+              Transport Protocol (RTP) Header Extension for Mixer-to-
+              Client Audio Level Indication", RFC 6465, December 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+Lennox                       Standards Track                   [Page 12]
+
+RFC 6904            Encrypted SRTP Header Extensions          April 2013
+
+
+Appendix A.  Test Vectors
+
+A.1.  Key Derivation Test Vectors
+
+   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 test vectors in Appendix
+   B.3 of [RFC3711].)
+
+   The inputs to the key derivation function are the 16-octet master key
+   and the 14-octet master salt:
+
+      master key: E1F97A0D3E018BE0D64FA32C06DE4139
+
+      master salt: 0EC675AD498AFEEBB6960B3AABE6
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lennox                       Standards Track                   [Page 13]
+
+RFC 6904            Encrypted SRTP Header Extensions          April 2013
+
+
+     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 is encrypted using the header cipher key and
+   header cipher salt computed in Appendix A.1.  The header extension is
+   carried in an SRTP-encrypted RTP packet with SSRC 0xCAFEBABE,
+   sequence number 0x1234, and an all-zero rollover counter.
+
+       Session Key:      549752054D6FB708622C4A2E596A1B93
+       Session Salt:     AB01818174C40D39A3781F7C2D27
+
+       SSRC:                     CAFEBABE
+       Rollover Counter:                 00000000
+       Sequence Number:                          1234
+       ----------------------------------------------
+       Init. Counter:    AB018181BE3AB787A3781F7C3F130000
+
+   The SRTP session was negotiated to indicate that header extension ID
+   values 1, 3, and 4 are encrypted.
+
+   In hexadecimal, the header extension being encrypted is as follows
+   (spaces have been 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.)  The header extension "defined by profile" and "length"
+   fields, which in this case are BEDE 0006 in hexadecimal, are not
+   included in the encryption process.
+
+
+
+
+Lennox                       Standards Track                   [Page 14]
+
+RFC 6904            Encrypted SRTP Header Extensions          April 2013
+
+
+   In hexadecimal, 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 exclusive-
+   OR the keystream with the plaintext:
+
+       Initial keystream:  1E19C8E1D481C779549ED1617AAA1B7A
+                           FC0D933AE7ED6CC8
+       Mask (hex):         00FFFFFFFFFFFFFFFF0000000000FF00
+                           FFFFFFFFFFFFFF00
+       Masked keystream:   0019C8E1D481C7795400000000001B00
+                           FC0D933AE7ED6C00
+       Plaintext:          17414273A475262748220000C8308E46
+                           55996386B395FB00
+       Ciphertext:         17588A9270F4E15E1C220000C8309546
+                           A994F0BC54789700
+
+Author's Address
+
+   Jonathan Lennox
+   Vidyo, Inc.
+   433 Hackensack Avenue
+   Seventh Floor
+   Hackensack, NJ  07601
+   US
+
+   EMail: jonathan@vidyo.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lennox                       Standards Track                   [Page 15]
+