idnits 2.17.1 

draft-ietf-avtcore-srtp-encrypted-header-ext-04.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

     (Using the creation date from RFC3711, updated by this document, for
     RFC5378 checks: 2001-02-27)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (January 3, 2013) is 4129 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285)


     Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	AVTCORE                                                        J. Lennox
3	Internet-Draft                                                     Vidyo
4	Updates: 3711 (if approved)                              January 3, 2013
5	Intended status: Standards Track
6	Expires: July 7, 2013

8	   Encryption of Header Extensions in the Secure Real-Time Transport
9	                            Protocol (SRTP)
10	            draft-ietf-avtcore-srtp-encrypted-header-ext-04

12	Abstract

14	   The Secure Real-Time Transport Protocol (SRTP) provides
15	   authentication, but not encryption, of the headers of Real-Time
16	   Transport Protocol (RTP) packets.  However, RTP header extensions may
17	   carry sensitive information for which participants in multimedia
18	   sessions want confidentiality.  This document provides a mechanism,
19	   extending the mechanisms of SRTP, to selectively encrypt RTP header
20	   extensions in SRTP.

22	   This document updates RFC 3711, the Secure Real-Time Transport
23	   Protocol specification, to require that all future SRTP encryption
24	   transforms specify how RTP header extensions are to be encrypted.

26	Status of this Memo

28	   This Internet-Draft is submitted in full conformance with the
29	   provisions of BCP 78 and BCP 79.

31	   Internet-Drafts are working documents of the Internet Engineering
32	   Task Force (IETF).  Note that other groups may also distribute
33	   working documents as Internet-Drafts.  The list of current Internet-
34	   Drafts is at http://datatracker.ietf.org/drafts/current/.

36	   Internet-Drafts are draft documents valid for a maximum of six months
37	   and may be updated, replaced, or obsoleted by other documents at any
38	   time.  It is inappropriate to use Internet-Drafts as reference
39	   material or to cite them other than as "work in progress."

41	   This Internet-Draft will expire on July 7, 2013.

43	Copyright Notice

45	   Copyright (c) 2013 IETF Trust and the persons identified as the
46	   document authors.  All rights reserved.

48	   This document is subject to BCP 78 and the IETF Trust's Legal
49	   Provisions Relating to IETF Documents
50	   (http://trustee.ietf.org/license-info) in effect on the date of
51	   publication of this document.  Please review these documents
52	   carefully, as they describe your rights and restrictions with respect
53	   to this document.  Code Components extracted from this document must
54	   include Simplified BSD License text as described in Section 4.e of
55	   the Trust Legal Provisions and are provided without warranty as
56	   described in the Simplified BSD License.

58	Table of Contents

60	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
61	   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
62	   3.  Encryption Mechanism . . . . . . . . . . . . . . . . . . . . .  4
63	     3.1.  Example Encryption Mask  . . . . . . . . . . . . . . . . .  5
64	     3.2.  Header Extension Keystream Generation for Existing
65	           Encryption Transforms  . . . . . . . . . . . . . . . . . .  7
66	     3.3.  Header Extension Keystream Generation for Future
67	           Encryption Transforms  . . . . . . . . . . . . . . . . . .  7
68	   4.  Signaling (Setup) Information  . . . . . . . . . . . . . . . .  7
69	     4.1.  Backward compatibility . . . . . . . . . . . . . . . . . .  8
70	   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
71	   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
72	   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
73	   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
74	     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
75	     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
76	   Appendix A.  Test Vectors  . . . . . . . . . . . . . . . . . . . . 12
77	     A.1.  Key derivation test vectors  . . . . . . . . . . . . . . . 12
78	     A.2.  Header Encryption Test Vectors using AES-CM  . . . . . . . 13
79	   Appendix B.  Changes From Earlier Versions . . . . . . . . . . . . 14
80	     B.1.  Changes from draft-ietf-avtcore -03  . . . . . . . . . . . 14
81	     B.2.  Changes from draft-ietf-avtcore -02  . . . . . . . . . . . 14
82	     B.3.  Changes from draft-ietf-avtcore -01  . . . . . . . . . . . 14
83	     B.4.  Changes from draft-ietf-avtcore -00  . . . . . . . . . . . 15
84	     B.5.  Changes from draft-lennox-avtcore -00  . . . . . . . . . . 15
85	     B.6.  Changes from draft-lennox-avt -02  . . . . . . . . . . . . 15
86	     B.7.  Changes From Individual Submission Draft -01 . . . . . . . 15
87	     B.8.  Changes From Individual Submission Draft -00 . . . . . . . 16
88	   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16

90	1.  Introduction

92	   The Secure Real-Time Transport Protocol [RFC3711] specification
93	   provides confidentiality, message authentication, and replay
94	   protection for multimedia payloads sent using the Real-Time Protocol
95	   (RTP) [RFC3550].  However, in order to preserve RTP header
96	   compression efficiency, SRTP provides only authentication and replay
97	   protection for the headers of RTP packets, not confidentiality.

99	   For the standard portions of an RTP header, this does not normally
100	   present a problem, as the information carried in an RTP header does
101	   not provide much information beyond that which an attacker could
102	   infer by observing the size and timing of RTP packets.  Thus, there
103	   is little need for confidentiality of the header information.

105	   However, this is not necessarily true for information carried in RTP
106	   header extensions.  A number of recent proposals for header
107	   extensions using the General Mechanism for RTP Header Extensions
108	   [RFC5285] carry information for which confidentiality could be
109	   desired or essential.  Notably, two recent specifications ([RFC6464]
110	   and [RFC6465]) carry information about per-packet sound levels of the
111	   media data carried in the RTP payload, and exposing this to an
112	   eavesdropper is unacceptable in many circumstances.

114	   This document, therefore, defines a mechanism by which encryption can
115	   be applied to RTP header extensions when they are transported using
116	   SRTP.  As an RTP sender may wish some extension information to be
117	   sent in the clear (for example, it may be useful for a network
118	   monitoring device to be aware of RTP transmission time offsets
119	   [RFC5450]), this mechanism can be selectively applied to a subset of
120	   the header extension elements carried in an SRTP packet.

122	   The mechanism defined by this document encrypts packets' header
123	   extensions using the same cryptographic algorithms and parameters as
124	   are used to encrypt the packets' RTP payloads.  This document defines
125	   how this is done for the encryption transforms defined in [RFC3711],
126	   [RFC5669], and [RFC6188], the SRTP encryption transforms defined by
127	   standards-track IETF documents at the time of this writing.  It also
128	   updates [RFC3711], to indicate that specifications of future SRTP
129	   encryption transforms must define how header extension encryption is
130	   to be performed.

132	2.  Terminology

134	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
135	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
136	   document are to be interpreted as described in RFC 2119 [RFC2119] and
137	   indicate requirement levels for compliant implementations.

139	3.  Encryption Mechanism

141	   Encrypted header extension elements are carried in the same manner as
142	   non-encrypted header extension elements, as defined by [RFC5285].
143	   The (one- or two-byte) header of the extension elements is not
144	   encrypted, nor is any of the header extension padding.  If multiple
145	   different header extension elements are being encrypted, they have
146	   separate element identifier values, just as they would if they were
147	   not encrypted; similarly, encrypted and non-encrypted header
148	   extension elements have separate identifier values.

150	   Encrypted extension headers are only carried in packets encrypted
151	   using the Secure Real-Time Transport Protocol [RFC3711].  To encrypt
152	   (or decrypt) encrypted extension headers, an SRTP participant first
153	   uses the SRTP Key Derivation Algorithm, specified in Section 4.3.1 of
154	   [RFC3711], to generate header encryption and header salting keys,
155	   using the same pseudo-random function family as are used for the key
156	   derivation for the SRTP session.  These keys are derived as follows:
157	   o  k_he (SRTP header encryption): <label> = 0x06, n=n_e.
158	   o  k_hs (SRTP header salting key): <label> = 0x07, n=n_s.
159	   where n_e and n_s are from the cryptographic context: the same size
160	   encryption key and salting key are used as are used for the SRTP
161	   payload.  (Note that since RTP headers, including extension headers,
162	   are authenticated in SRTP, no new authentication key is needed for
163	   extension headers.)

165	   A header extension keystream is generated for each packet containing
166	   encrypted header extension elements.  The details of how this header
167	   extension keystream is generated depend on the encryption transform
168	   that is used for the SRTP packet.  For encryption transforms that
169	   have been standardized as of the publication of this document, see
170	   Section 3.2; for requirements for new transforms, see Section 3.3.

172	   Once the header extension keystream is generated, the SRTP
173	   participant then computes an encryption mask for the header
174	   extension, identifying the portions of the header extension that are,
175	   or are to be, encrypted.  This encryption mask corresponds to the
176	   entire payload of each header extension element that is encrypted.
177	   It does not include any non-encrypted header extension elements, any
178	   extension element headers, or any padding octets.  The encryption
179	   mask has all-bits-1 octets (i.e., hexadecimal 0xff) for header
180	   extension octets which are to be encrypted, and all-bits-0 octets for
181	   header extension octets which are not to be.  The set of extension
182	   elements to be encrypted is communicated between the sender and the
183	   receiver using the signaling mechanisms described in Section 4.

185	   This encryption mask is computed separately for every packet that
186	   carries a header extension.  Based on the non-encrypted portions of
187	   the headers and the signaled list of encrypted extension elements, a
188	   receiver can always determine the correct encryption mask for any
189	   encrypted header extension.

191	   The SRTP participant bitwise-ANDs the encryption mask with the
192	   keystream to produce a masked keystream.  It then bitwise exclusive-
193	   ors the header extension with this masked keystream to produce the
194	   ciphertext version of the header extension.  (Thus, octets indicated
195	   as all-bits-1 in the encrypted mask are encrypted, whereas those
196	   indicated as all-bits-0 are not.)

198	   The header extension encryption process does not include the "defined
199	   by profile" or "length" fields of the header extension, only the
200	   field that [RFC3550] Section 5.3.1 calls "header extension" proper,
201	   starting with the first [RFC5285] ID and length.  Thus, both the
202	   encryption mask and the keystream begin at this point.

204	   This header extension encryption process could, equivalently, be
205	   computed by considering the encryption mask as a mixture of the
206	   encrypted and unencrypted headers, i.e. as

208	       EncryptedHeader = (Encrypt(Key, Plaintext) AND MASK) OR
209	                         (Plaintext AND (NOT MASK))

211	   where Encrypt is the encryption function, MASK is the encryption
212	   mask, and AND, OR, and NOT are bitwise operations.  This formulation
213	   of the encryption process might be preferred by implementations for
214	   which encryption is performed by a separate module, and cannot easily
215	   be modified.

217	   The SRTP authentication tag is computed across the encrypted header
218	   extension, i.e., the data that is actually transmitted on the wire.
219	   Thus, header extension encryption MUST be done before the
220	   authentication tag is computed, and authentication tag validation
221	   MUST be done on the encrypted header extensions.  For receivers,
222	   header extension decryption SHOULD be done only after the receiver
223	   has validated the packet's message authentication tag, and the
224	   receiver MUST NOT take any actions based on decrypted headers that
225	   could affect the security or proper functioning of the system, prior
226	   to validating the authentication tag.

228	3.1.  Example Encryption Mask

230	   If a sender wished to send a header extension containing an encrypted
231	   SMPTE timecode [RFC5484] with ID 1, a plaintext transmission time
232	   offset [RFC5450] with ID 2, an encrypted audio level indication

234	   [RFC6464] with ID 3, and an encrypted NTP Timestamp [RFC6051] with ID
235	   4, the plaintext RTP header extension might look like this:

237	    0                   1                   2                   3
238	    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
239	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
240	   |  ID=1 | len=7 |     SMTPE timecode (long form)                |
241	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
242	   |       SMTPE timecode (continued)                              |
243	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
244	   | SMTPE (cont'd)|  ID=2 | len=2 | toffset                       |
245	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
246	   | toffset (ct'd)|  ID=3 | len=0 | audio level   |  ID=4 | len=6 |
247	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
248	   |       NTP Timestamp (Variant B)                               |
249	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
250	   |       NTP Timestamp (Variant B, cont.)        | padding = 0   |
251	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

253	                                 Figure 1

255	   The corresponding encryption mask would then be:

257	    0                   1                   2                   3
258	    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
259	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
260	   |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|
261	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
262	   |1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
263	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
264	   |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|
265	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
266	   |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|
267	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
268	   |1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
269	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
270	   |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|
271	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

273	                                 Figure 2

275	   In the mask, the octets corresponding to the payloads of the
276	   encrypted header extension elements are set to all-1 values, and
277	   octets corresponding to non-encrypted header extension elements,
278	   element headers, and header extension padding are set to all-0
279	   values.

281	3.2.  Header Extension Keystream Generation for Existing Encryption
282	      Transforms

284	   For the AES-CM and AES-f8 transforms [RFC3711], the SEED-CTR
285	   transform [RFC5669], and the AES_192_CM and AES_256_CM transforms
286	   [RFC6188], the header extension keystream SHALL be generated for each
287	   packet containing encrypted header extension elements, using the same
288	   encryption transform and Initialization Vector (IV) as is used for
289	   that packet's SRTP payload, except that the SRTP encryption and
290	   salting keys k_e and k_s are replaced by the SRTP header encryption
291	   and header salting keys k_he and k_hs, defined above, respectively.

293	   For the SEED-CCM and SEED-GCM transforms [RFC5669], the header
294	   extension keystream SHALL be generated using the algorithm specified
295	   above for the SEED-CTR algorithm.  (Because the AEAD transform used
296	   on the payload in these algorithms includes the RTP header, including
297	   the RTP header extension, in its Associated Authenticated Data (AAD),
298	   counter-mode encryption for the header extension is believed to be of
299	   equivalent cryptographic strength to the CCM and GCM transforms.)

301	   For the NULL encryption transform [RFC3711], the header extension
302	   keystream SHALL be all-zero.

304	3.3.  Header Extension Keystream Generation for Future Encryption
305	      Transforms

307	   When new SRTP encryption transforms are defined, this document
308	   updates [RFC3711] as follows: in addition to the rules specified in
309	   Section 6 of RFC 3711, the standard track RFC defining the new
310	   transform MUST specify how the encryption transform is to be used
311	   with header extension encryption.

313	   It is RECOMMENDED that new transformations follow the same mechanisms
314	   as are defined in Section 3.2, if these are applicable and are
315	   believed to be cryptographically adequate for the transform in
316	   question.

318	4.  Signaling (Setup) Information

320	   Encrypted header extension elements are signaled in the SDP extmap
321	   attribute, using the URI "urn:ietf:params:rtp-hdrext:encrypt",
322	   followed by the URI of the header extension element being encrypted
323	   as well as any extensionattributes that extension normally takes.
324	   Figure 3 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234]
325	   showing this grammar extension, extending the grammar defined in
326	   [RFC5285].

328	   enc-extensionname = %x75.72.6e.3a.69.65.74.66.3a.70.61.72.61.6d.73.3a
329	       %x72.74.70.2d.68.64.72.65.78.74.3a.65.6e.63.72.79.70.74
330	       ; "urn:ietf:params:rtp-hdrext:encrypt" in lower case

332	   extmap /= mapentry SP enc-extensionname SP extensionname
333	       [SP extensionattributes]

335	   ; extmap, mapentry, extensionname and extensionattributes
336	   ; are defined in [RFC5285]

338	                 Figure 3: Syntax of the "encrypt" extmap

340	   Thus, for example, to signal an SRTP session using encrypted SMPTE
341	   timecodes [RFC5484], while simultaneously signaling plaintext
342	   transmission time offsets [RFC5450], an SDP document could contain
343	   (line breaks added for formatting):

345	   m=audio 49170 RTP/SAVP 0
346	   a=crypto:1 AES_CM_128_HMAC_SHA1_32 \
347	     inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
348	   a=extmap:1 urn:ietf:params:rtp-hdrext:encrypt \
349	       urn:ietf:params:rtp-hdrext:smpte-tc 25@600/24
350	   a=extmap:2 urn:ietf:params:rtp-hdrext:toffset

352	                                 Figure 4

354	   This example uses SDP Security Descriptions [RFC4568] for SRTP
355	   keying, but this is merely for illustration; any SRTP keying
356	   mechanism to establish session keys will work.

358	   The extmap SDP attribute is defined in [RFC5285] as being either a
359	   session or media attribute.  If the extmap for an encrypted header
360	   extension is specified as a media attribute, it MUST only be
361	   specified for media which use SRTP-based RTP profiles.  If such an
362	   extmap is specified as a session attribute, there MUST be at least
363	   one media in the SDP session which uses an SRTP-based RTP profile;
364	   the session-level extmap applies to all the SRTP-based media in the
365	   session, and MUST be ignored for all other (non-SRTP or non-RTP)
366	   media.

368	   The "urn:ietf:params:rtp-hdrext:encrypt" extension MUST NOT be
369	   recursively applied to itself.

371	4.1.  Backward compatibility

373	   Following the procedures in [RFC5285], an SDP endpoint which does not
374	   understand the "urn:ietf:params:rtp-hdrext:encrypt" extension URI
375	   will ignore the extension, and (for SDP offer/answer) negotiate not
376	   to use it.

378	   In a negotiated session (whether using offer/answer or some other
379	   means), best-effort encryption of a header extension element is
380	   possible: an endpoint MAY offer the same header extension element
381	   both encrypted and unencrypted.  Receivers which understand header
382	   extension encryption SHOULD choose the encrypted form and mark the
383	   unencrypted form "inactive", unless they have an explicit reason to
384	   prefer the unencrypted form.  (Note that, as always, users of best-
385	   effort encryption MUST be cautious of bid-down attacks, where a man-
386	   in-the-middle attacker removes a higher-security option, forcing
387	   endpoints to negotiate a lower-security one.  Appropriate
388	   countermeasures depend on the signaling protocol in use, but users
389	   can ensure, for example, that signaling is integrity-protected.)

391	5.  Security Considerations

393	   The security properties of header extension elements protected by the
394	   mechanism in this document are equivalent to those for SRTP payloads.

396	   The mechanism defined in this document does not provide
397	   confidentiality about which header extension elements are used for a
398	   given SRTP packet, only for the content of those header extension
399	   elements.  This appears to be in the spirit of SRTP itself, which
400	   does not encrypt RTP headers.  If this is a concern, an alternate
401	   mechanism would be needed to provide confidentiality.

403	   For the two-byte-header form of header extension elements (0x100x),
404	   this mechanism does not provide any protection to zero-length header
405	   extension elements (for which their presence or absence is the only
406	   information they carry).  It also does not provide any protection for
407	   the two-byte-headers' app bits (field 256, the lowest four bits of
408	   the "defined by profile" field).  Neither of these features are
409	   present in for one-byte-header form of header extension elements
410	   (0xBEDE), so these limitations do not apply in that case.

412	   This mechanism cannot protect RTP header extensions which do not use
413	   the mechanism defined in [RFC5285].

415	   This document does not specify the circumstances in which extension
416	   header encryption should be used.  Documents defining specific header
417	   extension elements should provide guidance on when encryption is
418	   appropriate for these elements.

420	   If a middlebox does not have access to the SRTP authentication keys,
421	   it has no way to verify the authenticity of unencrypted RTP header
422	   extension elements (or the unencrypted RTP header), even though it
423	   can monitor them.  Therefore, such middleboxes MUST treat such
424	   headers as untrusted and potentially generated by an attacker, in the
425	   same way as unauthenticated traffic.  (This does not mean that
426	   middleboxes cannot view and interpret such traffic, of course, only
427	   that appropriate skepticism needs to be maintained about the results
428	   of such interpretation.).

430	   There is no mechanism defined to protect header extensions with
431	   different algorithms or encryption keys than are used to protect the
432	   RTP payloads.  In particular, it is not possible to provide
433	   confidentiality for a header extension while leaving the payload in
434	   cleartext.

436	   The technique defined in this document can only be applied to
437	   encryption transforms that work by generating a pseudorandom
438	   keystream and bitwise exclusive-oring it with the plaintext, such as
439	   CTR or f8.  It MUST NOT be used with ECB, CBC, or any other
440	   encryption method that does not use a keystream, or a loss of
441	   security will entail.

443	6.  IANA Considerations

445	   This document defines a new extension URI to the RTP Compact Header
446	   Extensions subregistry of the Real-Time Transport Protocol (RTP)
447	   Parameters registry, according to the following data:

449	   Extension URI:  urn:ietf:params:rtp-hdrext:encrypt
450	   Description:  Encrypted extension header element
451	   Contact:  jonathan@vidyo.com
452	   Reference:  RFC XXXX

454	   (Note to the RFC-Editor: please replace "XXXX" with the number of
455	   this document prior to publication as an RFC.)

457	7.  Acknowledgments

459	   Thanks to Roni Even, Kevin Igoe, David McGrew, Magnus Westerlund,
460	   David Singer, Robert Sparks, Qin Wu, and Felix Wyss for their
461	   comments and suggestions in the development of this specification.

463	8.  References
464	8.1.  Normative References

466	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
467	              Requirement Levels", BCP 14, RFC 2119, March 1997.

469	   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
470	              Jacobson, "RTP: A Transport Protocol for Real-Time
471	              Applications", STD 64, RFC 3550, July 2003.

473	   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
474	              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
475	              RFC 3711, March 2004.

477	   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
478	              Specifications: ABNF", STD 68, RFC 5234, January 2008.

480	   [RFC5285]  Singer, D. and H. Desineni, "A General Mechanism for RTP
481	              Header Extensions", RFC 5285, July 2008.

483	   [RFC5669]  Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The
484	              SEED Cipher Algorithm and Its Use with the Secure Real-
485	              Time Transport Protocol (SRTP)", RFC 5669, August 2010.

487	   [RFC6188]  McGrew, D., "The Use of AES-192 and AES-256 in Secure
488	              RTP", RFC 6188, March 2011.

490	8.2.  Informative References

492	   [RFC4568]  Andreasen, F., Baugher, M., and D. Wing, "Session
493	              Description Protocol (SDP) Security Descriptions for Media
494	              Streams", RFC 4568, July 2006.

496	   [RFC5450]  Singer, D. and H. Desineni, "Transmission Time Offsets in
497	              RTP Streams", RFC 5450, March 2009.

499	   [RFC5484]  Singer, D., "Associating Time-Codes with RTP Streams",
500	              RFC 5484, March 2009.

502	   [RFC6051]  Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
503	              Flows", RFC 6051, November 2010.

505	   [RFC6464]  Lennox, J., Ivov, E., and E. Marocco, "A Real-time
506	              Transport Protocol (RTP) Header Extension for Client-to-
507	              Mixer Audio Level Indication", RFC 6464, December 2011.

509	   [RFC6465]  Ivov, E., Marocco, E., and J. Lennox, "A Real-time
510	              Transport Protocol (RTP) Header Extension for Mixer-to-
511	              Client Audio Level Indication", RFC 6465, December 2011.

513	Appendix A.  Test Vectors

515	A.1.  Key derivation test vectors

517	   This section provides test data for the header extension key
518	   derivation function, using AES-128 in Counter Mode.  (The algorithms
519	   and keys used are the same as those for the the test vectors in
520	   Appendix B.3 of [RFC3711].)

522	   The inputs to the key derivation function are the 16 octet master key
523	   and the 14 octet master salt:
524	      master key: E1F97A0D3E018BE0D64FA32C06DE4139
525	      master salt: 0EC675AD498AFEEBB6960B3AABE6

527	   Following [RFC3711], the input block for AES-CM is generated by
528	   exclusive-oring the master salt with the concatenation of the
529	   encryption key label 0x06 with (index DIV kdr), then padding on the
530	   right with two null octets (which implements the multiply-by-2^16
531	   operation, see Section 4.3.3 of [RFC3711]).  The resulting value is
532	   then AES-CM- encrypted using the master key to get the cipher key.

534	     index DIV kdr:                    000000000000
535	     label:                          06
536	     master salt:      0EC675AD498AFEEBB6960B3AABE6
537	     --------------------------------------------------
538	     xor:              0EC675AD498AFEEDB6960B3AABE6     (x, PRF input)

540	     x*2^16:           0EC675AD498AFEEDB6960B3AABE60000 (AES-CM input)

542	     hdr. cipher key:  549752054D6FB708622C4A2E596A1B93 (AES-CM output)

544	   Next, we show how the cipher salt is generated.  The input block for
545	   AES-CM is generated by exclusive-oring the master salt with the
546	   concatenation of the encryption salt label.  That value is padded and
547	   encrypted as above.

549	     index DIV kdr:                    000000000000
550	     label:                          07
551	     master salt:      0EC675AD498AFEEBB6960B3AABE6

553	     --------------------------------------------------
554	     xor:              0EC675AD498AFEECB6960B3AABE6     (x, PRF input)

556	     x*2^16:           0EC675AD498AFEECB6960B3AABE60000 (AES-CM input)

558	                       AB01818174C40D39A3781F7C2D270733 (AES-CM ouptut)

560	     hdr. cipher salt: AB01818174C40D39A3781F7C2D27

562	A.2.  Header Encryption Test Vectors using AES-CM

564	   This section provides test vectors for the encryption of a header
565	   extension, using the AES_CM cryptographic transform.

567	   The header extension is encrypted using the header cipher key and
568	   header cipher salt computed in Appendix A.1.  The header extension is
569	   carried in an SRTP-encrypted RTP packet with SSRC 0xCAFEBABE,
570	   sequence number 0x1234, and an all-zero rollover counter.

572	       Session Key:      549752054D6FB708622C4A2E596A1B93
573	       Session Salt:     AB01818174C40D39A3781F7C2D27

575	       SSRC:                     CAFEBABE
576	       Rollover Counter:                 00000000
577	       Sequence Number:                          1234
578	       ----------------------------------------------
579	       Init. Counter:    AB018181BE3AB787A3781F7C3F130000

581	   The SRTP session was negotiated to indicate that header extension ID
582	   values 1, 3 and 4 are encrypted.

584	   In hexadecimal, the header extension being encrypted is (spaces added
585	   to show the internal structure of the header extension):

587	     17 414273A475262748 22 0000C8 30 8E 46 55996386B395FB 00

589	   This header extension is 24 bytes long.  (Its values are intended to
590	   represent plausible values of the header extension elements shown in
591	   Section 3.1, but their specific meaning is not important for the
592	   example.)  The header extension "defined by profile" and "length"
593	   fields, which in this case are BEDE 0006 in hexadecimal, are not
594	   included in the encryption process.

596	   In hexadecimal, the corresponding encryption mask selecting the
597	   bodies of header extensions 1, 2, and 4 (corresponding to the mask in
598	   Figure 2) is:

600	      00 FFFFFFFFFFFFFFFF 00 000000 00 FF 00 FFFFFFFFFFFFFF 00

602	   Finally, we compute the keystream from the session key and the
603	   initial counter, apply the mask to the keystream, and then xor the
604	   keystream with the plaintext:

606	       Initial keystream:  1E19C8E1D481C779549ED1617AAA1B7A
607	                           FC0D933AE7ED6CC8
608	       Mask (Hex):         00FFFFFFFFFFFFFFFF0000000000FF00
609	                           FFFFFFFFFFFFFF00
610	       Masked keystream:   0019C8E1D481C7795400000000001B00
611	                           FC0D933AE7ED6C00
612	       Plaintext:          17414273A475262748220000C8308E46
613	                           55996386B395FB00
614	       Ciphertext:         17588A9270F4E15E1C220000C8309546
615	                           A994F0BC54789700

617	Appendix B.  Changes From Earlier Versions

619	   Note to the RFC-Editor: please remove this section prior to
620	   publication as an RFC.

622	B.1.  Changes from draft-ietf-avtcore -03

624	   o  Modified the ABNF syntax to avoid rule recursion.
625	   o  Added Robert Sparks to the Acknowledgments.

627	B.2.  Changes from draft-ietf-avtcore -02

629	   o  Clarified that the header extension encryption mask must be
630	      calculated separately for each packet, and can always be derived
631	      from the plaintext portions of the encrypted header extension.
632	   o  Presented an alternate formulation of the header extension
633	      encryption process, so implementations can use their existing
634	      encryption algorithms unmodified.
635	   o  Added a security consideration emphasizing that this mechanism
636	      must only be used with keystream-based encryption algorithms.

638	B.3.  Changes from draft-ietf-avtcore -01

640	   o  Made the draft update RFC 3711, and added a section specifying
641	      that all future SRTP encryption transforms must specify how header
642	      extension encryption is to be done.
643	   o  Explicitly distinguished the processing of existing encryption
644	      transforms from future ones.
645	   o  Clarified description of the process by which the encryption mask
646	      is applied, and that encryption does not apply to the header
647	      extension "defined by profile" or "length" fields.
648	   o  Defined how header extension encryption is to be done with the
649	      SEED algorithms defined in RFC 5669, and with the NULL algorithm.
650	   o  Added ABNF grammar for the SDP syntax.

652	   o  Clarified that header extension encryption must not be applied to
653	      itself.
654	   o  Expanded discussion of bid-down attacks.
655	   o  Pointed out that this mechanism can't protect non-RFC5285 header
656	      extensions, and that there's no way to give different protection
657	      to header extensions than to payloads.
658	   o  Updated references to now-published RFCs.
659	   o  Editorial clarifications.
660	   o  Added Magnus Westerlund to the Acknowledgments.

662	B.4.  Changes from draft-ietf-avtcore -00

664	   o  Clarified usage of Key Derivation Algorithm
665	   o  Provided non-normative guidance for how to use this mechanism with
666	      Authenticated Encryption with Associated Data (AEAD) transforms.
667	   o  Corrected SMPTE Timecode header extension element in example
668	      header extension (it's eight bytes, not sixteen).  Added an NTP
669	      timestamp to the example to fill it back out to original size.
670	   o  Specified applicability of the extmap attribute if it's specified
671	      as a session-level attribute.
672	   o  Added description of backward compatibility, including a
673	      description of how you can negotiate best-effort encryption.
674	   o  Added a note to the security considerations about the dangers for
675	      middleboxes observing unencrypted headers (both header extension
676	      elements and RTP headers) without being able to verify the
677	      authentication keys.
678	   o  Added test vectors.
679	   o  Added acknowledgments section.

681	B.5.  Changes from draft-lennox-avtcore -00

683	   o  Published as working group item.
684	   o  Added discussion of limitations when used with the two-byte-header
685	      form of header extension elements.
686	   o  Added open issue about how to use this mechanism with
687	      Authenticated Encryption with Associated Data (AEAD) transforms.
688	   o  Updated references.

690	B.6.  Changes from draft-lennox-avt -02

692	   o  Retargeted at AVTCORE working group.
693	   o  Updated references.

695	B.7.  Changes From Individual Submission Draft -01

697	   o  Minor editorial changes.

699	B.8.  Changes From Individual Submission Draft -00

701	   o  Clarified description of encryption mask creation.
702	   o  Added example encryption mask.
703	   o  Editorial changes.

705	Author's Address

707	   Jonathan Lennox
708	   Vidyo, Inc.
709	   433 Hackensack Avenue
710	   Seventh Floor
711	   Hackensack, NJ  07601
712	   US

714	   Email: jonathan@vidyo.com