1
2
3
4
5
6
7Network Working Group                                         M. Baugher
8Request for Comments: 3711                                     D. McGrew
9Category: Standards Track                            Cisco Systems, Inc.
10                                                              M. Naslund
11                                                              E. Carrara
12                                                              K. Norrman
13                                                       Ericsson Research
14                                                              March 2004
15
16
17             The Secure Real-time Transport Protocol (SRTP)
18
19Status of this Memo
20
21   This document specifies an Internet standards track protocol for the
22   Internet community, and requests discussion and suggestions for
23   improvements.  Please refer to the current edition of the "Internet
24   Official Protocol Standards" (STD 1) for the standardization state
25   and status of this protocol.  Distribution of this memo is unlimited.
26
27Copyright Notice
28
29   Copyright (C) The Internet Society (2004).  All Rights Reserved.
30
31Abstract
32
33   This document describes the Secure Real-time Transport Protocol
34   (SRTP), a profile of the Real-time Transport Protocol (RTP), which
35   can provide confidentiality, message authentication, and replay
36   protection to the RTP traffic and to the control traffic for RTP, the
37   Real-time Transport Control Protocol (RTCP).
38
39Table of Contents
40
41   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
42       1.1.  Notational Conventions . . . . . . . . . . . . . . . . .  3
43   2.  Goals and Features . . . . . . . . . . . . . . . . . . . . . .  4
44       2.1.  Features . . . . . . . . . . . . . . . . . . . . . . . .  5
45   3.  SRTP Framework . . . . . . . . . . . . . . . . . . . . . . . .  5
46       3.1.  Secure RTP . . . . . . . . . . . . . . . . . . . . . . .  6
47       3.2.  SRTP Cryptographic Contexts. . . . . . . . . . . . . . .  7
48             3.2.1.  Transform-independent parameters . . . . . . . .  8
49             3.2.2.  Transform-dependent parameters . . . . . . . . . 10
50             3.2.3.  Mapping SRTP Packets to Cryptographic Contexts . 10
51       3.3.  SRTP Packet Processing . . . . . . . . . . . . . . . . . 11
52             3.3.1.  Packet Index Determination, and ROC, s_l Update. 13
53             3.3.2.  Replay Protection. . . . . . . . . . . . . . . . 15
54      3.4.  Secure RTCP . . . . . . . . . . . . . . . . . . . . . . . 15
55
56
57
58Baugher, et al.             Standards Track                     [Page 1]
59
60RFC 3711                          SRTP                        March 2004
61
62
63   4.  Pre-Defined Cryptographic Transforms . . . . . . . . . . . . . 19
64       4.1.  Encryption . . . . . . . . . . . . . . . . . . . . . . . 19
65             4.1.1.  AES in Counter Mode. . . . . . . . . . . . . . . 21
66             4.1.2.  AES in f8-mode . . . . . . . . . . . . . . . . . 22
67             4.1.3.  NULL Cipher. . . . . . . . . . . . . . . . . . . 25
68       4.2.  Message Authentication and Integrity . . . . . . . . . . 25
69             4.2.1.  HMAC-SHA1. . . . . . . . . . . . . . . . . . . . 25
70       4.3.  Key Derivation . . . . . . . . . . . . . . . . . . . . . 26
71             4.3.1.  Key Derivation Algorithm . . . . . . . . . . . . 26
72             4.3.2.  SRTCP Key Derivation . . . . . . . . . . . . . . 28
73             4.3.3.  AES-CM PRF . . . . . . . . . . . . . . . . . . . 28
74   5.  Default and mandatory-to-implement Transforms. . . . . . . . . 28
75       5.1.  Encryption: AES-CM and NULL. . . . . . . . . . . . . . . 29
76       5.2.  Message Authentication/Integrity: HMAC-SHA1. . . . . . . 29
77       5.3.  Key Derivation: AES-CM PRF . . . . . . . . . . . . . . . 29
78   6.  Adding SRTP Transforms . . . . . . . . . . . . . . . . . . . . 29
79   7.  Rationale. . . . . . . . . . . . . . . . . . . . . . . . . . . 30
80       7.1.  Key derivation . . . . . . . . . . . . . . . . . . . . . 30
81       7.2.  Salting key. . . . . . . . . . . . . . . . . . . . . . . 30
82       7.3.  Message Integrity from Universal Hashing . . . . . . . . 31
83       7.4.  Data Origin Authentication Considerations. . . . . . . . 31
84       7.5.  Short and Zero-length Message Authentication . . . . . . 32
85   8.  Key Management Considerations. . . . . . . . . . . . . . . . . 33
86       8.1.  Re-keying  . . . . . . . . . . . . . . . . . . . . . . . 34
87             8.1.1.  Use of the <From, To> for re-keying. . . . . . . 34
88       8.2.  Key Management parameters. . . . . . . . . . . . . . . . 35
89   9.  Security Considerations. . . . . . . . . . . . . . . . . . . . 37
90       9.1.  SSRC collision and two-time pad. . . . . . . . . . . . . 37
91       9.2.  Key Usage. . . . . . . . . . . . . . . . . . . . . . . . 38
92       9.3.  Confidentiality of the RTP Payload . . . . . . . . . . . 39
93       9.4.  Confidentiality of the RTP Header. . . . . . . . . . . . 40
94       9.5.  Integrity of the RTP payload and header. . . . . . . . . 40
95             9.5.1. Risks of Weak or Null Message Authentication. . . 42
96             9.5.2.  Implicit Header Authentication . . . . . . . . . 43
97   10.  Interaction with Forward Error Correction mechanisms. . . . . 43
98   11.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 43
99       11.1. Unicast. . . . . . . . . . . . . . . . . . . . . . . . . 43
100       11.2. Multicast (one sender) . . . . . . . . . . . . . . . . . 44
101       11.3. Re-keying and access control . . . . . . . . . . . . . . 45
102       11.4. Summary of basic scenarios . . . . . . . . . . . . . . . 46
103   12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 46
104   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
105   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
106       14.1. Normative References . . . . . . . . . . . . . . . . . . 47
107       14.2. Informative References . . . . . . . . . . . . . . . . . 48
108   Appendix A: Pseudocode for Index Determination . . . . . . . . . . 51
109   Appendix B: Test Vectors . . . . . . . . . . . . . . . . . . . . . 51
110       B.1.  AES-f8 Test Vectors. . . . . . . . . . . . . . . . . . . 51
111
112
113
114Baugher, et al.             Standards Track                     [Page 2]
115
116RFC 3711                          SRTP                        March 2004
117
118
119       B.2.  AES-CM Test Vectors. . . . . . . . . . . . . . . . . . . 52
120       B.3.  Key Derivation Test Vectors. . . . . . . . . . . . . . . 53
121   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
122   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 56
123
1241.  Introduction
125
126   This document describes the Secure Real-time Transport Protocol
127   (SRTP), a profile of the Real-time Transport Protocol (RTP), which
128   can provide confidentiality, message authentication, and replay
129   protection to the RTP traffic and to the control traffic for RTP,
130   RTCP (the Real-time Transport Control Protocol) [RFC3350].
131
132   SRTP provides a framework for encryption and message authentication
133   of RTP and RTCP streams (Section 3).  SRTP defines a set of default
134   cryptographic transforms (Sections 4 and 5), and it allows new
135   transforms to be introduced in the future (Section 6).  With
136   appropriate key management (Sections 7 and 8), SRTP is secure
137   (Sections 9) for unicast and multicast RTP applications (Section 11).
138
139   SRTP can achieve high throughput and low packet expansion.  SRTP
140   proves to be a suitable protection for heterogeneous environments
141   (mix of wired and wireless networks).  To get such features, default
142   transforms are described, based on an additive stream cipher for
143   encryption, a keyed-hash based function for message authentication,
144   and an "implicit" index for sequencing/synchronization based on the
145   RTP sequence number for SRTP and an index number for Secure RTCP
146   (SRTCP).
147
1481.1.  Notational Conventions
149
150   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
151   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
152   document are to be interpreted as described in [RFC2119].  The
153   terminology conforms to [RFC2828] with the following exception.  For
154   simplicity we use the term "random" throughout the document to denote
155   randomly or pseudo-randomly generated values.  Large amounts of
156   random bits may be difficult to obtain, and for the security of SRTP,
157   pseudo-randomness is sufficient [RFC1750].
158
159   By convention, the adopted representation is the network byte order,
160   i.e., the left most bit (octet) is the most significant one.  By XOR
161   we mean bitwise addition modulo 2 of binary strings, and || denotes
162   concatenation.  In other words, if C = A || B, then the most
163   significant bits of C are the bits of A, and the least significant
164   bits of C equal the bits of B.  Hexadecimal numbers are prefixed by
165   0x.
166
167
168
169
170Baugher, et al.             Standards Track                     [Page 3]
171
172RFC 3711                          SRTP                        March 2004
173
174
175   The word "encryption" includes also use of the NULL algorithm (which
176   in practice does leave the data in the clear).
177
178   With slight abuse of notation, we use the terms "message
179   authentication" and "authentication tag" as is common practice, even
180   though in some circumstances, e.g., group communication, the service
181   provided is actually only integrity protection and not data origin
182   authentication.
183
1842.  Goals and Features
185
186   The security goals for SRTP are to ensure:
187
188   *  the confidentiality of the RTP and RTCP payloads, and
189
190   *  the integrity of the entire RTP and RTCP packets, together with
191      protection against replayed packets.
192
193   These security services are optional and independent from each other,
194   except that SRTCP integrity protection is mandatory (malicious or
195   erroneous alteration of RTCP messages could otherwise disrupt the
196   processing of the RTP stream).
197
198   Other, functional, goals for the protocol are:
199
200   *  a framework that permits upgrading with new cryptographic
201      transforms,
202
203   *  low bandwidth cost, i.e., a framework preserving RTP header
204      compression efficiency,
205
206   and, asserted by the pre-defined transforms:
207
208   *  a low computational cost,
209
210   *  a small footprint (i.e., small code size and data memory for
211      keying information and replay lists),
212
213   *  limited packet expansion to support the bandwidth economy goal,
214
215   *  independence from the underlying transport, network, and physical
216      layers used by RTP, in particular high tolerance to packet loss
217      and re-ordering.
218
219   These properties ensure that SRTP is a suitable protection scheme for
220   RTP/RTCP in both wired and wireless scenarios.
221
222
223
224
225
226Baugher, et al.             Standards Track                     [Page 4]
227
228RFC 3711                          SRTP                        March 2004
229
230
2312.1.  Features
232
233   Besides the above mentioned direct goals, SRTP provides for some
234   additional features.  They have been introduced to lighten the burden
235   on key management and to further increase security.  They include:
236
237   *  A single "master key" can provide keying material for
238      confidentiality and integrity protection, both for the SRTP stream
239      and the corresponding SRTCP stream.  This is achieved with a key
240      derivation function (see Section 4.3), providing "session keys"
241      for the respective security primitive, securely derived from the
242      master key.
243
244   *  In addition, the key derivation can be configured to periodically
245      refresh the session keys, which limits the amount of ciphertext
246      produced by a fixed key, available for an adversary to
247      cryptanalyze.
248
249   *  "Salting keys" are used to protect against pre-computation and
250      time-memory tradeoff attacks [MF00] [BS00].
251
252   Detailed rationale for these features can be found in Section 7.
253
2543.  SRTP Framework
255
256   RTP is the Real-time Transport Protocol [RFC3550].  We define SRTP as
257   a profile of RTP.  This profile is an extension to the RTP
258   Audio/Video Profile [RFC3551].  Except where explicitly noted, all
259   aspects of that profile apply, with the addition of the SRTP security
260   features.  Conceptually, we consider SRTP to be a "bump in the stack"
261   implementation which resides between the RTP application and the
262   transport layer.  SRTP intercepts RTP packets and then forwards an
263   equivalent SRTP packet on the sending side, and intercepts SRTP
264   packets and passes an equivalent RTP packet up the stack on the
265   receiving side.
266
267   Secure RTCP (SRTCP) provides the same security services to RTCP as
268   SRTP does to RTP.  SRTCP message authentication is MANDATORY and
269   thereby protects the RTCP fields to keep track of membership, provide
270   feedback to RTP senders, or maintain packet sequence counters.  SRTCP
271   is described in Section 3.4.
272
273
274
275
276
277
278
279
280
281
282Baugher, et al.             Standards Track                     [Page 5]
283
284RFC 3711                          SRTP                        March 2004
285
286
2873.1.  Secure RTP
288
289      The format of an SRTP packet is illustrated in Figure 1.
290
291        0                   1                   2                   3
292      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
293     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
294     |V=2|P|X|  CC   |M|     PT      |       sequence number         | |
295     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
296     |                           timestamp                           | |
297     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
298     |           synchronization source (SSRC) identifier            | |
299     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
300     |            contributing source (CSRC) identifiers             | |
301     |                               ....                            | |
302     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
303     |                   RTP extension (OPTIONAL)                    | |
304   +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
305   | |                          payload  ...                         | |
306   | |                               +-------------------------------+ |
307   | |                               | RTP padding   | RTP pad count | |
308   +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
309   | ~                     SRTP MKI (OPTIONAL)                       ~ |
310   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
311   | :                 authentication tag (RECOMMENDED)              : |
312   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
313   |                                                                   |
314   +- Encrypted Portion*                      Authenticated Portion ---+
315
316   Figure 1.  The format of an SRTP packet.  *Encrypted Portion is the
317   same size as the plaintext for the Section 4 pre-defined transforms.
318
319   The "Encrypted Portion" of an SRTP packet consists of the encryption
320   of the RTP payload (including RTP padding when present) of the
321   equivalent RTP packet.  The Encrypted Portion MAY be the exact size
322   of the plaintext or MAY be larger.  Figure 1 shows the RTP payload
323   including any possible padding for RTP [RFC3550].
324
325   None of the pre-defined encryption transforms uses any padding; for
326   these, the RTP and SRTP payload sizes match exactly.  New transforms
327   added to SRTP (following Section 6) may require padding, and may
328   hence produce larger payloads.  RTP provides its own padding format
329   (as seen in Fig. 1), which due to the padding indicator in the RTP
330   header has merits in terms of compactness relative to paddings using
331   prefix-free codes.  This RTP padding SHALL be the default method for
332   transforms requiring padding.  Transforms MAY specify other padding
333   methods, and MUST then specify the amount, format, and processing of
334   their padding.  It is important to note that encryption transforms
335
336
337
338Baugher, et al.             Standards Track                     [Page 6]
339
340RFC 3711                          SRTP                        March 2004
341
342
343   that use padding are vulnerable to subtle attacks, especially when
344   message authentication is not used [V02].  Each specification for a
345   new encryption transform needs to carefully consider and describe the
346   security implications of the padding that it uses.  Message
347   authentication codes define their own padding, so this default does
348   not apply to authentication transforms.
349
350   The OPTIONAL MKI and the RECOMMENDED authentication tag are the only
351   fields defined by SRTP that are not in RTP.  Only 8-bit alignment is
352   assumed.
353
354      MKI (Master Key Identifier): configurable length, OPTIONAL.  The
355              MKI is defined, signaled, and used by key management.  The
356              MKI identifies the master key from which the session
357              key(s) were derived that authenticate and/or encrypt the
358              particular packet.  Note that the MKI SHALL NOT identify
359              the SRTP cryptographic context, which is identified
360              according to Section 3.2.3.  The MKI MAY be used by key
361              management for the purposes of re-keying, identifying a
362              particular master key within the cryptographic context
363              (Section 3.2.1).
364
365      Authentication tag: configurable length, RECOMMENDED.  The
366              authentication tag is used to carry message authentication
367              data.  The Authenticated Portion of an SRTP packet
368              consists of the RTP header followed by the Encrypted
369              Portion of the SRTP packet.  Thus, if both encryption and
370              authentication are applied, encryption SHALL be applied
371              before authentication on the sender side and conversely on
372              the receiver side.  The authentication tag provides
373              authentication of the RTP header and payload, and it
374              indirectly provides replay protection by authenticating
375              the sequence number.  Note that the MKI is not integrity
376              protected as this does not provide any extra protection.
377
3783.2.  SRTP Cryptographic Contexts
379
380   Each SRTP stream requires the sender and receiver to maintain
381   cryptographic state information.  This information is called the
382   "cryptographic context".
383
384   SRTP uses two types of keys: session keys and master keys.  By a
385   "session key", we mean a key which is used directly in a
386   cryptographic transform (e.g., encryption or message authentication),
387   and by a "master key", we mean a random bit string (given by the key
388   management protocol) from which session keys are derived in a
389
390
391
392
393
394Baugher, et al.             Standards Track                     [Page 7]
395
396RFC 3711                          SRTP                        March 2004
397
398
399   cryptographically secure way.  The master key(s) and other parameters
400   in the cryptographic context are provided by key management
401   mechanisms external to SRTP, see Section 8.
402
4033.2.1.  Transform-independent parameters
404
405   Transform-independent parameters are present in the cryptographic
406   context independently of the particular encryption or authentication
407   transforms that are used.  The transform-independent parameters of
408   the cryptographic context for SRTP consist of:
409
410   *  a 32-bit unsigned rollover counter (ROC), which records how many
411      times the 16-bit RTP sequence number has been reset to zero after
412      passing through 65,535.  Unlike the sequence number (SEQ), which
413      SRTP extracts from the RTP packet header, the ROC is maintained by
414      SRTP as described in Section 3.3.1.
415
416      We define the index of the SRTP packet corresponding to a given
417      ROC and RTP sequence number to be the 48-bit quantity
418
419            i = 2^16 * ROC + SEQ.
420
421   *  for the receiver only, a 16-bit sequence number s_l, which can be
422      thought of as the highest received RTP sequence number (see
423      Section 3.3.1 for its handling), which SHOULD be authenticated
424      since message authentication is RECOMMENDED,
425
426   *  an identifier for the encryption algorithm, i.e., the cipher and
427      its mode of operation,
428
429   *  an identifier for the message authentication algorithm,
430
431   *  a replay list, maintained by the receiver only (when
432      authentication and replay protection are provided), containing
433      indices of recently received and authenticated SRTP packets,
434
435   *  an MKI indicator (0/1) as to whether an MKI is present in SRTP and
436      SRTCP packets,
437
438   *  if the MKI indicator is set to one, the length (in octets) of the
439      MKI field, and (for the sender) the actual value of the currently
440      active MKI (the value of the MKI indicator and length MUST be kept
441      fixed for the lifetime of the context),
442
443   *  the master key(s), which MUST be random and kept secret,
444
445
446
447
448
449
450Baugher, et al.             Standards Track                     [Page 8]
451
452RFC 3711                          SRTP                        March 2004
453
454
455   *  for each master key, there is a counter of the number of SRTP
456      packets that have been processed (sent) with that master key
457      (essential for security, see Sections 3.3.1 and 9),
458
459   *  non-negative integers n_e, and n_a, determining the length of the
460      session keys for encryption, and message authentication.
461
462   In addition, for each master key, an SRTP stream MAY use the
463   following associated values:
464
465   *  a master salt, to be used in the key derivation of session keys.
466      This value, when used, MUST be random, but MAY be public.  Use of
467      master salt is strongly RECOMMENDED, see Section 9.2.  A "NULL"
468      salt is treated as 00...0.
469
470   *  an integer in the set {1,2,4,...,2^24}, the "key_derivation_rate",
471      where an unspecified value is treated as zero.  The constraint to
472      be a power of 2 simplifies the session-key derivation
473      implementation, see Section 4.3.
474
475   *  an MKI value,
476
477   *  <From, To> values, specifying the lifetime for a master key,
478      expressed in terms of the two 48-bit index values inside whose
479      range (including the range end-points) the master key is valid.
480      For the use of <From, To>, see Section 8.1.1.  <From, To> is an
481      alternative to the MKI and assumes that a master key is in one-
482      to-one correspondence with the SRTP session key on which the
483      <From, To> range is defined.
484
485   SRTCP SHALL by default share the crypto context with SRTP, except:
486
487   *  no rollover counter and s_l-value need to be maintained as the
488      RTCP index is explicitly carried in each SRTCP packet,
489
490   *  a separate replay list is maintained (when replay protection is
491      provided),
492
493   *  SRTCP maintains a separate counter for its master key (even if the
494      master key is the same as that for SRTP, see below), as a means to
495      maintain a count of the number of SRTCP packets that have been
496      processed with that key.
497
498   Note in particular that the master key(s) MAY be shared between SRTP
499   and the corresponding SRTCP, if the pre-defined transforms (including
500   the key derivation) are used but the session key(s) MUST NOT be so
501   shared.
502
503
504
505
506Baugher, et al.             Standards Track                     [Page 9]
507
508RFC 3711                          SRTP                        March 2004
509
510
511   In addition, there can be cases (see Sections 8 and 9.1) where
512   several SRTP streams within a given RTP session, identified by their
513   synchronization source (SSRCs, which is part of the RTP header),
514   share most of the crypto context parameters (including possibly
515   master and session keys).  In such cases, just as in the normal
516   SRTP/SRTCP parameter sharing above, separate replay lists and packet
517   counters for each stream (SSRC) MUST still be maintained.  Also,
518   separate SRTP indices MUST then be maintained.
519
520   A summary of parameters, pre-defined transforms, and default values
521   for the above parameters (and other SRTP parameters) can be found in
522   Sections 5 and 8.2.
523
5243.2.2.  Transform-dependent parameters
525
526   All encryption, authentication/integrity, and key derivation
527   parameters are defined in the transforms section (Section 4).
528   Typical examples of such parameters are block size of ciphers,
529   session keys, data for the Initialization Vector (IV) formation, etc.
530   Future SRTP transform specifications MUST include a section to list
531   the additional cryptographic context's parameters for that transform,
532   if any.
533
5343.2.3.  Mapping SRTP Packets to Cryptographic Contexts
535
536   Recall that an RTP session for each participant is defined [RFC3550]
537   by a pair of destination transport addresses (one network address
538   plus a port pair for RTP and RTCP), and that a multimedia session is
539   defined as a collection of RTP sessions.  For example, a particular
540   multimedia session could include an audio RTP session, a video RTP
541   session, and a text RTP session.
542
543   A cryptographic context SHALL be uniquely identified by the triplet
544   context identifier:
545
546   context id = <SSRC, destination network address, destination
547   transport port number>
548
549   where the destination network address and the destination transport
550   port are the ones in the SRTP packet.  It is assumed that, when
551   presented with this information, the key management returns a context
552   with the information as described in Section 3.2.
553
554   As noted above, SRTP and SRTCP by default share the bulk of the
555   parameters in the cryptographic context.  Thus, retrieving the crypto
556   context parameters for an SRTCP stream in practice may imply a
557   binding to the correspondent SRTP crypto context.  It is up to the
558   implementation to assure such binding, since the RTCP port may not be
559
560
561
562Baugher, et al.             Standards Track                    [Page 10]
563
564RFC 3711                          SRTP                        March 2004
565
566
567   directly deducible from the RTP port only.  Alternatively, the key
568   management may choose to provide separate SRTP- and SRTCP- contexts,
569   duplicating the common parameters (such as master key(s)).  The
570   latter approach then also enables SRTP and SRTCP to use, e.g.,
571   distinct transforms, if so desired.  Similar considerations arise
572   when multiple SRTP streams, forming part of one single RTP session,
573   share keys and other parameters.
574
575   If no valid context can be found for a packet corresponding to a
576   certain context identifier, that packet MUST be discarded.
577
5783.3.  SRTP Packet Processing
579
580   The following applies to SRTP.  SRTCP is described in Section 3.4.
581
582   Assuming initialization of the cryptographic context(s) has taken
583   place via key management, the sender SHALL do the following to
584   construct an SRTP packet:
585
586   1. Determine which cryptographic context to use as described in
587      Section 3.2.3.
588
589   2. Determine the index of the SRTP packet using the rollover counter,
590      the highest sequence number in the cryptographic context, and the
591      sequence number in the RTP packet, as described in Section 3.3.1.
592
593   3. Determine the master key and master salt.  This is done using the
594      index determined in the previous step or the current MKI in the
595      cryptographic context, according to Section 8.1.
596
597   4. Determine the session keys and session salt (if they are used by
598      the transform) as described in Section 4.3, using master key,
599      master salt, key_derivation_rate, and session key-lengths in the
600      cryptographic context with the index, determined in Steps 2 and 3.
601
602   5. Encrypt the RTP payload to produce the Encrypted Portion of the
603      packet (see Section 4.1, for the defined ciphers).  This step uses
604      the encryption algorithm indicated in the cryptographic context,
605      the session encryption key and the session salt (if used) found in
606      Step 4 together with the index found in Step 2.
607
608   6. If the MKI indicator is set to one, append the MKI to the packet.
609
610   7. For message authentication, compute the authentication tag for the
611      Authenticated Portion of the packet, as described in Section 4.2.
612      This step uses the current rollover counter, the authentication
613
614
615
616
617
618Baugher, et al.             Standards Track                    [Page 11]
619
620RFC 3711                          SRTP                        March 2004
621
622
623      algorithm indicated in the cryptographic context, and the session
624      authentication key found in Step 4.  Append the authentication tag
625      to the packet.
626
627   8. If necessary, update the ROC as in Section 3.3.1, using the packet
628      index determined in Step 2.
629
630   To authenticate and decrypt an SRTP packet, the receiver SHALL do the
631   following:
632
633   1. Determine which cryptographic context to use as described in
634      Section 3.2.3.
635
636   2. Run the algorithm in Section 3.3.1 to get the index of the SRTP
637      packet.  The algorithm uses the rollover counter and highest
638      sequence number in the cryptographic context with the sequence
639      number in the SRTP packet, as described in Section 3.3.1.
640
641   3. Determine the master key and master salt.  If the MKI indicator in
642      the context is set to one, use the MKI in the SRTP packet,
643      otherwise use the index from the previous step, according to
644      Section 8.1.
645
646   4. Determine the session keys, and session salt (if used by the
647      transform) as described in Section 4.3, using master key, master
648      salt, key_derivation_rate and session key-lengths in the
649      cryptographic context with the index, determined in Steps 2 and 3.
650
651   5. For message authentication and replay protection, first check if
652      the packet has been replayed (Section 3.3.2), using the Replay
653      List and the index as determined in Step 2.  If the packet is
654      judged to be replayed, then the packet MUST be discarded, and the
655      event SHOULD be logged.
656
657      Next, perform verification of the authentication tag, using the
658      rollover counter from Step 2, the authentication algorithm
659      indicated in the cryptographic context, and the session
660      authentication key from Step 4.  If the result is "AUTHENTICATION
661      FAILURE" (see Section 4.2), the packet MUST be discarded from
662      further processing and the event SHOULD be logged.
663
664   6. Decrypt the Encrypted Portion of the packet (see Section 4.1, for
665      the defined ciphers), using the decryption algorithm indicated in
666      the cryptographic context, the session encryption key and salt (if
667      used) found in Step 4 with the index from Step 2.
668
669
670
671
672
673
674Baugher, et al.             Standards Track                    [Page 12]
675
676RFC 3711                          SRTP                        March 2004
677
678
679   7. Update the rollover counter and highest sequence number, s_l, in
680      the cryptographic context as in Section 3.3.1, using the packet
681      index estimated in Step 2.  If replay protection is provided, also
682      update the Replay List as described in Section 3.3.2.
683
684   8. When present, remove the MKI and authentication tag fields from
685      the packet.
686
6873.3.1.  Packet Index Determination, and ROC, s_l Update
688
689   SRTP implementations use an "implicit" packet index for sequencing,
690   i.e., not all of the index is explicitly carried in the SRTP packet.
691   For the pre-defined transforms, the index i is used in replay
692   protection (Section 3.3.2), encryption (Section 4.1), message
693   authentication (Section 4.2), and for the key derivation (Section
694   4.3).
695
696   When the session starts, the sender side MUST set the rollover
697   counter, ROC, to zero.  Each time the RTP sequence number, SEQ, wraps
698   modulo 2^16, the sender side MUST increment ROC by one, modulo 2^32
699   (see security aspects below).  The sender's packet index is then
700   defined as
701
702      i = 2^16 * ROC + SEQ.
703
704   Receiver-side implementations use the RTP sequence number to
705   determine the correct index of a packet, which is the location of the
706   packet in the sequence of all SRTP packets.  A robust approach for
707   the proper use of a rollover counter requires its handling and use to
708   be well defined.  In particular, out-of-order RTP packets with
709   sequence numbers close to 2^16 or zero must be properly handled.
710
711   The index estimate is based on the receiver's locally maintained ROC
712   and s_l values.  At the setup of the session, the ROC MUST be set to
713   zero.  Receivers joining an on-going session MUST be given the
714   current ROC value using out-of-band signaling such as key-management
715   signaling.  Furthermore, the receiver SHALL initialize s_l to the RTP
716   sequence number (SEQ) of the first observed SRTP packet (unless the
717   initial value is provided by out of band signaling such as key
718   management).
719
720   On consecutive SRTP packets, the receiver SHOULD estimate the index
721   as
722         i = 2^16 * v + SEQ,
723
724   where v is chosen from the set { ROC-1, ROC, ROC+1 } (modulo 2^32)
725   such that i is closest (in modulo 2^48 sense) to the value 2^16 * ROC
726   + s_l (see Appendix A for pseudocode).
727
728
729
730Baugher, et al.             Standards Track                    [Page 13]
731
732RFC 3711                          SRTP                        March 2004
733
734
735   After the packet has been processed and authenticated (when enabled
736   for SRTP packets for the session), the receiver MUST use v to
737   conditionally update its s_l and ROC variables as follows.  If
738   v=(ROC-1) mod 2^32, then there is no update to s_l or ROC.  If v=ROC,
739   then s_l is set to SEQ if and only if SEQ is larger than the current
740   s_l; there is no change to ROC.  If v=(ROC+1) mod 2^32, then s_l is
741   set to SEQ and ROC is set to v.
742
743   After a re-keying occurs (changing to a new master key), the rollover
744   counter always maintains its sequence of values, i.e., it MUST NOT be
745   reset to zero.
746
747   As the rollover counter is 32 bits long and the sequence number is 16
748   bits long, the maximum number of packets belonging to a given SRTP
749   stream that can be secured with the same key is 2^48 using the pre-
750   defined transforms.  After that number of SRTP packets have been sent
751   with a given (master or session) key, the sender MUST NOT send any
752   more packets with that key.  (There exists a similar limit for SRTCP,
753   which in practice may be more restrictive, see Section 9.2.)  This
754   limitation enforces a security benefit by providing an upper bound on
755   the amount of traffic that can pass before cryptographic keys are
756   changed.  Re-keying (see Section 8.1) MUST be triggered, before this
757   amount of traffic, and MAY be triggered earlier, e.g., for increased
758   security and access control to media.  Recurring key derivation by
759   means of a non-zero key_derivation_rate (see Section 4.3), also gives
760   stronger security but does not change the above absolute maximum
761   value.
762
763   On the receiver side, there is a caveat to updating s_l and ROC: if
764   message authentication is not present, neither the initialization of
765   s_l, nor the ROC update can be made completely robust.  The
766   receiver's "implicit index" approach works for the pre-defined
767   transforms as long as the reorder and loss of the packets are not too
768   great and bit-errors do not occur in unfortunate ways.  In
769   particular, 2^15 packets would need to be lost, or a packet would
770   need to be 2^15 packets out of sequence before synchronization is
771   lost.  Such drastic loss or reorder is likely to disrupt the RTP
772   application itself.
773
774   The algorithm for the index estimate and ROC update is a matter of
775   implementation, and should take into consideration the environment
776   (e.g., packet loss rate) and the cases when synchronization is likely
777   to be lost, e.g., when the initial sequence number (randomly chosen
778   by RTP) is not known in advance (not sent in the key management
779   protocol) but may be near to wrap modulo 2^16.
780
781
782
783
784
785
786Baugher, et al.             Standards Track                    [Page 14]
787
788RFC 3711                          SRTP                        March 2004
789
790
791   A more elaborate and more robust scheme than the one given above is
792   the handling of RTP's own "rollover counter", see Appendix A.1 of
793   [RFC3550].
794
7953.3.2.  Replay Protection
796
797   Secure replay protection is only possible when integrity protection
798   is present.  It is RECOMMENDED to use replay protection, both for RTP
799   and RTCP, as integrity protection alone cannot assure security
800   against replay attacks.
801
802   A packet is "replayed" when it is stored by an adversary, and then
803   re-injected into the network.  When message authentication is
804   provided, SRTP protects against such attacks through a Replay List.
805   Each SRTP receiver maintains a Replay List, which conceptually
806   contains the indices of all of the packets which have been received
807   and authenticated.  In practice, the list can use a "sliding window"
808   approach, so that a fixed amount of storage suffices for replay
809   protection.  Packet indices which lag behind the packet index in the
810   context by more than SRTP-WINDOW-SIZE can be assumed to have been
811   received, where SRTP-WINDOW-SIZE is a receiver-side, implementation-
812   dependent parameter and MUST be at least 64, but which MAY be set to
813   a higher value.
814
815   The receiver checks the index of an incoming packet against the
816   replay list and the window.  Only packets with index ahead of the
817   window, or, inside the window but not already received, SHALL be
818   accepted.
819
820   After the packet has been authenticated (if necessary the window is
821   first moved ahead), the replay list SHALL be updated with the new
822   index.
823
824   The Replay List can be efficiently implemented by using a bitmap to
825   represent which packets have been received, as described in the
826   Security Architecture for IP [RFC2401].
827
8283.4.  Secure RTCP
829
830   Secure RTCP follows the definition of Secure RTP.  SRTCP adds three
831   mandatory new fields (the SRTCP index, an "encrypt-flag", and the
832   authentication tag) and one optional field (the MKI) to the RTCP
833   packet definition.  The three mandatory fields MUST be appended to an
834   RTCP packet in order to form an equivalent SRTCP packet.  The added
835   fields follow any other profile-specific extensions.
836
837
838
839
840
841
842Baugher, et al.             Standards Track                    [Page 15]
843
844RFC 3711                          SRTP                        March 2004
845
846
847   According to Section 6.1 of [RFC3550], there is a REQUIRED packet
848   format for compound packets.  SRTCP MUST be given packets according
849   to that requirement in the sense that the first part MUST be a sender
850   report or a receiver report.  However, the RTCP encryption prefix (a
851   random 32-bit quantity) specified in that Section MUST NOT be used
852   since, as is stated there, it is only applicable to the encryption
853   method specified in [RFC3550] and is not needed by the cryptographic
854   mechanisms used in SRTP.
855
856      0                   1                   2                   3
857      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
858     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
859     |V=2|P|    RC   |   PT=SR or RR   |             length          | |
860     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
861     |                         SSRC of sender                        | |
862   +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
863   | ~                          sender info                          ~ |
864   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
865   | ~                         report block 1                        ~ |
866   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
867   | ~                         report block 2                        ~ |
868   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
869   | ~                              ...                              ~ |
870   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
871   | |V=2|P|    SC   |  PT=SDES=202  |             length            | |
872   | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
873   | |                          SSRC/CSRC_1                          | |
874   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
875   | ~                           SDES items                          ~ |
876   | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
877   | ~                              ...                              ~ |
878   +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
879   | |E|                         SRTCP index                         | |
880   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
881   | ~                     SRTCP MKI (OPTIONAL)                      ~ |
882   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
883   | :                     authentication tag                        : |
884   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
885   |                                                                   |
886   +-- Encrypted Portion                    Authenticated Portion -----+
887
888
889   Figure 2.  An example of the format of a Secure RTCP packet,
890   consisting of an underlying RTCP compound packet with a Sender Report
891   and SDES packet.
892
893
894
895
896
897
898Baugher, et al.             Standards Track                    [Page 16]
899
900RFC 3711                          SRTP                        March 2004
901
902
903   The Encrypted Portion of an SRTCP packet consists of the encryption
904   (Section 4.1) of the RTCP payload of the equivalent compound RTCP
905   packet, from the first RTCP packet, i.e., from the ninth (9) octet to
906   the end of the compound packet.  The Authenticated Portion of an
907   SRTCP packet consists of the entire equivalent (eventually compound)
908   RTCP packet, the E flag, and the SRTCP index (after any encryption
909   has been applied to the payload).
910
911   The added fields are:
912
913   E-flag: 1 bit, REQUIRED
914            The E-flag indicates if the current SRTCP packet is
915            encrypted or unencrypted.  Section 9.1 of [RFC3550] allows
916            the split of a compound RTCP packet into two lower-layer
917            packets, one to be encrypted and one to be sent in the
918            clear.  The E bit set to "1" indicates encrypted packet, and
919            "0" indicates non-encrypted packet.
920
921   SRTCP index: 31 bits, REQUIRED
922            The SRTCP index is a 31-bit counter for the SRTCP packet.
923            The index is explicitly included in each packet, in contrast
924            to the "implicit" index approach used for SRTP.  The SRTCP
925            index MUST be set to zero before the first SRTCP packet is
926            sent, and MUST be incremented by one, modulo 2^31, after
927            each SRTCP packet is sent.  In particular, after a re-key,
928            the SRTCP index MUST NOT be reset to zero again.
929
930   Authentication Tag: configurable length, REQUIRED
931            The authentication tag is used to carry message
932            authentication data.
933
934   MKI: configurable length, OPTIONAL
935            The MKI is the Master Key Indicator, and functions according
936            to the MKI definition in Section 3.
937
938   SRTCP uses the cryptographic context parameters and packet processing
939   of SRTP by default, with the following changes:
940
941   *  The receiver does not need to "estimate" the index, as it is
942      explicitly signaled in the packet.
943
944   *  Pre-defined SRTCP encryption is as specified in Section 4.1, but
945      using the definition of the SRTCP Encrypted Portion given in this
946      section, and using the SRTCP index as the index i.  The encryption
947      transform and related parameters SHALL by default be the same
948      selected for the protection of the associated SRTP stream(s),
949      while the NULL algorithm SHALL be applied to the RTCP packets not
950      to be encrypted.  SRTCP may have a different encryption transform
951
952
953
954Baugher, et al.             Standards Track                    [Page 17]
955
956RFC 3711                          SRTP                        March 2004
957
958
959      than the one used by the corresponding SRTP.  The expected use for
960      this feature is when the former has NULL-encryption and the latter
961      has a non NULL-encryption.
962
963   The E-flag is assigned a value by the sender depending on whether the
964   packet was encrypted or not.
965
966   *  SRTCP decryption is performed as in Section 4, but only if the E
967      flag is equal to 1.  If so, the Encrypted Portion is decrypted,
968      using the SRTCP index as the index i.  In case the E-flag is 0,
969      the payload is simply left unmodified.
970
971   *  SRTCP replay protection is as defined in Section 3.3.2, but using
972      the SRTCP index as the index i and a separate Replay List that is
973      specific to SRTCP.
974
975   *  The pre-defined SRTCP authentication tag is specified as in
976      Section 4.2, but with the Authenticated Portion of the SRTCP
977      packet given in this section (which includes the index).  The
978      authentication transform and related parameters (e.g., key size)
979      SHALL by default be the same as selected for the protection of the
980      associated SRTP stream(s).
981
982   *  In the last step of the processing, only the sender needs to
983      update the value of the SRTCP index by incrementing it modulo 2^31
984      and for security reasons the sender MUST also check the number of
985      SRTCP packets processed, see Section 9.2.
986
987   Message authentication for RTCP is REQUIRED, as it is the control
988   protocol (e.g., it has a BYE packet) for RTP.
989
990   Precautions must be taken so that the packet expansion in SRTCP (due
991   to the added fields) does not cause SRTCP messages to use more than
992   their share of RTCP bandwidth.  To avoid this, the following two
993   measures MUST be taken:
994
995   1. When initializing the RTCP variable "avg_rtcp_size" defined in
996      chapter 6.3 of [RFC3550], it MUST include the size of the fields
997      that will be added by SRTCP (index, E-bit, authentication tag, and
998      when present, the MKI).
999
1000   2. When updating the "avg_rtcp_size" using the variable "packet_size"
1001      (section 6.3.3 of [RFC3550]), the value of "packet_size" MUST
1002      include the size of the additional fields added by SRTCP.
1003
1004
1005
1006
1007
1008
1009
1010Baugher, et al.             Standards Track                    [Page 18]
1011
1012RFC 3711                          SRTP                        March 2004
1013
1014
1015   With these measures in place the SRTCP messages will not use more
1016   than the allotted bandwidth.  The effect of the size of the added
1017   fields on the SRTCP traffic will be that messages will be sent with
1018   longer packet intervals.  The increase in the intervals will be
1019   directly proportional to size of the added fields.  For the pre-
1020   defined transforms, the size of the added fields will be at least 14
1021   octets, and upper bounded depending on MKI and the authentication tag
1022   sizes.
1023
10244.  Pre-Defined Cryptographic Transforms
1025
1026   While there are numerous encryption and message authentication
1027   algorithms that can be used in SRTP, below we define default
1028   algorithms in order to avoid the complexity of specifying the
1029   encodings for the signaling of algorithm and parameter identifiers.
1030   The defined algorithms have been chosen as they fulfill the goals
1031   listed in Section 2.  Recommendations on how to extend SRTP with new
1032   transforms are given in Section 6.
1033
10344.1.  Encryption
1035
1036   The following parameters are common to both pre-defined, non-NULL,
1037   encryption transforms specified in this section.
1038
1039   *  BLOCK_CIPHER-MODE indicates the block cipher used and its mode of
1040      operation
1041   *  n_b is the bit-size of the block for the block cipher
1042   *  k_e is the session encryption key
1043   *  n_e is the bit-length of k_e
1044   *  k_s is the session salting key
1045   *  n_s is the bit-length of k_s
1046   *  SRTP_PREFIX_LENGTH is the octet length of the keystream prefix, a
1047      non-negative integer, specified by the message authentication code
1048      in use.
1049
1050   The distinct session keys and salts for SRTP/SRTCP are by default
1051   derived as specified in Section 4.3.
1052
1053   The encryption transforms defined in SRTP map the SRTP packet index
1054   and secret key into a pseudo-random keystream segment.  Each
1055   keystream segment encrypts a single RTP packet.  The process of
1056   encrypting a packet consists of generating the keystream segment
1057   corresponding to the packet, and then bitwise exclusive-oring that
1058   keystream segment onto the payload of the RTP packet to produce the
1059   Encrypted Portion of the SRTP packet.  In case the payload size is
1060   not an integer multiple of n_b bits, the excess (least significant)
1061   bits of the keystream are simply discarded.  Decryption is done the
1062   same way, but swapping the roles of the plaintext and ciphertext.
1063
1064
1065
1066Baugher, et al.             Standards Track                    [Page 19]
1067
1068RFC 3711                          SRTP                        March 2004
1069
1070
1071   +----+   +------------------+---------------------------------+
1072   | KG |-->| Keystream Prefix |          Keystream Suffix       |---+
1073   +----+   +------------------+---------------------------------+   |
1074                                                                     |
1075                               +---------------------------------+   v
1076                               |     Payload of RTP Packet       |->(*)
1077                               +---------------------------------+   |
1078                                                                     |
1079                               +---------------------------------+   |
1080                               | Encrypted Portion of SRTP Packet|<--+
1081                               +---------------------------------+
1082
1083   Figure 3: Default SRTP Encryption Processing.  Here KG denotes the
1084   keystream generator, and (*) denotes bitwise exclusive-or.
1085
1086   The definition of how the keystream is generated, given the index,
1087   depends on the cipher and its mode of operation.  Below, two such
1088   keystream generators are defined.  The NULL cipher is also defined,
1089   to be used when encryption of RTP is not required.
1090
1091   The SRTP definition of the keystream is illustrated in Figure 3.  The
1092   initial octets of each keystream segment MAY be reserved for use in a
1093   message authentication code, in which case the keystream used for
1094   encryption starts immediately after the last reserved octet.  The
1095   initial reserved octets are called the "keystream prefix" (not to be
1096   confused with the "encryption prefix" of [RFC3550, Section 6.1]), and
1097   the remaining octets are called the "keystream suffix".  The
1098   keystream prefix MUST NOT be used for encryption.  The process is
1099   illustrated in Figure 3.
1100
1101   The number of octets in the keystream prefix is denoted as
1102   SRTP_PREFIX_LENGTH.  The keystream prefix is indicated by a positive,
1103   non-zero value of SRTP_PREFIX_LENGTH.  This means that, even if
1104   confidentiality is not to be provided, the keystream generator output
1105   may still need to be computed for packet authentication, in which
1106   case the default keystream generator (mode) SHALL be used.
1107
1108   The default cipher is the Advanced Encryption Standard (AES) [AES],
1109   and we define two modes of running AES, (1) Segmented Integer Counter
1110   Mode AES and (2) AES in f8-mode.  In the remainder of this section,
1111   let E(k,x) be AES applied to key k and input block x.
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122Baugher, et al.             Standards Track                    [Page 20]
1123
1124RFC 3711                          SRTP                        March 2004
1125
1126
11274.1.1.  AES in Counter Mode
1128
1129   Conceptually, counter mode [AES-CTR] consists of encrypting
1130   successive integers.  The actual definition is somewhat more
1131   complicated, in order to randomize the starting point of the integer
1132   sequence.  Each packet is encrypted with a distinct keystream
1133   segment, which SHALL be computed as follows.
1134
1135   A keystream segment SHALL be the concatenation of the 128-bit output
1136   blocks of the AES cipher in the encrypt direction, using key k = k_e,
1137   in which the block indices are in increasing order.  Symbolically,
1138   each keystream segment looks like
1139
1140      E(k, IV) || E(k, IV + 1 mod 2^128) || E(k, IV + 2 mod 2^128) ...
1141
1142   where the 128-bit integer value IV SHALL be defined by the SSRC, the
1143   SRTP packet index i, and the SRTP session salting key k_s, as below.
1144
1145      IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16)
1146
1147   Each of the three terms in the XOR-sum above is padded with as many
1148   leading zeros as needed to make the operation well-defined,
1149   considered as a 128-bit value.
1150
1151   The inclusion of the SSRC allows the use of the same key to protect
1152   distinct SRTP streams within the same RTP session, see the security
1153   caveats in Section 9.1.
1154
1155   In the case of SRTCP, the SSRC of the first header of the compound
1156   packet MUST be used, i SHALL be the 31-bit SRTCP index and k_e, k_s
1157   SHALL be replaced by the SRTCP encryption session key and salt.
1158
1159   Note that the initial value, IV, is fixed for each packet and is
1160   formed by "reserving" 16 zeros in the least significant bits for the
1161   purpose of the counter.  The number of blocks of keystream generated
1162   for any fixed value of IV MUST NOT exceed 2^16 to avoid keystream
1163   re-use, see below.  The AES has a block size of 128 bits, so 2^16
1164   output blocks are sufficient to generate the 2^23 bits of keystream
1165   needed to encrypt the largest possible RTP packet (except for IPv6
1166   "jumbograms" [RFC2675], which are not likely to be used for RTP-based
1167   multimedia traffic).  This restriction on the maximum bit-size of the
1168   packet that can be encrypted ensures the security of the encryption
1169   method by limiting the effectiveness of probabilistic attacks [BDJR].
1170
1171   For a particular Counter Mode key, each IV value used as an input
1172   MUST be distinct, in order to avoid the security exposure of a two-
1173   time pad situation (Section 9.1).  To satisfy this constraint, an
1174   implementation MUST ensure that the combination of the SRTP packet
1175
1176
1177
1178Baugher, et al.             Standards Track                    [Page 21]
1179
1180RFC 3711                          SRTP                        March 2004
1181
1182
1183   index of ROC || SEQ, and the SSRC used in the construction of the IV
1184   are distinct for any particular key.  The failure to ensure this
1185   uniqueness could be catastrophic for Secure RTP.  This is in contrast
1186   to the situation for RTP itself, which may be able to tolerate such
1187   failures.  It is RECOMMENDED that, if a dedicated security module is
1188   present, the RTP sequence numbers and SSRC either be generated or
1189   checked by that module (i.e., sequence-number and SSRC processing in
1190   an SRTP system needs to be protected as well as the key).
1191
11924.1.2.  AES in f8-mode
1193
1194   To encrypt UMTS (Universal Mobile Telecommunications System, as 3G
1195   networks) data, a solution (see [f8-a] [f8-b]) known as the f8-
1196   algorithm has been developed.  On a high level, the proposed scheme
1197   is a variant of Output Feedback Mode (OFB) [HAC], with a more
1198   elaborate initialization and feedback function.  As in normal OFB,
1199   the core consists of a block cipher.  We also define here the use of
1200   AES as a block cipher to be used in what we shall call "f8-mode of
1201   operation" RTP encryption.  The AES f8-mode SHALL use the same
1202   default sizes for session key and salt as AES counter mode.
1203
1204   Figure 4 shows the structure of block cipher, E, running in f8-mode.
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234Baugher, et al.             Standards Track                    [Page 22]
1235
1236RFC 3711                          SRTP                        March 2004
1237
1238
1239                    IV
1240                    |
1241                    v
1242                +------+
1243                |      |
1244           +--->|  E   |
1245           |    +------+
1246           |        |
1247     m -> (*)       +-----------+-------------+--  ...     ------+
1248           |    IV' |           |             |                  |
1249           |        |   j=1 -> (*)    j=2 -> (*)   ...  j=L-1 ->(*)
1250           |        |           |             |                  |
1251           |        |      +-> (*)       +-> (*)   ...      +-> (*)
1252           |        |      |    |        |    |             |    |
1253           |        v      |    v        |    v             |    v
1254           |    +------+   | +------+    | +------+         | +------+
1255    k_e ---+--->|  E   |   | |  E   |    | |  E   |         | |  E   |
1256                |      |   | |      |    | |      |         | |      |
1257                +------+   | +------+    | +------+         | +------+
1258                    |      |    |        |    |             |    |
1259                    +------+    +--------+    +--  ...  ----+    |
1260                    |           |             |                  |
1261                    v           v             v                  v
1262                   S(0)        S(1)          S(2)  . . .       S(L-1)
1263
1264   Figure 4.  f8-mode of operation (asterisk, (*), denotes bitwise XOR).
1265   The figure represents the KG in Figure 3, when AES-f8 is used.
1266
12674.1.2.1.  f8 Keystream Generation
1268
1269   The Initialization Vector (IV) SHALL be determined as described in
1270   Section 4.1.2.2 (and in Section 4.1.2.3 for SRTCP).
1271
1272   Let IV', S(j), and m denote n_b-bit blocks.  The keystream,
1273   S(0) ||... || S(L-1), for an N-bit message SHALL be defined by
1274   setting IV' = E(k_e XOR m, IV), and S(-1) = 00..0.  For
1275   j = 0,1,..,L-1 where L = N/n_b (rounded up to nearest integer if it
1276   is not already an integer) compute
1277
1278            S(j) = E(k_e, IV' XOR j XOR S(j-1))
1279
1280   Notice that the IV is not used directly.  Instead it is fed through E
1281   under another key to produce an internal, "masked" value (denoted
1282   IV') to prevent an attacker from gaining known input/output pairs.
1283
1284
1285
1286
1287
1288
1289
1290Baugher, et al.             Standards Track                    [Page 23]
1291
1292RFC 3711                          SRTP                        March 2004
1293
1294
1295   The role of the internal counter, j, is to prevent short keystream
1296   cycles.  The value of the key mask m SHALL be
1297
1298           m = k_s || 0x555..5,
1299
1300   i.e., the session salting key, appended by the binary pattern 0101..
1301   to fill out the entire desired key size, n_e.
1302
1303   The sender SHOULD NOT generate more than 2^32 blocks, which is
1304   sufficient to generate 2^39 bits of keystream.  Unlike counter mode,
1305   there is no absolute threshold above (below) which f8 is guaranteed
1306   to be insecure (secure).  The above bound has been chosen to limit,
1307   with sufficient security margin, the probability of degenerative
1308   behavior in the f8 keystream generation.
1309
13104.1.2.2.  f8 SRTP IV Formation
1311
1312   The purpose of the following IV formation is to provide a feature
1313   which we call implicit header authentication (IHA), see Section 9.5.
1314
1315   The SRTP IV for 128-bit block AES-f8 SHALL be formed in the following
1316   way:
1317
1318        IV = 0x00 || M || PT || SEQ || TS || SSRC || ROC
1319
1320   M, PT, SEQ, TS, SSRC SHALL be taken from the RTP header; ROC is from
1321   the cryptographic context.
1322
1323   The presence of the SSRC as part of the IV allows AES-f8 to be used
1324   when a master key is shared between multiple streams within the same
1325   RTP session, see Section 9.1.
1326
13274.1.2.3.  f8 SRTCP IV Formation
1328
1329   The SRTCP IV for 128-bit block AES-f8 SHALL be formed in the
1330   following way:
1331
1332   IV= 0..0 || E || SRTCP index || V || P || RC || PT || length || SSRC
1333
1334   where V, P, RC, PT, length, SSRC SHALL be taken from the first header
1335   in the RTCP compound packet.  E and SRTCP index are the 1-bit and
1336   31-bit fields added to the packet.
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346Baugher, et al.             Standards Track                    [Page 24]
1347
1348RFC 3711                          SRTP                        March 2004
1349
1350
13514.1.3.  NULL Cipher
1352
1353   The NULL cipher is used when no confidentiality for RTP/RTCP is
1354   requested.  The keystream can be thought of as "000..0", i.e., the
1355   encryption SHALL simply copy the plaintext input into the ciphertext
1356   output.
1357
13584.2.  Message Authentication and Integrity
1359
1360   Throughout this section, M will denote data to be integrity
1361   protected.  In the case of SRTP, M SHALL consist of the Authenticated
1362   Portion of the packet (as specified in Figure 1) concatenated with
1363   the ROC, M = Authenticated Portion || ROC; in the case of SRTCP, M
1364   SHALL consist of the Authenticated Portion (as specified in Figure 2)
1365   only.
1366
1367   Common parameters:
1368
1369   *  AUTH_ALG is the authentication algorithm
1370   *  k_a is the session message authentication key
1371   *  n_a is the bit-length of the authentication key
1372   *  n_tag is the bit-length of the output authentication tag
1373   *  SRTP_PREFIX_LENGTH is the octet length of the keystream prefix as
1374      defined above, a parameter of AUTH_ALG
1375
1376   The distinct session authentication keys for SRTP/SRTCP are by
1377   default derived as specified in Section 4.3.
1378
1379   The values of n_a, n_tag, and SRTP_PREFIX_LENGTH MUST be fixed for
1380   any particular fixed value of the key.
1381
1382   We describe the process of computing authentication tags as follows.
1383   The sender computes the tag of M and appends it to the packet.  The
1384   SRTP receiver verifies a message/authentication tag pair by computing
1385   a new authentication tag over M using the selected algorithm and key,
1386   and then compares it to the tag associated with the received message.
1387   If the two tags are equal, then the message/tag pair is valid;
1388   otherwise, it is invalid and the error audit message "AUTHENTICATION
1389   FAILURE" MUST be returned.
1390
13914.2.1.  HMAC-SHA1
1392
1393   The pre-defined authentication transform for SRTP is HMAC-SHA1
1394   [RFC2104].  With HMAC-SHA1, the SRTP_PREFIX_LENGTH (Figure 3) SHALL
1395   be 0.  For SRTP (respectively SRTCP), the HMAC SHALL be applied to
1396   the session authentication key and M as specified above, i.e.,
1397   HMAC(k_a, M).  The HMAC output SHALL then be truncated to the n_tag
1398   left-most bits.
1399
1400
1401
1402Baugher, et al.             Standards Track                    [Page 25]
1403
1404RFC 3711                          SRTP                        March 2004
1405
1406
14074.3.  Key Derivation
1408
14094.3.1.  Key Derivation Algorithm
1410
1411   Regardless of the encryption or message authentication transform that
1412   is employed (it may be an SRTP pre-defined transform or newly
1413   introduced according to Section 6), interoperable SRTP
1414   implementations MUST use the SRTP key derivation to generate session
1415   keys.  Once the key derivation rate is properly signaled at the start
1416   of the session, there is no need for extra communication between the
1417   parties that use SRTP key derivation.
1418
1419                         packet index ---+
1420                                         |
1421                                         v
1422               +-----------+ master  +--------+ session encr_key
1423               | ext       | key     |        |---------->
1424               | key mgmt  |-------->|  key   | session auth_key
1425               | (optional |         | deriv  |---------->
1426               | rekey)    |-------->|        | session salt_key
1427               |           | master  |        |---------->
1428               +-----------+ salt    +--------+
1429
1430   Figure 5: SRTP key derivation.
1431
1432   At least one initial key derivation SHALL be performed by SRTP, i.e.,
1433   the first key derivation is REQUIRED.  Further applications of the
1434   key derivation MAY be performed, according to the
1435   "key_derivation_rate" value in the cryptographic context.  The key
1436   derivation function SHALL initially be invoked before the first
1437   packet and then, when r > 0, a key derivation is performed whenever
1438   index mod r equals zero.  This can be thought of as "refreshing" the
1439   session keys.  The value of "key_derivation_rate" MUST be kept fixed
1440   for the lifetime of the associated master key.
1441
1442   Interoperable SRTP implementations MAY also derive session salting
1443   keys for encryption transforms, as is done in both of the pre-
1444   defined transforms.
1445
1446   Let m and n be positive integers.  A pseudo-random function family is
1447   a set of keyed functions {PRF_n(k,x)} such that for the (secret)
1448   random key k, given m-bit x, PRF_n(k,x) is an n-bit string,
1449   computationally indistinguishable from random n-bit strings, see
1450   [HAC].  For the purpose of key derivation in SRTP, a secure PRF with
1451   m = 128 (or more) MUST be used, and a default PRF transform is
1452   defined in Section 4.3.3.
1453
1454
1455
1456
1457
1458Baugher, et al.             Standards Track                    [Page 26]
1459
1460RFC 3711                          SRTP                        March 2004
1461
1462
1463   Let "a DIV t" denote integer division of a by t, rounded down, and
1464   with the convention that "a DIV 0 = 0" for all a.  We also make the
1465   convention of treating "a DIV t" as a bit string of the same length
1466   as a, and thus "a DIV t" will in general have leading zeros.
1467
1468   Key derivation SHALL be defined as follows in terms of <label>, an
1469   8-bit constant (see below), master_salt and key_derivation_rate, as
1470   determined in the cryptographic context, and index, the packet index
1471   (i.e., the 48-bit ROC || SEQ for SRTP):
1472
1473   *  Let r = index DIV key_derivation_rate (with DIV as defined above).
1474
1475   *  Let key_id = <label> || r.
1476
1477   *  Let x = key_id XOR master_salt, where key_id and master_salt are
1478      aligned so that their least significant bits agree (right-
1479      alignment).
1480
1481   <label> MUST be unique for each type of key to be derived.  We
1482   currently define <label> 0x00 to 0x05 (see below), and future
1483   extensions MAY specify new values in the range 0x06 to 0xff for other
1484   purposes.  The n-bit SRTP key (or salt) for this packet SHALL then be
1485   derived from the master key, k_master as follows:
1486
1487      PRF_n(k_master, x).
1488
1489   (The PRF may internally specify additional formatting and padding of
1490   x, see e.g., Section 4.3.3 for the default PRF.)
1491
1492   The session keys and salt SHALL now be derived using:
1493
1494   - k_e (SRTP encryption): <label> = 0x00, n = n_e.
1495
1496   - k_a (SRTP message authentication): <label> = 0x01, n = n_a.
1497
1498   - k_s (SRTP salting key): <label> = 0x02, n = n_s.
1499
1500   where n_e, n_s, and n_a are from the cryptographic context.
1501
1502   The master key and master salt MUST be random, but the master salt
1503   MAY be public.
1504
1505   Note that for a key_derivation_rate of 0, the application of the key
1506   derivation SHALL take place exactly once.
1507
1508   The definition of DIV above is purely for notational convenience.
1509   For a non-zero t among the set of allowed key derivation rates, "a
1510   DIV t" can be implemented as a right-shift by the base-2 logarithm of
1511
1512
1513
1514Baugher, et al.             Standards Track                    [Page 27]
1515
1516RFC 3711                          SRTP                        March 2004
1517
1518
1519   t.  The derivation operation is further facilitated if the rates are
1520   chosen to be powers of 256, but that granularity was considered too
1521   coarse to be a requirement of this specification.
1522
1523   The upper limit on the number of packets that can be secured using
1524   the same master key (see Section 9.2) is independent of the key
1525   derivation.
1526
15274.3.2.  SRTCP Key Derivation
1528
1529   SRTCP SHALL by default use the same master key (and master salt) as
1530   SRTP.  To do this securely, the following changes SHALL be done to
1531   the definitions in Section 4.3.1 when applying session key derivation
1532   for SRTCP.
1533
1534   Replace the SRTP index by the 32-bit quantity: 0 || SRTCP index
1535   (i.e., excluding the E-bit, replacing it with a fixed 0-bit), and use
1536   <label> = 0x03 for the SRTCP encryption key, <label> = 0x04 for the
1537   SRTCP authentication key, and, <label> = 0x05 for the SRTCP salting
1538   key.
1539
15404.3.3.  AES-CM PRF
1541
1542   The currently defined PRF, keyed by 128, 192, or 256 bit master key,
1543   has input block size m = 128 and can produce n-bit outputs for n up
1544   to 2^23.  PRF_n(k_master,x) SHALL be AES in Counter Mode as described
1545   in Section 4.1.1, applied to key k_master, and IV equal to (x*2^16),
1546   and with the output keystream truncated to the n first (left-most)
1547   bits.  (Requiring n/128, rounded up, applications of AES.)
1548
15495.  Default and mandatory-to-implement Transforms
1550
1551   The default transforms also are mandatory-to-implement transforms in
1552   SRTP.  Of course, "mandatory-to-implement" does not imply
1553   "mandatory-to-use".  Table 1 summarizes the pre-defined transforms.
1554   The default values below are valid for the pre-defined transforms.
1555
1556                         mandatory-to-impl.   optional     default
1557
1558   encryption            AES-CM, NULL         AES-f8       AES-CM
1559   message integrity     HMAC-SHA1              -          HMAC-SHA1
1560   key derivation (PRF)  AES-CM                 -          AES-CM
1561
1562   Table 1: Mandatory-to-implement, optional and default transforms in
1563   SRTP and SRTCP.
1564
1565
1566
1567
1568
1569
1570Baugher, et al.             Standards Track                    [Page 28]
1571
1572RFC 3711                          SRTP                        March 2004
1573
1574
15755.1.  Encryption: AES-CM and NULL
1576
1577   AES running in Segmented Integer Counter Mode, as defined in Section
1578   4.1.1, SHALL be the default encryption algorithm.  The default key
1579   lengths SHALL be 128-bit for the session encryption key (n_e).  The
1580   default session salt key-length (n_s) SHALL be 112 bits.
1581
1582   The NULL cipher SHALL also be mandatory-to-implement.
1583
15845.2.  Message Authentication/Integrity: HMAC-SHA1
1585
1586   HMAC-SHA1, as defined in Section 4.2.1, SHALL be the default message
1587   authentication code.  The default session authentication key-length
1588   (n_a) SHALL be 160 bits, the default authentication tag length
1589   (n_tag) SHALL be 80 bits, and the SRTP_PREFIX_LENGTH SHALL be zero
1590   for HMAC-SHA1.  In addition, for SRTCP, the pre-defined HMAC-SHA1
1591   MUST NOT be applied with a value of n_tag, nor n_a, that are smaller
1592   than these defaults.  For SRTP, smaller values are NOT RECOMMENDED,
1593   but MAY be used after careful consideration of the issues in Section
1594   7.5 and 9.5.
1595
15965.3.  Key Derivation: AES-CM PRF
1597
1598   The AES Counter Mode based key derivation and PRF defined in Sections
1599   4.3.1 to 4.3.3, using a 128-bit master key, SHALL be the default
1600   method for generating session keys.  The default master salt length
1601   SHALL be 112 bits and the default key-derivation rate SHALL be zero.
1602
16036.  Adding SRTP Transforms
1604
1605   Section 4 provides examples of the level of detail needed for
1606   defining transforms.  Whenever a new transform is to be added to
1607   SRTP, a companion standard track RFC MUST be written to exactly
1608   define how the new transform can be used with SRTP (and SRTCP).  Such
1609   a companion RFC SHOULD avoid overlap with the SRTP protocol document.
1610   Note however, that it MAY be necessary to extend the SRTP or SRTCP
1611   cryptographic context definition with new parameters (including fixed
1612   or default values), add steps to the packet processing, or even add
1613   fields to the SRTP/SRTCP packets.  The companion RFC SHALL explain
1614   any known issues regarding interactions between the transform and
1615   other aspects of SRTP.
1616
1617   Each new transform document SHOULD specify its key attributes, e.g.,
1618   size of keys (minimum, maximum, recommended), format of keys,
1619   recommended/required processing of input keying material,
1620   requirements/recommendations on key lifetime, re-keying and key
1621   derivation, whether sharing of keys between SRTP and SRTCP is allowed
1622   or not, etc.
1623
1624
1625
1626Baugher, et al.             Standards Track                    [Page 29]
1627
1628RFC 3711                          SRTP                        March 2004
1629
1630
1631   An added message integrity transform SHOULD define a minimum
1632   acceptable key/tag size for SRTCP, equivalent in strength to the
1633   minimum values as defined in Section 5.2.
1634
16357.  Rationale
1636
1637   This section explains the rationale behind several important features
1638   of SRTP.
1639
16407.1.  Key derivation
1641
1642   Key derivation reduces the burden on the key establishment.  As many
1643   as six different keys are needed per crypto context (SRTP and SRTCP
1644   encryption keys and salts, SRTP and SRTCP authentication keys), but
1645   these are derived from a single master key in a cryptographically
1646   secure way.  Thus, the key management protocol needs to exchange only
1647   one master key (plus master salt when required), and then SRTP itself
1648   derives all the necessary session keys (via the first, mandatory
1649   application of the key derivation function).
1650
1651   Multiple applications of the key derivation function are optional,
1652   but will give security benefits when enabled.  They prevent an
1653   attacker from obtaining large amounts of ciphertext produced by a
1654   single fixed session key.  If the attacker was able to collect a
1655   large amount of ciphertext for a certain session key, he might be
1656   helped in mounting certain attacks.
1657
1658   Multiple applications of the key derivation function provide
1659   backwards and forward security in the sense that a compromised
1660   session key does not compromise other session keys derived from the
1661   same master key.  This means that the attacker who is able to recover
1662   a certain session key, is anyway not able to have access to messages
1663   secured under previous and later session keys (derived from the same
1664   master key).  (Note that, of course, a leaked master key reveals all
1665   the session keys derived from it.)
1666
1667   Considerations arise with high-rate key refresh, especially in large
1668   multicast settings, see Section 11.
1669
16707.2.  Salting key
1671
1672   The master salt guarantees security against off-line key-collision
1673   attacks on the key derivation that might otherwise reduce the
1674   effective key size [MF00].
1675
1676
1677
1678
1679
1680
1681
1682Baugher, et al.             Standards Track                    [Page 30]
1683
1684RFC 3711                          SRTP                        March 2004
1685
1686
1687   The derived session salting key used in the encryption, has been
1688   introduced to protect against some attacks on additive stream
1689   ciphers, see Section 9.2.  The explicit inclusion method of the salt
1690   in the IV has been selected for ease of hardware implementation.
1691
16927.3.  Message Integrity from Universal Hashing
1693
1694   The particular definition of the keystream given in Section 4.1 (the
1695   keystream prefix) is to give provision for particular universal hash
1696   functions, suitable for message authentication in the Wegman-Carter
1697   paradigm [WC81].  Such functions are provably secure, simple, quick,
1698   and especially appropriate for Digital Signal Processors and other
1699   processors with a fast multiply operation.
1700
1701   No authentication transforms are currently provided in SRTP other
1702   than HMAC-SHA1.  Future transforms, like the above mentioned
1703   universal hash functions, MAY be added following the guidelines in
1704   Section 6.
1705
17067.4.  Data Origin Authentication Considerations
1707
1708   Note that in pair-wise communications, integrity and data origin
1709   authentication are provided together.  However, in group scenarios
1710   where the keys are shared between members, the MAC tag only proves
1711   that a member of the group sent the packet, but does not prevent
1712   against a member impersonating another.  Data origin authentication
1713   (DOA) for multicast and group RTP sessions is a hard problem that
1714   needs a solution; while some promising proposals are being
1715   investigated [PCST1] [PCST2], more work is needed to rigorously
1716   specify these technologies.  Thus SRTP data origin authentication in
1717   groups is for further study.
1718
1719   DOA can be done otherwise using signatures.  However, this has high
1720   impact in terms of bandwidth and processing time, therefore we do not
1721   offer this form of authentication in the pre-defined packet-integrity
1722   transform.
1723
1724   The presence of mixers and translators does not allow data origin
1725   authentication in case the RTP payload and/or the RTP header are
1726   manipulated.  Note that these types of middle entities also disrupt
1727   end-to-end confidentiality (as the IV formation depends e.g., on the
1728   RTP header preservation).  A certain trust model may choose to trust
1729   the mixers/translators to decrypt/re-encrypt the media (this would
1730   imply breaking the end-to-end security, with related security
1731   implications).
1732
1733
1734
1735
1736
1737
1738Baugher, et al.             Standards Track                    [Page 31]
1739
1740RFC 3711                          SRTP                        March 2004
1741
1742
17437.5.  Short and Zero-length Message Authentication
1744
1745   As shown in Figure 1, the authentication tag is RECOMMENDED in SRTP.
1746   A full 80-bit authentication-tag SHOULD be used, but a shorter tag or
1747   even a zero-length tag (i.e., no message authentication) MAY be used
1748   under certain conditions to support either of the following two
1749   application environments.
1750
1751      1. Strong authentication can be impractical in environments where
1752         bandwidth preservation is imperative.  An important special
1753         case is wireless communication systems, in which bandwidth is a
1754         scarce and expensive resource.  Studies have shown that for
1755         certain applications and link technologies, additional bytes
1756         may result in a significant decrease in spectrum efficiency
1757         [SWO].  Considerable effort has been made to design IP header
1758         compression techniques to improve spectrum efficiency
1759         [RFC3095].  A typical voice application produces 20 byte
1760         samples, and the RTP, UDP and IP headers need to be jointly
1761         compressed to one or two bytes on average in order to obtain
1762         acceptable wireless bandwidth economy [RFC3095].  In this case,
1763         strong authentication would impose nearly fifty percent
1764         overhead.
1765
1766      2. Authentication is impractical for applications that use data
1767         links with fixed-width fields that cannot accommodate the
1768         expansion due to the authentication tag.  This is the case for
1769         some important existing wireless channels.  For example, zero-
1770         byte header compression is used to adapt EVRC/SMV voice with
1771         the legacy IS-95 bearer channel in CDMA2000 VoIP services.  It
1772         was found that not a single additional octet could be added to
1773         the data, which motivated the creation of a zero-byte profile
1774         for ROHC [RFC3242].
1775
1776   A short tag is secure for a restricted set of applications.  Consider
1777   a voice telephony application, for example, such as a G.729 audio
1778   codec with a 20-millisecond packetization interval, protected by a
1779   32-bit message authentication tag.  The likelihood of any given
1780   packet being successfully forged is only one in 2^32.  Thus an
1781   adversary can control no more than 20 milliseconds of audio output
1782   during a 994-day period, on average.  In contrast, the effect of a
1783   single forged packet can be much larger if the application is
1784   stateful.  A codec that uses relative or predictive compression
1785   across packets will propagate the maliciously generated state,
1786   affecting a longer duration of output.
1787
1788
1789
1790
1791
1792
1793
1794Baugher, et al.             Standards Track                    [Page 32]
1795
1796RFC 3711                          SRTP                        March 2004
1797
1798
1799   Certainly not all SRTP or telephony applications meet the criteria
1800   for short or zero-length authentication tags.  Section 9.5.1
1801   discusses the risks of weak or no message authentication, and section
1802   9.5 describes the circumstances when it is acceptable and when it is
1803   unacceptable.
1804
18058.  Key Management Considerations
1806
1807   There are emerging key management standards [MIKEY] [KEYMGT] [SDMS]
1808   for establishing an SRTP cryptographic context (e.g., an SRTP master
1809   key).  Both proprietary and open-standard key management methods are
1810   likely to be used for telephony applications [MIKEY] [KINK] and
1811   multicast applications [GDOI].  This section provides guidance for
1812   key management systems that service SRTP session.
1813
1814   For initialization, an interoperable SRTP implementation SHOULD be
1815   given the SSRC and MAY be given the initial RTP sequence number for
1816   the RTP stream by key management (thus, key management has a
1817   dependency on RTP operational parameters).  Sending the RTP sequence
1818   number in the key management may be useful e.g., when the initial
1819   sequence number is close to wrapping (to avoid synchronization
1820   problems), and to communicate the current sequence number to a
1821   joining endpoint (to properly initialize its replay list).
1822
1823   If the pre-defined transforms are used, SRTP allows sharing of the
1824   same master key between SRTP/SRTCP streams belonging to the same RTP
1825   session.
1826
1827   First, sharing between SRTP streams belonging to the same RTP session
1828   is secure if the design of the synchronization mechanism, i.e., the
1829   IV, avoids keystream re-use (the two-time pad, Section 9.1).  This is
1830   taken care of by the fact that RTP provides for unique SSRCs for
1831   streams belonging to the same RTP session.  See Section 9.1 for
1832   further discussion.
1833
1834   Second, sharing between SRTP and the corresponding SRTCP is secure.
1835   The fact that an SRTP stream and its associated SRTCP stream both
1836   carry the same SSRC does not constitute a problem for the two-time
1837   pad due to the key derivation.  Thus, SRTP and SRTCP corresponding to
1838   one RTP session MAY share master keys (as they do by default).
1839
1840   Note that message authentication also has a dependency on SSRC
1841   uniqueness that is unrelated to the problem of keystream reuse: SRTP
1842   streams authenticated under the same key MUST have a distinct SSRC in
1843   order to identify the sender of the message.  This requirement is
1844   needed because the SSRC is the cryptographically authenticated field
1845
1846
1847
1848
1849
1850Baugher, et al.             Standards Track                    [Page 33]
1851
1852RFC 3711                          SRTP                        March 2004
1853
1854
1855   used to distinguish between different SRTP streams.  Were two streams
1856   to use identical SSRC values, then an adversary could substitute
1857   messages from one stream into the other without detection.
1858
1859   SRTP/SRTCP MUST NOT share master keys under any other circumstances
1860   than the ones given above, i.e., between SRTP and its corresponding
1861   SRTCP, and, between streams belonging to the same RTP session.
1862
18638.1.  Re-keying
1864
1865   The recommended way for a particular key management system to provide
1866   re-key within SRTP is by associating a master key in a crypto context
1867   with an MKI.
1868
1869   This provides for easy master key retrieval (see Scenarios in Section
1870   11), but has the disadvantage of adding extra bits to each packet.
1871   As noted in Section 7.5, some wireless links do not cater for added
1872   bits, therefore SRTP also defines a more economic way of triggering
1873   re-keying, via use of <From, To>, which works in some specific,
1874   simple scenarios (see Section 8.1.1).
1875
1876   SRTP senders SHALL count the amount of SRTP and SRTCP traffic being
1877   used for a master key and invoke key management to re-key if needed
1878   (Section 9.2).  These interactions are defined by the key management
1879   interface to SRTP and are not defined by this protocol specification.
1880
18818.1.1.  Use of the <From, To> for re-keying
1882
1883   In addition to the use of the MKI, SRTP defines another optional
1884   mechanism for master key retrieval, the <From, To>.  The <From, To>
1885   specifies the range of SRTP indices (a pair of sequence number and
1886   ROC) within which a certain master key is valid, and is (when used)
1887   part of the crypto context.  By looking at the 48-bit SRTP index of
1888   the current SRTP packet, the corresponding master key can be found by
1889   determining which From-To interval it belongs to.  For SRTCP, the
1890   most recently observed/used SRTP index (which can be obtained from
1891   the cryptographic context) is used for this purpose, even though
1892   SRTCP has its own (31-bit) index (see caveat below).
1893
1894   This method, compared to the MKI, has the advantage of identifying
1895   the master key and defining its lifetime without adding extra bits to
1896   each packet.  This could be useful, as already noted, for some
1897   wireless links that do not cater for added bits.  However, its use
1898   SHOULD be limited to specific, very simple scenarios.  We recommend
1899   to limit its use when the RTP session is a simple unidirectional or
1900   bi-directional stream.  This is because in case of multiple streams,
1901   it is difficult to trigger the re-key based on the <From, To> of a
1902   single RTP stream. For example, if several streams share a master
1903
1904
1905
1906Baugher, et al.             Standards Track                    [Page 34]
1907
1908RFC 3711                          SRTP                        March 2004
1909
1910
1911   key, there is no simple one-to-one correspondence between the index
1912   sequence space of a certain stream, and the index sequence space on
1913   which the <From, To> values are based.  Consequently, when a master
1914   key is shared between streams, one of these streams MUST be
1915   designated by key management as the one whose index space defines the
1916   re-keying points.  Also, the re-key triggering on SRTCP is based on
1917   the correspondent SRTP stream, i.e., when the SRTP stream changes the
1918   master key, so does the correspondent SRTCP.  This becomes obviously
1919   more and more complex with multiple streams.
1920
1921   The default values for the <From, To> are "from the first observed
1922   packet" and "until further notice".  However, the maximum limit of
1923   SRTP/SRTCP packets that are sent under each given master/session key
1924   (Section 9.2) MUST NOT be exceeded.
1925
1926   In case the <From, To> is used as key retrieval, then the MKI is not
1927   inserted in the packet (and its indicator in the crypto context is
1928   zero).  However, using the MKI does not exclude using <From, To> key
1929   lifetime simultaneously.  This can for instance be useful to signal
1930   at the sender side at which point in time an MKI is to be made
1931   active.
1932
19338.2.  Key Management parameters
1934
1935   The table below lists all SRTP parameters that key management can
1936   supply.  For reference, it also provides a summary of the default and
1937   mandatory-to-support values for an SRTP implementation as described
1938   in Section 5.
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962Baugher, et al.             Standards Track                    [Page 35]
1963
1964RFC 3711                          SRTP                        March 2004
1965
1966
1967   Parameter                     Mandatory-to-support    Default
1968   ---------                     --------------------    -------
1969
1970   SRTP and SRTCP encr transf.       AES_CM, NULL         AES_CM
1971   (Other possible values: AES_f8)
1972
1973   SRTP and SRTCP auth transf.       HMAC-SHA1           HMAC-SHA1
1974
1975   SRTP and SRTCP auth params:
1976     n_tag (tag length)                 80                 80
1977     SRTP prefix_length                  0                  0
1978
1979   Key derivation PRF                 AES_CM              AES_CM
1980
1981   Key material params
1982   (for each master key):
1983     master key length                 128                128
1984     n_e (encr session key length)     128                128
1985     n_a (auth session key length)     160                160
1986     master salt key
1987     length of the master salt         112                112
1988     n_s (session salt key length)     112                112
1989     key derivation rate                 0                  0
1990
1991     key lifetime
1992        SRTP-packets-max-lifetime      2^48               2^48
1993        SRTCP-packets-max-lifetime     2^31               2^31
1994        from-to-lifetime <From, To>
1995     MKI indicator                       0                 0
1996     length of the MKI                   0                 0
1997     value of the MKI
1998
1999   Crypto context index params:
2000     SSRC value
2001     ROC
2002     SEQ
2003     SRTCP Index
2004     Transport address
2005     Port number
2006
2007   Relation to other RTP profiles:
2008     sender's order between FEC and SRTP FEC-SRTP      FEC-SRTP
2009     (see Section 10)
2010
2011
2012
2013
2014
2015
2016
2017
2018Baugher, et al.             Standards Track                    [Page 36]
2019
2020RFC 3711                          SRTP                        March 2004
2021
2022
20239. Security Considerations
2024
20259.1.  SSRC collision and two-time pad
2026
2027   Any fixed keystream output, generated from the same key and index
2028   MUST only be used to encrypt once.  Re-using such keystream (jokingly
2029   called a "two-time pad" system by cryptographers), can seriously
2030   compromise security.  The NSA's VENONA project [C99] provides a
2031   historical example of such a compromise.  It is REQUIRED that
2032   automatic key management be used for establishing and maintaining
2033   SRTP and SRTCP keying material; this requirement is to avoid
2034   keystream reuse, which is more likely to occur with manual key
2035   management.  Furthermore, in SRTP, a "two-time pad" is avoided by
2036   requiring the key, or some other parameter of cryptographic
2037   significance, to be unique per RTP/RTCP stream and packet.  The pre-
2038   defined SRTP transforms accomplish packet-uniqueness by including the
2039   packet index and stream-uniqueness by inclusion of the SSRC.
2040
2041   The pre-defined transforms (AES-CM and AES-f8) allow master keys to
2042   be shared across streams belonging to the same RTP session by the
2043   inclusion of the SSRC in the IV.  A master key MUST NOT be shared
2044   among different RTP sessions.
2045
2046   Thus, the SSRC MUST be unique between all the RTP streams within the
2047   same RTP session that share the same master key.  RTP itself provides
2048   an algorithm for detecting SSRC collisions within the same RTP
2049   session.  Thus, temporary collisions could lead to temporary two-time
2050   pad, in the unfortunate event that SSRCs collide at a point in time
2051   when the streams also have identical sequence numbers (occurring with
2052   probability roughly 2^(-48)).  Therefore, the key management SHOULD
2053   take care of avoiding such SSRC collisions by including the SSRCs to
2054   be used in the session as negotiation parameters, proactively
2055   assuring their uniqueness.  This is a strong requirements in
2056   scenarios where for example, there are multiple senders that can
2057   start to transmit simultaneously, before SSRC collision are detected
2058   at the RTP level.
2059
2060   Note also that even with distinct SSRCs, extensive use of the same
2061   key might improve chances of probabilistic collision and time-
2062   memory-tradeoff attacks succeeding.
2063
2064   As described, master keys MAY be shared between streams belonging to
2065   the same RTP session, but it is RECOMMENDED that each SSRC have its
2066   own master key.  When master keys are shared among SSRC participants
2067   and SSRCs are managed by a key management module as recommended
2068   above, the RECOMMENDED policy for an SSRC collision error is for the
2069   participant to leave the SRTP session as it is a sign of malfunction.
2070
2071
2072
2073
2074Baugher, et al.             Standards Track                    [Page 37]
2075
2076RFC 3711                          SRTP                        March 2004
2077
2078
20799.2.  Key Usage
2080
2081   The effective key size is determined (upper bounded) by the size of
2082   the master key and, for encryption, the size of the salting key.  Any
2083   additive stream cipher is vulnerable to attacks that use statistical
2084   knowledge about the plaintext source to enable key collision and
2085   time-memory tradeoff attacks [MF00] [H80] [BS00].  These attacks take
2086   advantage of commonalities among plaintexts, and provide a way for a
2087   cryptanalyst to amortize the computational effort of decryption over
2088   many keys, or over many bytes of output, thus reducing the effective
2089   key size of the cipher.  A detailed analysis of these attacks and
2090   their applicability to the encryption of Internet traffic is provided
2091   in [MF00].  In summary, the effective key size of SRTP when used in a
2092   security system in which m distinct keys are used, is equal to the
2093   key size of the cipher less the logarithm (base two) of m.
2094   Protection against such attacks can be provided simply by increasing
2095   the size of the keys used, which here can be accomplished by the use
2096   of the salting key.  Note that the salting key MUST be random but MAY
2097   be public.  A salt size of (the suggested) size 112 bits protects
2098   against attacks in scenarios where at most 2^112 keys are in use.
2099   This is sufficient for all practical purposes.
2100
2101   Implementations SHOULD use keys that are as large as possible.
2102   Please note that in many cases increasing the key size of a cipher
2103   does not affect the throughput of that cipher.
2104
2105   The use of the SRTP and SRTCP indices in the pre-defined transforms
2106   fixes the maximum number of packets that can be secured with the same
2107   key.  This limit is fixed to 2^48 SRTP packets for an SRTP stream,
2108   and 2^31 SRTCP packets, when SRTP and SRTCP are considered
2109   independently.  Due to for example re-keying, reaching this limit may
2110   or may not coincide with wrapping of the indices, and thus the sender
2111   MUST keep packet counts.  However, when the session keys for related
2112   SRTP and SRTCP streams are derived from the same master key (the
2113   default behavior, Section 4.3), the upper bound that has to be
2114   considered is in practice the minimum of the two quantities.  That
2115   is, when 2^48 SRTP packets or 2^31 SRTCP packets have been secured
2116   with the same key (whichever occurs before), the key management MUST
2117   be called to provide new master key(s) (previously stored and used
2118   keys MUST NOT be used again), or the session MUST be terminated.  If
2119   a sender of RTCP discovers that the sender of SRTP (or SRTCP) has not
2120   updated the master or session key prior to sending 2^48 SRTP (or 2^31
2121   SRTCP) packets belonging to the same SRTP (SRTCP) stream, it is up to
2122   the security policy of the RTCP sender how to behave, e.g., whether
2123   an RTCP BYE-packet should be sent and/or if the event should be
2124   logged.
2125
2126
2127
2128
2129
2130Baugher, et al.             Standards Track                    [Page 38]
2131
2132RFC 3711                          SRTP                        March 2004
2133
2134
2135   Note: in most typical applications (assuming at least one RTCP packet
2136   for every 128,000 RTP packets), it will be the SRTCP index that first
2137   reaches the upper limit, although the time until this occurs is very
2138   long: even at 200 SRTCP packets/sec, the 2^31 index space of SRTCP is
2139   enough to secure approximately 4 months of communication.
2140
2141   Note that if the master key is to be shared between SRTP streams
2142   within the same RTP session (Section 9.1), although the above bounds
2143   are on a per stream (i.e., per SSRC) basis, the sender MUST base re-
2144   key decision on the stream whose sequence number space is the first
2145   to be exhausted.
2146
2147   Key derivation limits the amount of plaintext that is encrypted with
2148   a fixed session key, and made available to an attacker for analysis,
2149   but key derivation does not extend the master key's lifetime.  To see
2150   this, simply consider our requirements to avoid two-time pad:  two
2151   distinct packets MUST either be processed with distinct IVs, or with
2152   distinct session keys, and both the distinctness of IV and of the
2153   session keys are (for the pre-defined transforms) dependent on the
2154   distinctness of the packet indices.
2155
2156   Note that with the key derivation, the effective key size is at most
2157   that of the master key, even if the derived session key is
2158   considerably longer.  With the pre-defined authentication transform,
2159   the session authentication key is 160 bits, but the master key by
2160   default is only 128 bits.  This design choice was made to comply with
2161   certain recommendations in [RFC2104] so that an existing HMAC
2162   implementation can be plugged into SRTP without problems.  Since the
2163   default tag size is 80 bits, it is, for the applications in mind,
2164   also considered acceptable from security point of view.  Users having
2165   concerns about this are RECOMMENDED to instead use a 192 bit master
2166   key in the key derivation.  It was, however, chosen not to mandate
2167   192-bit keys since existing AES implementations to be used in the
2168   key-derivation may not always support key-lengths other than 128
2169   bits.  Since AES is not defined (or properly analyzed) for use with
2170   160 bit keys it is NOT RECOMMENDED that ad-hoc key-padding schemes
2171   are used to pad shorter keys to 192 or 256 bits.
2172
21739.3.  Confidentiality of the RTP Payload
2174
2175   SRTP's pre-defined ciphers are "seekable" stream ciphers, i.e.,
2176   ciphers able to efficiently seek to arbitrary locations in their
2177   keystream (so that the encryption or decryption of one packet does
2178   not depend on preceding packets).  By using seekable stream ciphers,
2179   SRTP avoids the denial of service attacks that are possible on stream
2180   ciphers that lack this property.  It is important to be aware that,
2181   as with any stream cipher, the exact length of the payload is
2182   revealed by the encryption.  This means that it may be possible to
2183
2184
2185
2186Baugher, et al.             Standards Track                    [Page 39]
2187
2188RFC 3711                          SRTP                        March 2004
2189
2190
2191   deduce certain "formatting bits" of the payload, as the length of the
2192   codec output might vary due to certain parameter settings etc.  This,
2193   in turn, implies that the corresponding bit of the keystream can be
2194   deduced.  However, if the stream cipher is secure (counter mode and
2195   f8 are provably secure under certain assumptions [BDJR] [KSYH] [IK]),
2196   knowledge of a few bits of the keystream will not aid an attacker in
2197   predicting subsequent keystream bits.  Thus, the payload length (and
2198   information deducible from this) will leak, but nothing else.
2199
2200   As some RTP packet could contain highly predictable data, e.g., SID,
2201   it is important to use a cipher designed to resist known plaintext
2202   attacks (which is the current practice).
2203
22049.4.  Confidentiality of the RTP Header
2205
2206   In SRTP, RTP headers are sent in the clear to allow for header
2207   compression.  This means that data such as payload type,
2208   synchronization source identifier, and timestamp are available to an
2209   eavesdropper.  Moreover, since RTP allows for future extensions of
2210   headers, we cannot foresee what kind of possibly sensitive
2211   information might also be "leaked".
2212
2213   SRTP is a low-cost method, which allows header compression to reduce
2214   bandwidth.  It is up to the endpoints' policies to decide about the
2215   security protocol to employ.  If one really needs to protect headers,
2216   and is allowed to do so by the surrounding environment, then one
2217   should also look at alternatives, e.g., IPsec [RFC2401].
2218
22199.5.  Integrity of the RTP payload and header
2220
2221   SRTP messages are subject to attacks on their integrity and source
2222   identification, and these risks are discussed in Section 9.5.1.  To
2223   protect against these attacks, each SRTP stream SHOULD be protected
2224   by HMAC-SHA1 [RFC2104] with an 80-bit output tag and a 160-bit key,
2225   or a message authentication code with equivalent strength.  Secure
2226   RTP SHOULD NOT be used without message authentication, except under
2227   the circumstances described in this section.  It is important to note
2228   that encryption algorithms, including AES Counter Mode and f8, do not
2229   provide message authentication.  SRTCP MUST NOT be used with weak (or
2230   NULL) authentication.
2231
2232   SRTP MAY be used with weak authentication (e.g., a 32-bit
2233   authentication tag), or with no authentication (the NULL
2234   authentication algorithm).  These options allow SRTP to be used to
2235   provide confidentiality in situations where
2236
2237    * weak or null authentication is an acceptable security risk, and
2238    * it is impractical to provide strong message authentication.
2239
2240
2241
2242Baugher, et al.             Standards Track                    [Page 40]
2243
2244RFC 3711                          SRTP                        March 2004
2245
2246
2247   These conditions are described below and in Section 7.5.  Note that
2248   both conditions MUST hold in order for weak or null authentication to
2249   be used.  The risks associated with exercising the weak or null
2250   authentication options need to be considered by a security audit
2251   prior to their use for a particular application or environment given
2252   the risks, which are discussed in Section 9.5.1.
2253
2254   Weak authentication is acceptable when the RTP application is such
2255   that the effect of a small fraction of successful forgeries is
2256   negligible.  If the application is stateless, then the effect of a
2257   single forged RTP packet is limited to the decoding of that
2258   particular packet.  Under this condition, the size of the
2259   authentication tag MUST ensure that only a negligible fraction of the
2260   packets passed to the RTP application by the SRTP receiver can be
2261   forgeries.  This fraction is negligible when an adversary, if given
2262   control of the forged packets, is not able to make a significant
2263   impact on the output of the RTP application (see the example of
2264   Section 7.5).
2265
2266   Weak or null authentication MAY be acceptable when it is unlikely
2267   that an adversary can modify ciphertext so that it decrypts to an
2268   intelligible value.  One important case is when it is difficult for
2269   an adversary to acquire the RTP plaintext data, since for many
2270   codecs, an adversary that does not know the input signal cannot
2271   manipulate the output signal in a controlled way.  In many cases it
2272   may be difficult for the adversary to determine the actual value of
2273   the plaintext.  For example, a hidden snooping device might be
2274   required in order to know a live audio or video signal.  The
2275   adversary's signal must have a quality equivalent to or greater than
2276   that of the signal under attack, since otherwise the adversary would
2277   not have enough information to encode that signal with the codec used
2278   by the victim.  Plaintext prediction may also be especially difficult
2279   for an interactive application such as a telephone call.
2280
2281   Weak or null authentication MUST NOT be used when the RTP application
2282   makes data forwarding or access control decisions based on the RTP
2283   data.  In such a case, an attacker may be able to subvert
2284   confidentiality by causing the receiver to forward data to an
2285   attacker.  See Section 3 of [B96] for a real-life example of such
2286   attacks.
2287
2288   Null authentication MUST NOT be used when a replay attack, in which
2289   an adversary stores packets then replays them later in the session,
2290   could have a non-negligible impact on the receiver.  An example of a
2291   successful replay attack is the storing of the output of a
2292   surveillance camera for a period of time, later followed by the
2293
2294
2295
2296
2297
2298Baugher, et al.             Standards Track                    [Page 41]
2299
2300RFC 3711                          SRTP                        March 2004
2301
2302
2303   injection of that output to the monitoring station to avoid
2304   surveillance.  Encryption does not protect against this attack, and
2305   non-null authentication is REQUIRED in order to defeat it.
2306
2307   If existential message forgery is an issue, i.e., when the accuracy
2308   of the received data is of non-negligible importance, null
2309   authentication MUST NOT be used.
2310
23119.5.1.  Risks of Weak or Null Message Authentication
2312
2313   During a security audit considering the use of weak or null
2314   authentication, it is important to keep in mind the following attacks
2315   which are possible when no message authentication algorithm is used.
2316
2317   An attacker who cannot predict the plaintext is still always able to
2318   modify the message sent between the sender and the receiver so that
2319   it decrypts to a random plaintext value, or to send a stream of bogus
2320   packets to the receiver that will decrypt to random plaintext values.
2321   This attack is essentially a denial of service attack, though in the
2322   absence of message authentication, the RTP application will have
2323   inputs that are bit-wise correlated with the true value.  Some
2324   multimedia codecs and common operating systems will crash when such
2325   data are accepted as valid video data.  This denial of service attack
2326   may be a much larger threat than that due to an attacker dropping,
2327   delaying, or re-ordering packets.
2328
2329   An attacker who cannot predict the plaintext can still replay a
2330   previous message with certainty that the receiver will accept it.
2331   Applications with stateless codecs might be robust against this type
2332   of attack, but for other, more complex applications these attacks may
2333   be far more grave.
2334
2335   An attacker who can predict the plaintext can modify the ciphertext
2336   so that it will decrypt to any value of her choosing.  With an
2337   additive stream cipher, an attacker will always be able to change
2338   individual bits.
2339
2340   An attacker may be able to subvert confidentiality due to the lack of
2341   authentication when a data forwarding or access control decision is
2342   made on decrypted but unauthenticated plaintext.  This is because the
2343   receiver may be fooled into forwarding data to an attacker, leading
2344   to an indirect breach of confidentiality (see Section 3 of [B96]).
2345   This is because data-forwarding decisions are made on the decrypted
2346   plaintext; information in the plaintext will determine to what subnet
2347   (or process) the plaintext is forwarded in ESP [RFC2401] tunnel mode
2348   (respectively, transport mode).  When Secure RTP is used without
2349
2350
2351
2352
2353
2354Baugher, et al.             Standards Track                    [Page 42]
2355
2356RFC 3711                          SRTP                        March 2004
2357
2358
2359   message authentication, it should be verified that the application
2360   does not make data forwarding or access control decisions based on
2361   the decrypted plaintext.
2362
2363   Some cipher modes of operation that require padding, e.g., standard
2364   cipher block chaining (CBC) are very sensitive to attacks on
2365   confidentiality if certain padding types are used in the absence of
2366   integrity.  The attack [V02] shows that this is indeed the case for
2367   the standard RTP padding as discussed in reference to Figure 1, when
2368   used together with CBC mode.  Later transform additions to SRTP MUST
2369   therefore carefully consider the risk of using this padding without
2370   proper integrity protection.
2371
23729.5.2.  Implicit Header Authentication
2373
2374   The IV formation of the f8-mode gives implicit authentication (IHA)
2375   of the RTP header, even when message authentication is not used.
2376   When IHA is used, an attacker that modifies the value of the RTP
2377   header will cause the decryption process at the receiver to produce
2378   random plaintext values.  While this protection is not equivalent to
2379   message authentication, it may be useful for some applications.
2380
238110.  Interaction with Forward Error Correction mechanisms
2382
2383   The default processing when using Forward Error Correction (e.g., RFC
2384   2733) processing with SRTP SHALL be to perform FEC processing prior
2385   to SRTP processing on the sender side and to perform SRTP processing
2386   prior to FEC processing on the receiver side.  Any change to this
2387   ordering (reversing it, or, placing FEC between SRTP encryption and
2388   SRTP authentication) SHALL be signaled out of band.
2389
239011.  Scenarios
2391
2392   SRTP can be used as security protocol for the RTP/RTCP traffic in
2393   many different scenarios.  SRTP has a number of configuration
2394   options, in particular regarding key usage, and can have impact on
2395   the total performance of the application according to the way it is
2396   used.  Hence, the use of SRTP is dependent on the kind of scenario
2397   and application it is used with.  In the following, we briefly
2398   illustrate some use cases for SRTP, and give some guidelines for
2399   recommended setting of its options.
2400
240111.1.  Unicast
2402
2403   A typical example would be a voice call or video-on-demand
2404   application.
2405
2406
2407
2408
2409
2410Baugher, et al.             Standards Track                    [Page 43]
2411
2412RFC 3711                          SRTP                        March 2004
2413
2414
2415   Consider one bi-directional RTP stream, as one RTP session.  It is
2416   possible for the two parties to share the same master key in the two
2417   directions according to the principles of Section 9.1.  The first
2418   round of the key derivation splits the master key into any or all of
2419   the following session keys (according to the provided security
2420   functions):
2421
2422   SRTP_encr_key, SRTP_auth_key, SRTCP_encr_key, and SRTCP_auth key.
2423
2424   (For simplicity, we omit discussion of the salts, which are also
2425   derived.)  In this scenario, it will in most cases suffice to have a
2426   single master key with the default lifetime.  This guarantees
2427   sufficiently long lifetime of the keys and a minimum set of keys in
2428   place for most practical purposes.  Also, in this case RTCP
2429   protection can be applied smoothly.  Under these assumptions, use of
2430   the MKI can be omitted.  As the key-derivation in combination with
2431   large difference in the packet rate in the respective directions may
2432   require simultaneous storage of several session keys, if storage is
2433   an issue, we recommended to use low-rate key derivation.
2434
2435   The same considerations can be extended to the unicast scenario with
2436   multiple RTP sessions, where each session would have a distinct
2437   master key.
2438
243911.2.  Multicast (one sender)
2440
2441   Just as with (unprotected) RTP, a scalability issue arises in big
2442   groups due to the possibly very large amount of SRTCP Receiver
2443   Reports that the sender might need to process.  In SRTP, the sender
2444   may have to keep state (the cryptographic context) for each receiver,
2445   or more precisely, for the SRTCP used to protect Receiver Reports.
2446   The overhead increases proportionally to the size of the group.  In
2447   particular, re-keying requires special concern, see below.
2448
2449   Consider first a small group of receivers.  There are a few possible
2450   setups with the distribution of master keys among the receivers.
2451   Given a single RTP session, one possibility is that the receivers
2452   share the same master key as per Section 9.1 to secure all their
2453   respective RTCP traffic.  This shared master key could then be the
2454   same one used by the sender to protect its outbound SRTP traffic.
2455   Alternatively, it could be a master key shared only among the
2456   receivers and used solely for their SRTCP traffic.  Both alternatives
2457   require the receivers to trust each other.
2458
2459   Considering SRTCP and key storage, it is recommended to use low-rate
2460   (or zero) key_derivation (except the mandatory initial one), so that
2461   the sender does not need to store too many session keys (each SRTCP
2462   stream might otherwise have a different session key at a given point
2463
2464
2465
2466Baugher, et al.             Standards Track                    [Page 44]
2467
2468RFC 3711                          SRTP                        March 2004
2469
2470
2471   in time, as the SRTCP sources send at different times).  Thus, in
2472   case key derivation is wanted for SRTP, the cryptographic context for
2473   SRTP can be kept separate from the SRTCP crypto context, so that it
2474   is possible to have a key_derivation_rate of 0 for SRTCP and a non-
2475   zero value for SRTP.
2476
2477   Use of the MKI for re-keying is RECOMMENDED for most applications
2478   (see Section 8.1).
2479
2480   If there are more than one SRTP/SRTCP stream (within the same RTP
2481   session) that share the master key, the upper limit of 2^48 SRTP
2482   packets / 2^31 SRTCP packets means that, before one of the streams
2483   reaches its maximum number of packets, re-keying MUST be triggered on
2484   ALL streams sharing the master key.  (From strict security point of
2485   view, only the stream reaching the maximum would need to be re-keyed,
2486   but then the streams would no longer be sharing master key, which is
2487   the intention.)  A local policy at the sender side should force
2488   rekeying in a way that the maximum packet limit is not reached on any
2489   of the streams.  Use of the MKI for re-keying is RECOMMENDED.
2490
2491   In large multicast with one sender, the same considerations as for
2492   the small group multicast hold.  The biggest issue in this scenario
2493   is the additional load placed at the sender side, due to the state
2494   (cryptographic contexts) that has to be maintained for each receiver,
2495   sending back RTCP Receiver Reports.  At minimum, a replay window
2496   might need to be maintained for each RTCP source.
2497
249811.3.  Re-keying and access control
2499
2500   Re-keying may occur due to access control (e.g., when a member is
2501   removed during a multicast RTP session), or for pure cryptographic
2502   reasons (e.g., the key is at the end of its lifetime).  When using
2503   SRTP default transforms, the master key MUST be replaced before any
2504   of the index spaces are exhausted for any of the streams protected by
2505   one and the same master key.
2506
2507   How key management re-keys SRTP implementations is out of scope, but
2508   it is clear that there are straightforward ways to manage keys for a
2509   multicast group.  In one-sender multicast, for example, it is
2510   typically the responsibility of the sender to determine when a new
2511   key is needed.  The sender is the one entity that can keep track of
2512   when the maximum number of packets has been sent, as receivers may
2513   join and leave the session at any time, there may be packet loss and
2514   delay etc.  In scenarios other than one-sender multicast, other
2515   methods can be used.  Here, one must take into consideration that key
2516   exchange can be a costly operation, taking several seconds for a
2517   single exchange.  Hence, some time before the master key is
2518   exhausted/expires, out-of-band key management is initiated, resulting
2519
2520
2521
2522Baugher, et al.             Standards Track                    [Page 45]
2523
2524RFC 3711                          SRTP                        March 2004
2525
2526
2527   in a new master key that is shared with the receiver(s).  In any
2528   event, to maintain synchronization when switching to the new key,
2529   group policy might choose between using the MKI and the <From, To>,
2530   as described in Section 8.1.
2531
2532   For access control purposes, the <From, To> periods are set at the
2533   desired granularity, dependent on the packet rate.  High rate re-
2534   keying can be problematic for SRTCP in some large-group scenarios.
2535   As mentioned, there are potential problems in using the SRTP index,
2536   rather than the SRTCP index, for determining the master key.  In
2537   particular, for short periods during switching of master keys, it may
2538   be the case that SRTCP packets are not under the current master key
2539   of the correspondent SRTP.  Therefore, using the MKI for re-keying in
2540   such scenarios will produce better results.
2541
254211.4.  Summary of basic scenarios
2543
2544   The description of these scenarios highlights some recommendations on
2545   the use of SRTP, mainly related to re-keying and large scale
2546   multicast:
2547
2548   - Do not use fast re-keying with the <From, To> feature.  It may, in
2549     particular, give problems in retrieving the correct SRTCP key, if
2550     an SRTCP packet arrives close to the re-keying time.  The MKI
2551     SHOULD be used in this case.
2552
2553   - If multiple SRTP streams in the same RTP session share the same
2554     master key, also moderate rate re-keying MAY have the same
2555     problems, and the MKI SHOULD be used.
2556
2557   - Though offering increased security, a non-zero key_derivation_rate
2558     is NOT RECOMMENDED when trying to minimize the number of keys in
2559     use with multiple streams.
2560
256112.  IANA Considerations
2562
2563   The RTP specification establishes a registry of profile names for use
2564   by higher-level control protocols, such as the Session Description
2565   Protocol (SDP), to refer to transport methods.  This profile
2566   registers the name "RTP/SAVP".
2567
2568   SRTP uses cryptographic transforms which a key management protocol
2569   signals.  It is the task of each particular key management protocol
2570   to register the cryptographic transforms or suites of transforms with
2571   IANA.  The key management protocol conveys these protocol numbers,
2572   not SRTP, and each key management protocol chooses the numbering
2573   scheme and syntax that it requires.
2574
2575
2576
2577
2578Baugher, et al.             Standards Track                    [Page 46]
2579
2580RFC 3711                          SRTP                        March 2004
2581
2582
2583   Specification of a key management protocol for SRTP is out of scope
2584   here.  Section 8.2, however, provides guidance on the parameters that
2585   need to be defined for the default and mandatory transforms.
2586
258713.  Acknowledgements
2588
2589   David Oran (Cisco) and Rolf Blom (Ericsson) are co-authors of this
2590   document but their valuable contributions are acknowledged here to
2591   keep the length of the author list down.
2592
2593   The authors would in addition like to thank Magnus Westerlund, Brian
2594   Weis, Ghyslain Pelletier, Morgan Lindqvist, Robert Fairlie-
2595   Cuninghame, Adrian Perrig, the AVT WG and in particular the chairmen
2596   Colin Perkins and Stephen Casner, the Transport and Security Area
2597   Directors, and Eric Rescorla for their reviews and support.
2598
259914.  References
2600
260114.1.  Normative References
2602
2603   [AES]     NIST, "Advanced Encryption Standard (AES)", FIPS PUB 197,
2604             http://www.nist.gov/aes/
2605
2606   [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
2607             Hashing for Message Authentication", RFC 2104, February
2608             1997.
2609
2610   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2611             Requirement Levels", BCP 14, RFC 2119, March 1997.
2612
2613   [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
2614             Internet Protocol", RFC 2401, November 1998.
2615
2616   [RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828,
2617             May 2000.
2618
2619   [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
2620             "RTP: A Transport Protocol for Real-time Applications", RFC
2621             3550, July 2003.
2622
2623   [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
2624             Video Conferences with Minimal Control",  RFC 3551, July
2625             2003.
2626
2627
2628
2629
2630
2631
2632
2633
2634Baugher, et al.             Standards Track                    [Page 47]
2635
2636RFC 3711                          SRTP                        March 2004
2637
2638
263914.2.  Informative References
2640
2641   [AES-CTR] Lipmaa, H., Rogaway, P. and D. Wagner, "CTR-Mode
2642             Encryption", NIST, http://csrc.nist.gov/encryption/modes/
2643             workshop1/papers/lipmaa-ctr.pdf
2644
2645   [B96]     Bellovin, S., "Problem Areas for the IP Security
2646             Protocols," in Proceedings of the Sixth Usenix Unix
2647             Security Symposium, pp. 1-16, San Jose, CA, July 1996
2648             (http://www.research.att.com/~smb/papers/index.html).
2649
2650   [BDJR]    Bellare, M., Desai, A., Jokipii, E. and P. Rogaway, "A
2651             Concrete Treatment of Symmetric Encryption: Analysis of DES
2652             Modes of Operation", Proceedings 38th IEEE FOCS, pp. 394-
2653             403, 1997.
2654
2655   [BS00]    Biryukov, A. and A. Shamir, "Cryptanalytic Time/Memory/Data
2656             Tradeoffs for Stream Ciphers", Proceedings, ASIACRYPT 2000,
2657             LNCS 1976, pp. 1-13, Springer Verlag.
2658
2659   [C99]     Crowell, W. P., "Introduction to the VENONA Project",
2660             http://www.nsa.gov:8080/docs/venona/index.html.
2661
2662   [CTR]     Dworkin, M., NIST Special Publication 800-38A,
2663             "Recommendation for Block Cipher Modes of Operation:
2664             Methods and Techniques", 2001.
2665             http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-
2666             38a.pdf.
2667
2668   [f8-a]    3GPP TS 35.201 V4.1.0 (2001-12) Technical Specification 3rd
2669             Generation Partnership Project; Technical Specification
2670             Group Services and System Aspects; 3G Security;
2671             Specification of the 3GPP Confidentiality and Integrity
2672             Algorithms; Document 1: f8 and f9 Specification (Release
2673             4).
2674
2675   [f8-b]    3GPP TR 33.908 V4.0.0 (2001-09) Technical Report 3rd
2676             Generation Partnership Project; Technical Specification
2677             Group Services and System Aspects; 3G Security; General
2678             Report on the Design, Specification and Evaluation of 3GPP
2679             Standard Confidentiality and Integrity Algorithms (Release
2680             4).
2681
2682   [GDOI]    Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The
2683             Group Domain of Interpretation, RFC 3547, July 2003.
2684
2685
2686
2687
2688
2689
2690Baugher, et al.             Standards Track                    [Page 48]
2691
2692RFC 3711                          SRTP                        March 2004
2693
2694
2695   [HAC]     Menezes, A., Van Oorschot, P. and  S. Vanstone, "Handbook
2696             of Applied Cryptography", CRC Press, 1997, ISBN 0-8493-
2697             8523-7.
2698
2699   [H80]     Hellman, M. E., "A cryptanalytic time-memory trade-off",
2700             IEEE Transactions on Information Theory, July 1980, pp.
2701             401-406.
2702
2703   [IK]      T. Iwata and T. Kohno: "New Security Proofs for the 3GPP
2704             Confidentiality and Integrity Algorithms", Proceedings of
2705             FSE 2004.
2706
2707   [KINK]    Thomas, M. and J. Vilhuber, "Kerberized Internet
2708             Negotiation of Keys (KINK)", Work in Progress.
2709
2710   [KEYMGT]  Arrko, J., et al., "Key Management Extensions for Session
2711             Description Protocol (SDP) and Real Time Streaming Protocol
2712             (RTSP)", Work in Progress.
2713
2714   [KSYH]    Kang, J-S., Shin, S-U., Hong, D. and O. Yi, "Provable
2715             Security of KASUMI and 3GPP Encryption Mode f8",
2716             Proceedings Asiacrypt 2001, Springer Verlag LNCS 2248, pp.
2717             255-271, 2001.
2718
2719   [MIKEY]   Arrko, J., et. al., "MIKEY: Multimedia Internet KEYing",
2720             Work in Progress.
2721
2722   [MF00]    McGrew, D. and S. Fluhrer, "Attacks on Encryption of
2723             Redundant Plaintext and Implications on Internet Security",
2724             the Proceedings of the Seventh Annual Workshop on Selected
2725             Areas in Cryptography (SAC 2000), Springer-Verlag.
2726
2727   [PCST1]   Perrig, A., Canetti, R., Tygar, D. and D.  Song, "Efficient
2728             and Secure Source Authentication for Multicast", in Proc.
2729             of Network and Distributed System Security Symposium NDSS
2730             2001, pp. 35-46, 2001.
2731
2732   [PCST2]   Perrig, A., Canetti, R., Tygar, D. and D. Song, "Efficient
2733             Authentication and Signing of Multicast Streams over Lossy
2734             Channels", in Proc. of IEEE Security and Privacy Symposium
2735             S&P2000, pp. 56-73, 2000.
2736
2737   [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
2738             Recommendations for Security", RFC 1750, December 1994.
2739
2740   [RFC2675] Borman, D., Deering, S. and R. Hinden, "IPv6 Jumbograms",
2741             RFC 2675, August 1999.
2742
2743
2744
2745
2746Baugher, et al.             Standards Track                    [Page 49]
2747
2748RFC 3711                          SRTP                        March 2004
2749
2750
2751   [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukuhsima, H.,
2752             Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
2753             Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke,
2754             T., Yoshimura, T. and H. Zheng, "RObust Header Compression:
2755             Framework and Four Profiles: RTP, UDP, ESP, and
2756             uncompressed (ROHC)", RFC 3095, July 2001.
2757
2758   [RFC3242] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
2759             (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP ", RFC
2760             3242, April 2002.
2761
2762   [SDMS]    Andreasen, F., Baugher, M. and D. Wing, "Session
2763             Description Protocol Security Descriptions for Media
2764             Streams", Work in Progress.
2765
2766   [SWO]     Svanbro, K., Wiorek, J. and B. Olin, "Voice-over-IP-over-
2767             wireless", Proc.  PIMRC 2000, London, Sept. 2000.
2768
2769   [V02]     Vaudenay, S., "Security Flaws Induced by CBC Padding -
2770             Application to SSL, IPsec, WTLS...", Advances in
2771             Cryptology, EUROCRYPT'02, LNCS 2332, pp. 534-545.
2772
2773   [WC81]    Wegman, M. N., and  J.L. Carter, "New Hash Functions and
2774             Their Use in Authentication and Set Equality", JCSS 22,
2775             265-279, 1981.
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802Baugher, et al.             Standards Track                    [Page 50]
2803
2804RFC 3711                          SRTP                        March 2004
2805
2806
2807Appendix A: Pseudocode for Index Determination
2808
2809   The following is an example of pseudo-code for the algorithm to
2810   determine the index i of an SRTP packet with sequence number SEQ.  In
2811   the following, signed arithmetic is assumed.
2812
2813         if (s_l < 32,768)
2814            if (SEQ - s_l > 32,768)
2815               set v to (ROC-1) mod 2^32
2816            else
2817               set v to ROC
2818            endif
2819         else
2820            if (s_l - 32,768 > SEQ)
2821               set v to (ROC+1) mod 2^32
2822            else
2823               set v to ROC
2824            endif
2825         endif
2826         return SEQ + v*65,536
2827
2828Appendix B: Test Vectors
2829
2830   All values are in hexadecimal.
2831
2832B.1.  AES-f8 Test Vectors
2833
2834   SRTP PREFIX LENGTH  :   0
2835
2836   RTP packet header   :   806e5cba50681de55c621599
2837
2838   RTP packet payload  :   70736575646f72616e646f6d6e657373
2839                           20697320746865206e65787420626573
2840                           74207468696e67
2841
2842   ROC                 :   d462564a
2843   key                 :   234829008467be186c3de14aae72d62c
2844   salt key            :   32f2870d
2845   key-mask (m)        :   32f2870d555555555555555555555555
2846   key XOR key-mask    :   11baae0dd132eb4d3968b41ffb278379
2847
2848   IV                  :   006e5cba50681de55c621599d462564a
2849   IV'                 :   595b699bbd3bc0df26062093c1ad8f73
2850
2851
2852
2853
2854
2855
2856
2857
2858Baugher, et al.             Standards Track                    [Page 51]
2859
2860RFC 3711                          SRTP                        March 2004
2861
2862
2863   j = 0
2864   IV' xor j           :   595b699bbd3bc0df26062093c1ad8f73
2865   S(-1)               :   00000000000000000000000000000000
2866   IV' xor S(-1) xor j :   595b699bbd3bc0df26062093c1ad8f73
2867   S(0)                :   71ef82d70a172660240709c7fbb19d8e
2868   plaintext           :   70736575646f72616e646f6d6e657373
2869   ciphertext          :   019ce7a26e7854014a6366aa95d4eefd
2870
2871   j = 1
2872   IV' xor j           :   595b699bbd3bc0df26062093c1ad8f72
2873   S(0)                :   71ef82d70a172660240709c7fbb19d8e
2874   IV' xor S(0) xor j  :   28b4eb4cb72ce6bf020129543a1c12fc
2875   S(1)                :   3abd640a60919fd43bd289a09649b5fc
2876   plaintext           :   20697320746865206e65787420626573
2877   ciphertext          :   1ad4172a14f9faf455b7f1d4b62bd08f
2878
2879   j = 2
2880   IV' xor j           :   595b699bbd3bc0df26062093c1ad8f71
2881   S(1)                :   3abd640a60919fd43bd289a09649b5fc
2882   IV' xor S(1) xor j  :   63e60d91ddaa5f0b1dd4a93357e43a8d
2883   S(2)                :   220c7a8715266565b09ecc8a2a62b11b
2884   plaintext           :   74207468696e67
2885   ciphertext          :   562c0eef7c4802
2886
2887B.2.  AES-CM Test Vectors
2888
2889    Keystream segment length: 1044512 octets (65282 AES blocks)
2890    Session Key:      2B7E151628AED2A6ABF7158809CF4F3C
2891    Rollover Counter: 00000000
2892    Sequence Number:  0000
2893    SSRC:             00000000
2894    Session Salt:     F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000 (already shifted)
2895    Offset:           F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000
2896
2897    Counter                            Keystream
2898
2899    F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000   E03EAD0935C95E80E166B16DD92B4EB4
2900    F0F1F2F3F4F5F6F7F8F9FAFBFCFD0001   D23513162B02D0F72A43A2FE4A5F97AB
2901    F0F1F2F3F4F5F6F7F8F9FAFBFCFD0002   41E95B3BB0A2E8DD477901E4FCA894C0
2902    ...                                ...
2903    F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF   EC8CDF7398607CB0F2D21675EA9EA1E4
2904    F0F1F2F3F4F5F6F7F8F9FAFBFCFDFF00   362B7C3C6773516318A077D7FC5073AE
2905    F0F1F2F3F4F5F6F7F8F9FAFBFCFDFF01   6A2CC3787889374FBEB4C81B17BA6C44
2906
2907   Nota Bene: this test case is contrived so that the latter part of the
2908   keystream segment coincides with the test case in Section F.5.1 of
2909   [CTR].
2910
2911
2912
2913
2914Baugher, et al.             Standards Track                    [Page 52]
2915
2916RFC 3711                          SRTP                        March 2004
2917
2918
2919B.3.  Key Derivation Test Vectors
2920
2921   This section provides test data for the default key derivation
2922   function, which uses AES-128 in Counter Mode.  In the following, we
2923   walk through the initial key derivation for the AES-128 Counter Mode
2924   cipher, which requires a 16 octet session encryption key and a 14
2925   octet session salt, and an authentication function which requires a
2926   94-octet session authentication key.  These values are called the
2927   cipher key, the cipher salt, and the auth key in the following.
2928   Since this is the initial key derivation and the key derivation rate
2929   is equal to zero, the value of (index DIV key_derivation_rate) is
2930   zero (actually, a six-octet string of zeros).  In the following, we
2931   shorten key_derivation_rate to kdr.
2932
2933   The inputs to the key derivation function are the 16 octet master key
2934   and the 14 octet master salt:
2935
2936      master key:  E1F97A0D3E018BE0D64FA32C06DE4139
2937      master salt: 0EC675AD498AFEEBB6960B3AABE6
2938
2939   We first show how the cipher key is generated.  The input block for
2940   AES-CM is generated by exclusive-oring the master salt with the
2941   concatenation of the encryption key label 0x00 with (index DIV kdr),
2942   then padding on the right with two null octets (which implements the
2943   multiply-by-2^16 operation, see Section 4.3.3).  The resulting value
2944   is then AES-CM- encrypted using the master key to get the cipher key.
2945
2946      index DIV kdr:                 000000000000
2947      label:                       00
2948      master salt:   0EC675AD498AFEEBB6960B3AABE6
2949      -----------------------------------------------
2950      xor:           0EC675AD498AFEEBB6960B3AABE6     (x, PRF input)
2951
2952      x*2^16:        0EC675AD498AFEEBB6960B3AABE60000 (AES-CM input)
2953
2954      cipher key:    C61E7A93744F39EE10734AFE3FF7A087 (AES-CM output)
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970Baugher, et al.             Standards Track                    [Page 53]
2971
2972RFC 3711                          SRTP                        March 2004
2973
2974
2975   Next, we show how the cipher salt is generated.  The input block for
2976   AES-CM is generated by exclusive-oring the master salt with the
2977   concatenation of the encryption salt label.  That value is padded and
2978   encrypted as above.
2979
2980      index DIV kdr:                 000000000000
2981      label:                       02
2982      master salt:   0EC675AD498AFEEBB6960B3AABE6
2983
2984      ----------------------------------------------
2985      xor:           0EC675AD498AFEE9B6960B3AABE6     (x, PRF input)
2986
2987      x*2^16:        0EC675AD498AFEE9B6960B3AABE60000 (AES-CM input)
2988
2989                     30CBBC08863D8C85D49DB34A9AE17AC6 (AES-CM ouptut)
2990
2991      cipher salt:   30CBBC08863D8C85D49DB34A9AE1
2992
2993   We now show how the auth key is generated.  The input block for AES-
2994   CM is generated as above, but using the authentication key label.
2995
2996      index DIV kdr:                   000000000000
2997      label:                         01
2998      master salt:     0EC675AD498AFEEBB6960B3AABE6
2999      -----------------------------------------------
3000      xor:             0EC675AD498AFEEAB6960B3AABE6     (x, PRF input)
3001
3002      x*2^16:          0EC675AD498AFEEAB6960B3AABE60000 (AES-CM input)
3003
3004   Below, the auth key is shown on the left, while the corresponding AES
3005   input blocks are shown on the right.
3006
3007   auth key                           AES input blocks
3008   CEBE321F6FF7716B6FD4AB49AF256A15   0EC675AD498AFEEAB6960B3AABE60000
3009   6D38BAA48F0A0ACF3C34E2359E6CDBCE   0EC675AD498AFEEAB6960B3AABE60001
3010   E049646C43D9327AD175578EF7227098   0EC675AD498AFEEAB6960B3AABE60002
3011   6371C10C9A369AC2F94A8C5FBCDDDC25   0EC675AD498AFEEAB6960B3AABE60003
3012   6D6E919A48B610EF17C2041E47403576   0EC675AD498AFEEAB6960B3AABE60004
3013   6B68642C59BBFC2F34DB60DBDFB2       0EC675AD498AFEEAB6960B3AABE60005
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026Baugher, et al.             Standards Track                    [Page 54]
3027
3028RFC 3711                          SRTP                        March 2004
3029
3030
3031Authors' Addresses
3032
3033   Questions and comments should be directed to the authors and
3034   avt@ietf.org:
3035
3036   Mark Baugher
3037   Cisco Systems, Inc.
3038   5510 SW Orchid Street
3039   Portland, OR 97219 USA
3040
3041   Phone:  +1 408-853-4418
3042   EMail:  mbaugher@cisco.com
3043
3044
3045   Elisabetta Carrara
3046   Ericsson Research
3047   SE-16480 Stockholm
3048   Sweden
3049
3050   Phone:  +46 8 50877040
3051   EMail:  elisabetta.carrara@ericsson.com
3052
3053
3054   David A. McGrew
3055   Cisco Systems, Inc.
3056   San Jose, CA 95134-1706
3057   USA
3058
3059   Phone:  +1 301-349-5815
3060   EMail:  mcgrew@cisco.com
3061
3062
3063   Mats Naslund
3064   Ericsson Research
3065   SE-16480 Stockholm
3066   Sweden
3067
3068   Phone:  +46 8 58533739
3069   EMail:  mats.naslund@ericsson.com
3070
3071
3072   Karl Norrman
3073   Ericsson Research
3074   SE-16480 Stockholm
3075   Sweden
3076
3077   Phone:  +46 8 4044502
3078   EMail:  karl.norrman@ericsson.com
3079
3080
3081
3082Baugher, et al.             Standards Track                    [Page 55]
3083
3084RFC 3711                          SRTP                        March 2004
3085
3086
3087Full Copyright Statement
3088
3089   Copyright (C) The Internet Society (2004).  This document is subject
3090   to the rights, licenses and restrictions contained in BCP 78 and
3091   except as set forth therein, the authors retain all their rights.
3092
3093   This document and the information contained herein are provided on an
3094   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
3095   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
3096   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
3097   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
3098   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
3099   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
3100
3101Intellectual Property
3102
3103   The IETF takes no position regarding the validity or scope of any
3104   Intellectual Property Rights or other rights that might be claimed to
3105   pertain to the implementation or use of the technology described in
3106   this document or the extent to which any license under such rights
3107   might or might not be available; nor does it represent that it has
3108   made any independent effort to identify any such rights.  Information
3109   on the procedures with respect to rights in RFC documents can be
3110   found in BCP 78 and BCP 79.
3111
3112   Copies of IPR disclosures made to the IETF Secretariat and any
3113   assurances of licenses to be made available, or the result of an
3114   attempt made to obtain a general license or permission for the use of
3115   such proprietary rights by implementers or users of this
3116   specification can be obtained from the IETF on-line IPR repository at
3117   http://www.ietf.org/ipr.
3118
3119   The IETF invites any interested party to bring to its attention any
3120   copyrights, patents or patent applications, or other proprietary
3121   rights that may cover technology that may be required to implement
3122   this standard.  Please address the information to the IETF at ietf-
3123   ipr@ietf.org.
3124
3125Acknowledgement
3126
3127   Funding for the RFC Editor function is currently provided by the
3128   Internet Society.
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138Baugher, et al.             Standards Track                    [Page 56]
3139
3140