reactor-effect-client 0.2.0 → 0.3.0-rc.0

package/notices/owned-webrtc/rfc3711.txt

@@ -1,3139 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. Baugher
-Request for Comments: 3711                                     D. McGrew
-Category: Standards Track                            Cisco Systems, Inc.
-                                                              M. Naslund
-                                                              E. Carrara
-                                                              K. Norrman
-                                                       Ericsson Research
-                                                              March 2004
-
-
-             The Secure Real-time Transport Protocol (SRTP)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This document describes the Secure Real-time Transport Protocol
-   (SRTP), a profile of the Real-time Transport Protocol (RTP), which
-   can provide confidentiality, message authentication, and replay
-   protection to the RTP traffic and to the control traffic for RTP, the
-   Real-time Transport Control Protocol (RTCP).
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-       1.1.  Notational Conventions . . . . . . . . . . . . . . . . .  3
-   2.  Goals and Features . . . . . . . . . . . . . . . . . . . . . .  4
-       2.1.  Features . . . . . . . . . . . . . . . . . . . . . . . .  5
-   3.  SRTP Framework . . . . . . . . . . . . . . . . . . . . . . . .  5
-       3.1.  Secure RTP . . . . . . . . . . . . . . . . . . . . . . .  6
-       3.2.  SRTP Cryptographic Contexts. . . . . . . . . . . . . . .  7
-             3.2.1.  Transform-independent parameters . . . . . . . .  8
-             3.2.2.  Transform-dependent parameters . . . . . . . . . 10
-             3.2.3.  Mapping SRTP Packets to Cryptographic Contexts . 10
-       3.3.  SRTP Packet Processing . . . . . . . . . . . . . . . . . 11
-             3.3.1.  Packet Index Determination, and ROC, s_l Update. 13
-             3.3.2.  Replay Protection. . . . . . . . . . . . . . . . 15
-      3.4.  Secure RTCP . . . . . . . . . . . . . . . . . . . . . . . 15
-
-
-
-Baugher, et al.             Standards Track                     [Page 1]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   4.  Pre-Defined Cryptographic Transforms . . . . . . . . . . . . . 19
-       4.1.  Encryption . . . . . . . . . . . . . . . . . . . . . . . 19
-             4.1.1.  AES in Counter Mode. . . . . . . . . . . . . . . 21
-             4.1.2.  AES in f8-mode . . . . . . . . . . . . . . . . . 22
-             4.1.3.  NULL Cipher. . . . . . . . . . . . . . . . . . . 25
-       4.2.  Message Authentication and Integrity . . . . . . . . . . 25
-             4.2.1.  HMAC-SHA1. . . . . . . . . . . . . . . . . . . . 25
-       4.3.  Key Derivation . . . . . . . . . . . . . . . . . . . . . 26
-             4.3.1.  Key Derivation Algorithm . . . . . . . . . . . . 26
-             4.3.2.  SRTCP Key Derivation . . . . . . . . . . . . . . 28
-             4.3.3.  AES-CM PRF . . . . . . . . . . . . . . . . . . . 28
-   5.  Default and mandatory-to-implement Transforms. . . . . . . . . 28
-       5.1.  Encryption: AES-CM and NULL. . . . . . . . . . . . . . . 29
-       5.2.  Message Authentication/Integrity: HMAC-SHA1. . . . . . . 29
-       5.3.  Key Derivation: AES-CM PRF . . . . . . . . . . . . . . . 29
-   6.  Adding SRTP Transforms . . . . . . . . . . . . . . . . . . . . 29
-   7.  Rationale. . . . . . . . . . . . . . . . . . . . . . . . . . . 30
-       7.1.  Key derivation . . . . . . . . . . . . . . . . . . . . . 30
-       7.2.  Salting key. . . . . . . . . . . . . . . . . . . . . . . 30
-       7.3.  Message Integrity from Universal Hashing . . . . . . . . 31
-       7.4.  Data Origin Authentication Considerations. . . . . . . . 31
-       7.5.  Short and Zero-length Message Authentication . . . . . . 32
-   8.  Key Management Considerations. . . . . . . . . . . . . . . . . 33
-       8.1.  Re-keying  . . . . . . . . . . . . . . . . . . . . . . . 34
-             8.1.1.  Use of the <From, To> for re-keying. . . . . . . 34
-       8.2.  Key Management parameters. . . . . . . . . . . . . . . . 35
-   9.  Security Considerations. . . . . . . . . . . . . . . . . . . . 37
-       9.1.  SSRC collision and two-time pad. . . . . . . . . . . . . 37
-       9.2.  Key Usage. . . . . . . . . . . . . . . . . . . . . . . . 38
-       9.3.  Confidentiality of the RTP Payload . . . . . . . . . . . 39
-       9.4.  Confidentiality of the RTP Header. . . . . . . . . . . . 40
-       9.5.  Integrity of the RTP payload and header. . . . . . . . . 40
-             9.5.1. Risks of Weak or Null Message Authentication. . . 42
-             9.5.2.  Implicit Header Authentication . . . . . . . . . 43
-   10.  Interaction with Forward Error Correction mechanisms. . . . . 43
-   11.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 43
-       11.1. Unicast. . . . . . . . . . . . . . . . . . . . . . . . . 43
-       11.2. Multicast (one sender) . . . . . . . . . . . . . . . . . 44
-       11.3. Re-keying and access control . . . . . . . . . . . . . . 45
-       11.4. Summary of basic scenarios . . . . . . . . . . . . . . . 46
-   12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 46
-   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
-   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
-       14.1. Normative References . . . . . . . . . . . . . . . . . . 47
-       14.2. Informative References . . . . . . . . . . . . . . . . . 48
-   Appendix A: Pseudocode for Index Determination . . . . . . . . . . 51
-   Appendix B: Test Vectors . . . . . . . . . . . . . . . . . . . . . 51
-       B.1.  AES-f8 Test Vectors. . . . . . . . . . . . . . . . . . . 51
-
-
-
-Baugher, et al.             Standards Track                     [Page 2]
-
-RFC 3711                          SRTP                        March 2004
-
-
-       B.2.  AES-CM Test Vectors. . . . . . . . . . . . . . . . . . . 52
-       B.3.  Key Derivation Test Vectors. . . . . . . . . . . . . . . 53
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 56
-
-1.  Introduction
-
-   This document describes the Secure Real-time Transport Protocol
-   (SRTP), a profile of the Real-time Transport Protocol (RTP), which
-   can provide confidentiality, message authentication, and replay
-   protection to the RTP traffic and to the control traffic for RTP,
-   RTCP (the Real-time Transport Control Protocol) [RFC3350].
-
-   SRTP provides a framework for encryption and message authentication
-   of RTP and RTCP streams (Section 3).  SRTP defines a set of default
-   cryptographic transforms (Sections 4 and 5), and it allows new
-   transforms to be introduced in the future (Section 6).  With
-   appropriate key management (Sections 7 and 8), SRTP is secure
-   (Sections 9) for unicast and multicast RTP applications (Section 11).
-
-   SRTP can achieve high throughput and low packet expansion.  SRTP
-   proves to be a suitable protection for heterogeneous environments
-   (mix of wired and wireless networks).  To get such features, default
-   transforms are described, based on an additive stream cipher for
-   encryption, a keyed-hash based function for message authentication,
-   and an "implicit" index for sequencing/synchronization based on the
-   RTP sequence number for SRTP and an index number for Secure RTCP
-   (SRTCP).
-
-1.1.  Notational Conventions
-
-   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].  The
-   terminology conforms to [RFC2828] with the following exception.  For
-   simplicity we use the term "random" throughout the document to denote
-   randomly or pseudo-randomly generated values.  Large amounts of
-   random bits may be difficult to obtain, and for the security of SRTP,
-   pseudo-randomness is sufficient [RFC1750].
-
-   By convention, the adopted representation is the network byte order,
-   i.e., the left most bit (octet) is the most significant one.  By XOR
-   we mean bitwise addition modulo 2 of binary strings, and || denotes
-   concatenation.  In other words, if C = A || B, then the most
-   significant bits of C are the bits of A, and the least significant
-   bits of C equal the bits of B.  Hexadecimal numbers are prefixed by
-   0x.
-
-
-
-
-Baugher, et al.             Standards Track                     [Page 3]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   The word "encryption" includes also use of the NULL algorithm (which
-   in practice does leave the data in the clear).
-
-   With slight abuse of notation, we use the terms "message
-   authentication" and "authentication tag" as is common practice, even
-   though in some circumstances, e.g., group communication, the service
-   provided is actually only integrity protection and not data origin
-   authentication.
-
-2.  Goals and Features
-
-   The security goals for SRTP are to ensure:
-
-   *  the confidentiality of the RTP and RTCP payloads, and
-
-   *  the integrity of the entire RTP and RTCP packets, together with
-      protection against replayed packets.
-
-   These security services are optional and independent from each other,
-   except that SRTCP integrity protection is mandatory (malicious or
-   erroneous alteration of RTCP messages could otherwise disrupt the
-   processing of the RTP stream).
-
-   Other, functional, goals for the protocol are:
-
-   *  a framework that permits upgrading with new cryptographic
-      transforms,
-
-   *  low bandwidth cost, i.e., a framework preserving RTP header
-      compression efficiency,
-
-   and, asserted by the pre-defined transforms:
-
-   *  a low computational cost,
-
-   *  a small footprint (i.e., small code size and data memory for
-      keying information and replay lists),
-
-   *  limited packet expansion to support the bandwidth economy goal,
-
-   *  independence from the underlying transport, network, and physical
-      layers used by RTP, in particular high tolerance to packet loss
-      and re-ordering.
-
-   These properties ensure that SRTP is a suitable protection scheme for
-   RTP/RTCP in both wired and wireless scenarios.
-
-
-
-
-
-Baugher, et al.             Standards Track                     [Page 4]
-
-RFC 3711                          SRTP                        March 2004
-
-
-2.1.  Features
-
-   Besides the above mentioned direct goals, SRTP provides for some
-   additional features.  They have been introduced to lighten the burden
-   on key management and to further increase security.  They include:
-
-   *  A single "master key" can provide keying material for
-      confidentiality and integrity protection, both for the SRTP stream
-      and the corresponding SRTCP stream.  This is achieved with a key
-      derivation function (see Section 4.3), providing "session keys"
-      for the respective security primitive, securely derived from the
-      master key.
-
-   *  In addition, the key derivation can be configured to periodically
-      refresh the session keys, which limits the amount of ciphertext
-      produced by a fixed key, available for an adversary to
-      cryptanalyze.
-
-   *  "Salting keys" are used to protect against pre-computation and
-      time-memory tradeoff attacks [MF00] [BS00].
-
-   Detailed rationale for these features can be found in Section 7.
-
-3.  SRTP Framework
-
-   RTP is the Real-time Transport Protocol [RFC3550].  We define SRTP as
-   a profile of RTP.  This profile is an extension to the RTP
-   Audio/Video Profile [RFC3551].  Except where explicitly noted, all
-   aspects of that profile apply, with the addition of the SRTP security
-   features.  Conceptually, we consider SRTP to be a "bump in the stack"
-   implementation which resides between the RTP application and the
-   transport layer.  SRTP intercepts RTP packets and then forwards an
-   equivalent SRTP packet on the sending side, and intercepts SRTP
-   packets and passes an equivalent RTP packet up the stack on the
-   receiving side.
-
-   Secure RTCP (SRTCP) provides the same security services to RTCP as
-   SRTP does to RTP.  SRTCP message authentication is MANDATORY and
-   thereby protects the RTCP fields to keep track of membership, provide
-   feedback to RTP senders, or maintain packet sequence counters.  SRTCP
-   is described in Section 3.4.
-
-
-
-
-
-
-
-
-
-
-Baugher, et al.             Standards Track                     [Page 5]
-
-RFC 3711                          SRTP                        March 2004
-
-
-3.1.  Secure RTP
-
-      The format of an SRTP packet is illustrated in Figure 1.
-
-        0                   1                   2                   3
-      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
-     |V=2|P|X|  CC   |M|     PT      |       sequence number         | |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
-     |                           timestamp                           | |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
-     |           synchronization source (SSRC) identifier            | |
-     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
-     |            contributing source (CSRC) identifiers             | |
-     |                               ....                            | |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
-     |                   RTP extension (OPTIONAL)                    | |
-   +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
-   | |                          payload  ...                         | |
-   | |                               +-------------------------------+ |
-   | |                               | RTP padding   | RTP pad count | |
-   +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
-   | ~                     SRTP MKI (OPTIONAL)                       ~ |
-   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
-   | :                 authentication tag (RECOMMENDED)              : |
-   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
-   |                                                                   |
-   +- Encrypted Portion*                      Authenticated Portion ---+
-
-   Figure 1.  The format of an SRTP packet.  *Encrypted Portion is the
-   same size as the plaintext for the Section 4 pre-defined transforms.
-
-   The "Encrypted Portion" of an SRTP packet consists of the encryption
-   of the RTP payload (including RTP padding when present) of the
-   equivalent RTP packet.  The Encrypted Portion MAY be the exact size
-   of the plaintext or MAY be larger.  Figure 1 shows the RTP payload
-   including any possible padding for RTP [RFC3550].
-
-   None of the pre-defined encryption transforms uses any padding; for
-   these, the RTP and SRTP payload sizes match exactly.  New transforms
-   added to SRTP (following Section 6) may require padding, and may
-   hence produce larger payloads.  RTP provides its own padding format
-   (as seen in Fig. 1), which due to the padding indicator in the RTP
-   header has merits in terms of compactness relative to paddings using
-   prefix-free codes.  This RTP padding SHALL be the default method for
-   transforms requiring padding.  Transforms MAY specify other padding
-   methods, and MUST then specify the amount, format, and processing of
-   their padding.  It is important to note that encryption transforms
-
-
-
-Baugher, et al.             Standards Track                     [Page 6]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   that use padding are vulnerable to subtle attacks, especially when
-   message authentication is not used [V02].  Each specification for a
-   new encryption transform needs to carefully consider and describe the
-   security implications of the padding that it uses.  Message
-   authentication codes define their own padding, so this default does
-   not apply to authentication transforms.
-
-   The OPTIONAL MKI and the RECOMMENDED authentication tag are the only
-   fields defined by SRTP that are not in RTP.  Only 8-bit alignment is
-   assumed.
-
-      MKI (Master Key Identifier): configurable length, OPTIONAL.  The
-              MKI is defined, signaled, and used by key management.  The
-              MKI identifies the master key from which the session
-              key(s) were derived that authenticate and/or encrypt the
-              particular packet.  Note that the MKI SHALL NOT identify
-              the SRTP cryptographic context, which is identified
-              according to Section 3.2.3.  The MKI MAY be used by key
-              management for the purposes of re-keying, identifying a
-              particular master key within the cryptographic context
-              (Section 3.2.1).
-
-      Authentication tag: configurable length, RECOMMENDED.  The
-              authentication tag is used to carry message authentication
-              data.  The Authenticated Portion of an SRTP packet
-              consists of the RTP header followed by the Encrypted
-              Portion of the SRTP packet.  Thus, if both encryption and
-              authentication are applied, encryption SHALL be applied
-              before authentication on the sender side and conversely on
-              the receiver side.  The authentication tag provides
-              authentication of the RTP header and payload, and it
-              indirectly provides replay protection by authenticating
-              the sequence number.  Note that the MKI is not integrity
-              protected as this does not provide any extra protection.
-
-3.2.  SRTP Cryptographic Contexts
-
-   Each SRTP stream requires the sender and receiver to maintain
-   cryptographic state information.  This information is called the
-   "cryptographic context".
-
-   SRTP uses two types of keys: session keys and master keys.  By a
-   "session key", we mean a key which is used directly in a
-   cryptographic transform (e.g., encryption or message authentication),
-   and by a "master key", we mean a random bit string (given by the key
-   management protocol) from which session keys are derived in a
-
-
-
-
-
-Baugher, et al.             Standards Track                     [Page 7]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   cryptographically secure way.  The master key(s) and other parameters
-   in the cryptographic context are provided by key management
-   mechanisms external to SRTP, see Section 8.
-
-3.2.1.  Transform-independent parameters
-
-   Transform-independent parameters are present in the cryptographic
-   context independently of the particular encryption or authentication
-   transforms that are used.  The transform-independent parameters of
-   the cryptographic context for SRTP consist of:
-
-   *  a 32-bit unsigned rollover counter (ROC), which records how many
-      times the 16-bit RTP sequence number has been reset to zero after
-      passing through 65,535.  Unlike the sequence number (SEQ), which
-      SRTP extracts from the RTP packet header, the ROC is maintained by
-      SRTP as described in Section 3.3.1.
-
-      We define the index of the SRTP packet corresponding to a given
-      ROC and RTP sequence number to be the 48-bit quantity
-
-            i = 2^16 * ROC + SEQ.
-
-   *  for the receiver only, a 16-bit sequence number s_l, which can be
-      thought of as the highest received RTP sequence number (see
-      Section 3.3.1 for its handling), which SHOULD be authenticated
-      since message authentication is RECOMMENDED,
-
-   *  an identifier for the encryption algorithm, i.e., the cipher and
-      its mode of operation,
-
-   *  an identifier for the message authentication algorithm,
-
-   *  a replay list, maintained by the receiver only (when
-      authentication and replay protection are provided), containing
-      indices of recently received and authenticated SRTP packets,
-
-   *  an MKI indicator (0/1) as to whether an MKI is present in SRTP and
-      SRTCP packets,
-
-   *  if the MKI indicator is set to one, the length (in octets) of the
-      MKI field, and (for the sender) the actual value of the currently
-      active MKI (the value of the MKI indicator and length MUST be kept
-      fixed for the lifetime of the context),
-
-   *  the master key(s), which MUST be random and kept secret,
-
-
-
-
-
-
-Baugher, et al.             Standards Track                     [Page 8]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   *  for each master key, there is a counter of the number of SRTP
-      packets that have been processed (sent) with that master key
-      (essential for security, see Sections 3.3.1 and 9),
-
-   *  non-negative integers n_e, and n_a, determining the length of the
-      session keys for encryption, and message authentication.
-
-   In addition, for each master key, an SRTP stream MAY use the
-   following associated values:
-
-   *  a master salt, to be used in the key derivation of session keys.
-      This value, when used, MUST be random, but MAY be public.  Use of
-      master salt is strongly RECOMMENDED, see Section 9.2.  A "NULL"
-      salt is treated as 00...0.
-
-   *  an integer in the set {1,2,4,...,2^24}, the "key_derivation_rate",
-      where an unspecified value is treated as zero.  The constraint to
-      be a power of 2 simplifies the session-key derivation
-      implementation, see Section 4.3.
-
-   *  an MKI value,
-
-   *  <From, To> values, specifying the lifetime for a master key,
-      expressed in terms of the two 48-bit index values inside whose
-      range (including the range end-points) the master key is valid.
-      For the use of <From, To>, see Section 8.1.1.  <From, To> is an
-      alternative to the MKI and assumes that a master key is in one-
-      to-one correspondence with the SRTP session key on which the
-      <From, To> range is defined.
-
-   SRTCP SHALL by default share the crypto context with SRTP, except:
-
-   *  no rollover counter and s_l-value need to be maintained as the
-      RTCP index is explicitly carried in each SRTCP packet,
-
-   *  a separate replay list is maintained (when replay protection is
-      provided),
-
-   *  SRTCP maintains a separate counter for its master key (even if the
-      master key is the same as that for SRTP, see below), as a means to
-      maintain a count of the number of SRTCP packets that have been
-      processed with that key.
-
-   Note in particular that the master key(s) MAY be shared between SRTP
-   and the corresponding SRTCP, if the pre-defined transforms (including
-   the key derivation) are used but the session key(s) MUST NOT be so
-   shared.
-
-
-
-
-Baugher, et al.             Standards Track                     [Page 9]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   In addition, there can be cases (see Sections 8 and 9.1) where
-   several SRTP streams within a given RTP session, identified by their
-   synchronization source (SSRCs, which is part of the RTP header),
-   share most of the crypto context parameters (including possibly
-   master and session keys).  In such cases, just as in the normal
-   SRTP/SRTCP parameter sharing above, separate replay lists and packet
-   counters for each stream (SSRC) MUST still be maintained.  Also,
-   separate SRTP indices MUST then be maintained.
-
-   A summary of parameters, pre-defined transforms, and default values
-   for the above parameters (and other SRTP parameters) can be found in
-   Sections 5 and 8.2.
-
-3.2.2.  Transform-dependent parameters
-
-   All encryption, authentication/integrity, and key derivation
-   parameters are defined in the transforms section (Section 4).
-   Typical examples of such parameters are block size of ciphers,
-   session keys, data for the Initialization Vector (IV) formation, etc.
-   Future SRTP transform specifications MUST include a section to list
-   the additional cryptographic context's parameters for that transform,
-   if any.
-
-3.2.3.  Mapping SRTP Packets to Cryptographic Contexts
-
-   Recall that an RTP session for each participant is defined [RFC3550]
-   by a pair of destination transport addresses (one network address
-   plus a port pair for RTP and RTCP), and that a multimedia session is
-   defined as a collection of RTP sessions.  For example, a particular
-   multimedia session could include an audio RTP session, a video RTP
-   session, and a text RTP session.
-
-   A cryptographic context SHALL be uniquely identified by the triplet
-   context identifier:
-
-   context id = <SSRC, destination network address, destination
-   transport port number>
-
-   where the destination network address and the destination transport
-   port are the ones in the SRTP packet.  It is assumed that, when
-   presented with this information, the key management returns a context
-   with the information as described in Section 3.2.
-
-   As noted above, SRTP and SRTCP by default share the bulk of the
-   parameters in the cryptographic context.  Thus, retrieving the crypto
-   context parameters for an SRTCP stream in practice may imply a
-   binding to the correspondent SRTP crypto context.  It is up to the
-   implementation to assure such binding, since the RTCP port may not be
-
-
-
-Baugher, et al.             Standards Track                    [Page 10]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   directly deducible from the RTP port only.  Alternatively, the key
-   management may choose to provide separate SRTP- and SRTCP- contexts,
-   duplicating the common parameters (such as master key(s)).  The
-   latter approach then also enables SRTP and SRTCP to use, e.g.,
-   distinct transforms, if so desired.  Similar considerations arise
-   when multiple SRTP streams, forming part of one single RTP session,
-   share keys and other parameters.
-
-   If no valid context can be found for a packet corresponding to a
-   certain context identifier, that packet MUST be discarded.
-
-3.3.  SRTP Packet Processing
-
-   The following applies to SRTP.  SRTCP is described in Section 3.4.
-
-   Assuming initialization of the cryptographic context(s) has taken
-   place via key management, the sender SHALL do the following to
-   construct an SRTP packet:
-
-   1. Determine which cryptographic context to use as described in
-      Section 3.2.3.
-
-   2. Determine the index of the SRTP packet using the rollover counter,
-      the highest sequence number in the cryptographic context, and the
-      sequence number in the RTP packet, as described in Section 3.3.1.
-
-   3. Determine the master key and master salt.  This is done using the
-      index determined in the previous step or the current MKI in the
-      cryptographic context, according to Section 8.1.
-
-   4. Determine the session keys and session salt (if they are used by
-      the transform) as described in Section 4.3, using master key,
-      master salt, key_derivation_rate, and session key-lengths in the
-      cryptographic context with the index, determined in Steps 2 and 3.
-
-   5. Encrypt the RTP payload to produce the Encrypted Portion of the
-      packet (see Section 4.1, for the defined ciphers).  This step uses
-      the encryption algorithm indicated in the cryptographic context,
-      the session encryption key and the session salt (if used) found in
-      Step 4 together with the index found in Step 2.
-
-   6. If the MKI indicator is set to one, append the MKI to the packet.
-
-   7. For message authentication, compute the authentication tag for the
-      Authenticated Portion of the packet, as described in Section 4.2.
-      This step uses the current rollover counter, the authentication
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 11]
-
-RFC 3711                          SRTP                        March 2004
-
-
-      algorithm indicated in the cryptographic context, and the session
-      authentication key found in Step 4.  Append the authentication tag
-      to the packet.
-
-   8. If necessary, update the ROC as in Section 3.3.1, using the packet
-      index determined in Step 2.
-
-   To authenticate and decrypt an SRTP packet, the receiver SHALL do the
-   following:
-
-   1. Determine which cryptographic context to use as described in
-      Section 3.2.3.
-
-   2. Run the algorithm in Section 3.3.1 to get the index of the SRTP
-      packet.  The algorithm uses the rollover counter and highest
-      sequence number in the cryptographic context with the sequence
-      number in the SRTP packet, as described in Section 3.3.1.
-
-   3. Determine the master key and master salt.  If the MKI indicator in
-      the context is set to one, use the MKI in the SRTP packet,
-      otherwise use the index from the previous step, according to
-      Section 8.1.
-
-   4. Determine the session keys, and session salt (if used by the
-      transform) as described in Section 4.3, using master key, master
-      salt, key_derivation_rate and session key-lengths in the
-      cryptographic context with the index, determined in Steps 2 and 3.
-
-   5. For message authentication and replay protection, first check if
-      the packet has been replayed (Section 3.3.2), using the Replay
-      List and the index as determined in Step 2.  If the packet is
-      judged to be replayed, then the packet MUST be discarded, and the
-      event SHOULD be logged.
-
-      Next, perform verification of the authentication tag, using the
-      rollover counter from Step 2, the authentication algorithm
-      indicated in the cryptographic context, and the session
-      authentication key from Step 4.  If the result is "AUTHENTICATION
-      FAILURE" (see Section 4.2), the packet MUST be discarded from
-      further processing and the event SHOULD be logged.
-
-   6. Decrypt the Encrypted Portion of the packet (see Section 4.1, for
-      the defined ciphers), using the decryption algorithm indicated in
-      the cryptographic context, the session encryption key and salt (if
-      used) found in Step 4 with the index from Step 2.
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 12]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   7. Update the rollover counter and highest sequence number, s_l, in
-      the cryptographic context as in Section 3.3.1, using the packet
-      index estimated in Step 2.  If replay protection is provided, also
-      update the Replay List as described in Section 3.3.2.
-
-   8. When present, remove the MKI and authentication tag fields from
-      the packet.
-
-3.3.1.  Packet Index Determination, and ROC, s_l Update
-
-   SRTP implementations use an "implicit" packet index for sequencing,
-   i.e., not all of the index is explicitly carried in the SRTP packet.
-   For the pre-defined transforms, the index i is used in replay
-   protection (Section 3.3.2), encryption (Section 4.1), message
-   authentication (Section 4.2), and for the key derivation (Section
-   4.3).
-
-   When the session starts, the sender side MUST set the rollover
-   counter, ROC, to zero.  Each time the RTP sequence number, SEQ, wraps
-   modulo 2^16, the sender side MUST increment ROC by one, modulo 2^32
-   (see security aspects below).  The sender's packet index is then
-   defined as
-
-      i = 2^16 * ROC + SEQ.
-
-   Receiver-side implementations use the RTP sequence number to
-   determine the correct index of a packet, which is the location of the
-   packet in the sequence of all SRTP packets.  A robust approach for
-   the proper use of a rollover counter requires its handling and use to
-   be well defined.  In particular, out-of-order RTP packets with
-   sequence numbers close to 2^16 or zero must be properly handled.
-
-   The index estimate is based on the receiver's locally maintained ROC
-   and s_l values.  At the setup of the session, the ROC MUST be set to
-   zero.  Receivers joining an on-going session MUST be given the
-   current ROC value using out-of-band signaling such as key-management
-   signaling.  Furthermore, the receiver SHALL initialize s_l to the RTP
-   sequence number (SEQ) of the first observed SRTP packet (unless the
-   initial value is provided by out of band signaling such as key
-   management).
-
-   On consecutive SRTP packets, the receiver SHOULD estimate the index
-   as
-         i = 2^16 * v + SEQ,
-
-   where v is chosen from the set { ROC-1, ROC, ROC+1 } (modulo 2^32)
-   such that i is closest (in modulo 2^48 sense) to the value 2^16 * ROC
-   + s_l (see Appendix A for pseudocode).
-
-
-
-Baugher, et al.             Standards Track                    [Page 13]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   After the packet has been processed and authenticated (when enabled
-   for SRTP packets for the session), the receiver MUST use v to
-   conditionally update its s_l and ROC variables as follows.  If
-   v=(ROC-1) mod 2^32, then there is no update to s_l or ROC.  If v=ROC,
-   then s_l is set to SEQ if and only if SEQ is larger than the current
-   s_l; there is no change to ROC.  If v=(ROC+1) mod 2^32, then s_l is
-   set to SEQ and ROC is set to v.
-
-   After a re-keying occurs (changing to a new master key), the rollover
-   counter always maintains its sequence of values, i.e., it MUST NOT be
-   reset to zero.
-
-   As the rollover counter is 32 bits long and the sequence number is 16
-   bits long, the maximum number of packets belonging to a given SRTP
-   stream that can be secured with the same key is 2^48 using the pre-
-   defined transforms.  After that number of SRTP packets have been sent
-   with a given (master or session) key, the sender MUST NOT send any
-   more packets with that key.  (There exists a similar limit for SRTCP,
-   which in practice may be more restrictive, see Section 9.2.)  This
-   limitation enforces a security benefit by providing an upper bound on
-   the amount of traffic that can pass before cryptographic keys are
-   changed.  Re-keying (see Section 8.1) MUST be triggered, before this
-   amount of traffic, and MAY be triggered earlier, e.g., for increased
-   security and access control to media.  Recurring key derivation by
-   means of a non-zero key_derivation_rate (see Section 4.3), also gives
-   stronger security but does not change the above absolute maximum
-   value.
-
-   On the receiver side, there is a caveat to updating s_l and ROC: if
-   message authentication is not present, neither the initialization of
-   s_l, nor the ROC update can be made completely robust.  The
-   receiver's "implicit index" approach works for the pre-defined
-   transforms as long as the reorder and loss of the packets are not too
-   great and bit-errors do not occur in unfortunate ways.  In
-   particular, 2^15 packets would need to be lost, or a packet would
-   need to be 2^15 packets out of sequence before synchronization is
-   lost.  Such drastic loss or reorder is likely to disrupt the RTP
-   application itself.
-
-   The algorithm for the index estimate and ROC update is a matter of
-   implementation, and should take into consideration the environment
-   (e.g., packet loss rate) and the cases when synchronization is likely
-   to be lost, e.g., when the initial sequence number (randomly chosen
-   by RTP) is not known in advance (not sent in the key management
-   protocol) but may be near to wrap modulo 2^16.
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 14]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   A more elaborate and more robust scheme than the one given above is
-   the handling of RTP's own "rollover counter", see Appendix A.1 of
-   [RFC3550].
-
-3.3.2.  Replay Protection
-
-   Secure replay protection is only possible when integrity protection
-   is present.  It is RECOMMENDED to use replay protection, both for RTP
-   and RTCP, as integrity protection alone cannot assure security
-   against replay attacks.
-
-   A packet is "replayed" when it is stored by an adversary, and then
-   re-injected into the network.  When message authentication is
-   provided, SRTP protects against such attacks through a Replay List.
-   Each SRTP receiver maintains a Replay List, which conceptually
-   contains the indices of all of the packets which have been received
-   and authenticated.  In practice, the list can use a "sliding window"
-   approach, so that a fixed amount of storage suffices for replay
-   protection.  Packet indices which lag behind the packet index in the
-   context by more than SRTP-WINDOW-SIZE can be assumed to have been
-   received, where SRTP-WINDOW-SIZE is a receiver-side, implementation-
-   dependent parameter and MUST be at least 64, but which MAY be set to
-   a higher value.
-
-   The receiver checks the index of an incoming packet against the
-   replay list and the window.  Only packets with index ahead of the
-   window, or, inside the window but not already received, SHALL be
-   accepted.
-
-   After the packet has been authenticated (if necessary the window is
-   first moved ahead), the replay list SHALL be updated with the new
-   index.
-
-   The Replay List can be efficiently implemented by using a bitmap to
-   represent which packets have been received, as described in the
-   Security Architecture for IP [RFC2401].
-
-3.4.  Secure RTCP
-
-   Secure RTCP follows the definition of Secure RTP.  SRTCP adds three
-   mandatory new fields (the SRTCP index, an "encrypt-flag", and the
-   authentication tag) and one optional field (the MKI) to the RTCP
-   packet definition.  The three mandatory fields MUST be appended to an
-   RTCP packet in order to form an equivalent SRTCP packet.  The added
-   fields follow any other profile-specific extensions.
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 15]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   According to Section 6.1 of [RFC3550], there is a REQUIRED packet
-   format for compound packets.  SRTCP MUST be given packets according
-   to that requirement in the sense that the first part MUST be a sender
-   report or a receiver report.  However, the RTCP encryption prefix (a
-   random 32-bit quantity) specified in that Section MUST NOT be used
-   since, as is stated there, it is only applicable to the encryption
-   method specified in [RFC3550] and is not needed by the cryptographic
-   mechanisms used in SRTP.
-
-      0                   1                   2                   3
-      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
-     |V=2|P|    RC   |   PT=SR or RR   |             length          | |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
-     |                         SSRC of sender                        | |
-   +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
-   | ~                          sender info                          ~ |
-   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
-   | ~                         report block 1                        ~ |
-   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
-   | ~                         report block 2                        ~ |
-   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
-   | ~                              ...                              ~ |
-   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
-   | |V=2|P|    SC   |  PT=SDES=202  |             length            | |
-   | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
-   | |                          SSRC/CSRC_1                          | |
-   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
-   | ~                           SDES items                          ~ |
-   | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
-   | ~                              ...                              ~ |
-   +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
-   | |E|                         SRTCP index                         | |
-   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
-   | ~                     SRTCP MKI (OPTIONAL)                      ~ |
-   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
-   | :                     authentication tag                        : |
-   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
-   |                                                                   |
-   +-- Encrypted Portion                    Authenticated Portion -----+
-
-
-   Figure 2.  An example of the format of a Secure RTCP packet,
-   consisting of an underlying RTCP compound packet with a Sender Report
-   and SDES packet.
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 16]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   The Encrypted Portion of an SRTCP packet consists of the encryption
-   (Section 4.1) of the RTCP payload of the equivalent compound RTCP
-   packet, from the first RTCP packet, i.e., from the ninth (9) octet to
-   the end of the compound packet.  The Authenticated Portion of an
-   SRTCP packet consists of the entire equivalent (eventually compound)
-   RTCP packet, the E flag, and the SRTCP index (after any encryption
-   has been applied to the payload).
-
-   The added fields are:
-
-   E-flag: 1 bit, REQUIRED
-            The E-flag indicates if the current SRTCP packet is
-            encrypted or unencrypted.  Section 9.1 of [RFC3550] allows
-            the split of a compound RTCP packet into two lower-layer
-            packets, one to be encrypted and one to be sent in the
-            clear.  The E bit set to "1" indicates encrypted packet, and
-            "0" indicates non-encrypted packet.
-
-   SRTCP index: 31 bits, REQUIRED
-            The SRTCP index is a 31-bit counter for the SRTCP packet.
-            The index is explicitly included in each packet, in contrast
-            to the "implicit" index approach used for SRTP.  The SRTCP
-            index MUST be set to zero before the first SRTCP packet is
-            sent, and MUST be incremented by one, modulo 2^31, after
-            each SRTCP packet is sent.  In particular, after a re-key,
-            the SRTCP index MUST NOT be reset to zero again.
-
-   Authentication Tag: configurable length, REQUIRED
-            The authentication tag is used to carry message
-            authentication data.
-
-   MKI: configurable length, OPTIONAL
-            The MKI is the Master Key Indicator, and functions according
-            to the MKI definition in Section 3.
-
-   SRTCP uses the cryptographic context parameters and packet processing
-   of SRTP by default, with the following changes:
-
-   *  The receiver does not need to "estimate" the index, as it is
-      explicitly signaled in the packet.
-
-   *  Pre-defined SRTCP encryption is as specified in Section 4.1, but
-      using the definition of the SRTCP Encrypted Portion given in this
-      section, and using the SRTCP index as the index i.  The encryption
-      transform and related parameters SHALL by default be the same
-      selected for the protection of the associated SRTP stream(s),
-      while the NULL algorithm SHALL be applied to the RTCP packets not
-      to be encrypted.  SRTCP may have a different encryption transform
-
-
-
-Baugher, et al.             Standards Track                    [Page 17]
-
-RFC 3711                          SRTP                        March 2004
-
-
-      than the one used by the corresponding SRTP.  The expected use for
-      this feature is when the former has NULL-encryption and the latter
-      has a non NULL-encryption.
-
-   The E-flag is assigned a value by the sender depending on whether the
-   packet was encrypted or not.
-
-   *  SRTCP decryption is performed as in Section 4, but only if the E
-      flag is equal to 1.  If so, the Encrypted Portion is decrypted,
-      using the SRTCP index as the index i.  In case the E-flag is 0,
-      the payload is simply left unmodified.
-
-   *  SRTCP replay protection is as defined in Section 3.3.2, but using
-      the SRTCP index as the index i and a separate Replay List that is
-      specific to SRTCP.
-
-   *  The pre-defined SRTCP authentication tag is specified as in
-      Section 4.2, but with the Authenticated Portion of the SRTCP
-      packet given in this section (which includes the index).  The
-      authentication transform and related parameters (e.g., key size)
-      SHALL by default be the same as selected for the protection of the
-      associated SRTP stream(s).
-
-   *  In the last step of the processing, only the sender needs to
-      update the value of the SRTCP index by incrementing it modulo 2^31
-      and for security reasons the sender MUST also check the number of
-      SRTCP packets processed, see Section 9.2.
-
-   Message authentication for RTCP is REQUIRED, as it is the control
-   protocol (e.g., it has a BYE packet) for RTP.
-
-   Precautions must be taken so that the packet expansion in SRTCP (due
-   to the added fields) does not cause SRTCP messages to use more than
-   their share of RTCP bandwidth.  To avoid this, the following two
-   measures MUST be taken:
-
-   1. When initializing the RTCP variable "avg_rtcp_size" defined in
-      chapter 6.3 of [RFC3550], it MUST include the size of the fields
-      that will be added by SRTCP (index, E-bit, authentication tag, and
-      when present, the MKI).
-
-   2. When updating the "avg_rtcp_size" using the variable "packet_size"
-      (section 6.3.3 of [RFC3550]), the value of "packet_size" MUST
-      include the size of the additional fields added by SRTCP.
-
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 18]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   With these measures in place the SRTCP messages will not use more
-   than the allotted bandwidth.  The effect of the size of the added
-   fields on the SRTCP traffic will be that messages will be sent with
-   longer packet intervals.  The increase in the intervals will be
-   directly proportional to size of the added fields.  For the pre-
-   defined transforms, the size of the added fields will be at least 14
-   octets, and upper bounded depending on MKI and the authentication tag
-   sizes.
-
-4.  Pre-Defined Cryptographic Transforms
-
-   While there are numerous encryption and message authentication
-   algorithms that can be used in SRTP, below we define default
-   algorithms in order to avoid the complexity of specifying the
-   encodings for the signaling of algorithm and parameter identifiers.
-   The defined algorithms have been chosen as they fulfill the goals
-   listed in Section 2.  Recommendations on how to extend SRTP with new
-   transforms are given in Section 6.
-
-4.1.  Encryption
-
-   The following parameters are common to both pre-defined, non-NULL,
-   encryption transforms specified in this section.
-
-   *  BLOCK_CIPHER-MODE indicates the block cipher used and its mode of
-      operation
-   *  n_b is the bit-size of the block for the block cipher
-   *  k_e is the session encryption key
-   *  n_e is the bit-length of k_e
-   *  k_s is the session salting key
-   *  n_s is the bit-length of k_s
-   *  SRTP_PREFIX_LENGTH is the octet length of the keystream prefix, a
-      non-negative integer, specified by the message authentication code
-      in use.
-
-   The distinct session keys and salts for SRTP/SRTCP are by default
-   derived as specified in Section 4.3.
-
-   The encryption transforms defined in SRTP map the SRTP packet index
-   and secret key into a pseudo-random keystream segment.  Each
-   keystream segment encrypts a single RTP packet.  The process of
-   encrypting a packet consists of generating the keystream segment
-   corresponding to the packet, and then bitwise exclusive-oring that
-   keystream segment onto the payload of the RTP packet to produce the
-   Encrypted Portion of the SRTP packet.  In case the payload size is
-   not an integer multiple of n_b bits, the excess (least significant)
-   bits of the keystream are simply discarded.  Decryption is done the
-   same way, but swapping the roles of the plaintext and ciphertext.
-
-
-
-Baugher, et al.             Standards Track                    [Page 19]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   +----+   +------------------+---------------------------------+
-   | KG |-->| Keystream Prefix |          Keystream Suffix       |---+
-   +----+   +------------------+---------------------------------+   |
-                                                                     |
-                               +---------------------------------+   v
-                               |     Payload of RTP Packet       |->(*)
-                               +---------------------------------+   |
-                                                                     |
-                               +---------------------------------+   |
-                               | Encrypted Portion of SRTP Packet|<--+
-                               +---------------------------------+
-
-   Figure 3: Default SRTP Encryption Processing.  Here KG denotes the
-   keystream generator, and (*) denotes bitwise exclusive-or.
-
-   The definition of how the keystream is generated, given the index,
-   depends on the cipher and its mode of operation.  Below, two such
-   keystream generators are defined.  The NULL cipher is also defined,
-   to be used when encryption of RTP is not required.
-
-   The SRTP definition of the keystream is illustrated in Figure 3.  The
-   initial octets of each keystream segment MAY be reserved for use in a
-   message authentication code, in which case the keystream used for
-   encryption starts immediately after the last reserved octet.  The
-   initial reserved octets are called the "keystream prefix" (not to be
-   confused with the "encryption prefix" of [RFC3550, Section 6.1]), and
-   the remaining octets are called the "keystream suffix".  The
-   keystream prefix MUST NOT be used for encryption.  The process is
-   illustrated in Figure 3.
-
-   The number of octets in the keystream prefix is denoted as
-   SRTP_PREFIX_LENGTH.  The keystream prefix is indicated by a positive,
-   non-zero value of SRTP_PREFIX_LENGTH.  This means that, even if
-   confidentiality is not to be provided, the keystream generator output
-   may still need to be computed for packet authentication, in which
-   case the default keystream generator (mode) SHALL be used.
-
-   The default cipher is the Advanced Encryption Standard (AES) [AES],
-   and we define two modes of running AES, (1) Segmented Integer Counter
-   Mode AES and (2) AES in f8-mode.  In the remainder of this section,
-   let E(k,x) be AES applied to key k and input block x.
-
-
-
-
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 20]
-
-RFC 3711                          SRTP                        March 2004
-
-
-4.1.1.  AES in Counter Mode
-
-   Conceptually, counter mode [AES-CTR] consists of encrypting
-   successive integers.  The actual definition is somewhat more
-   complicated, in order to randomize the starting point of the integer
-   sequence.  Each packet is encrypted with a distinct keystream
-   segment, which SHALL be computed as follows.
-
-   A keystream segment SHALL be the concatenation of the 128-bit output
-   blocks of the AES cipher in the encrypt direction, using key k = k_e,
-   in which the block indices are in increasing order.  Symbolically,
-   each keystream segment looks like
-
-      E(k, IV) || E(k, IV + 1 mod 2^128) || E(k, IV + 2 mod 2^128) ...
-
-   where the 128-bit integer value IV SHALL be defined by the SSRC, the
-   SRTP packet index i, and the SRTP session salting key k_s, as below.
-
-      IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16)
-
-   Each of the three terms in the XOR-sum above is padded with as many
-   leading zeros as needed to make the operation well-defined,
-   considered as a 128-bit value.
-
-   The inclusion of the SSRC allows the use of the same key to protect
-   distinct SRTP streams within the same RTP session, see the security
-   caveats in Section 9.1.
-
-   In the case of SRTCP, the SSRC of the first header of the compound
-   packet MUST be used, i SHALL be the 31-bit SRTCP index and k_e, k_s
-   SHALL be replaced by the SRTCP encryption session key and salt.
-
-   Note that the initial value, IV, is fixed for each packet and is
-   formed by "reserving" 16 zeros in the least significant bits for the
-   purpose of the counter.  The number of blocks of keystream generated
-   for any fixed value of IV MUST NOT exceed 2^16 to avoid keystream
-   re-use, see below.  The AES has a block size of 128 bits, so 2^16
-   output blocks are sufficient to generate the 2^23 bits of keystream
-   needed to encrypt the largest possible RTP packet (except for IPv6
-   "jumbograms" [RFC2675], which are not likely to be used for RTP-based
-   multimedia traffic).  This restriction on the maximum bit-size of the
-   packet that can be encrypted ensures the security of the encryption
-   method by limiting the effectiveness of probabilistic attacks [BDJR].
-
-   For a particular Counter Mode key, each IV value used as an input
-   MUST be distinct, in order to avoid the security exposure of a two-
-   time pad situation (Section 9.1).  To satisfy this constraint, an
-   implementation MUST ensure that the combination of the SRTP packet
-
-
-
-Baugher, et al.             Standards Track                    [Page 21]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   index of ROC || SEQ, and the SSRC used in the construction of the IV
-   are distinct for any particular key.  The failure to ensure this
-   uniqueness could be catastrophic for Secure RTP.  This is in contrast
-   to the situation for RTP itself, which may be able to tolerate such
-   failures.  It is RECOMMENDED that, if a dedicated security module is
-   present, the RTP sequence numbers and SSRC either be generated or
-   checked by that module (i.e., sequence-number and SSRC processing in
-   an SRTP system needs to be protected as well as the key).
-
-4.1.2.  AES in f8-mode
-
-   To encrypt UMTS (Universal Mobile Telecommunications System, as 3G
-   networks) data, a solution (see [f8-a] [f8-b]) known as the f8-
-   algorithm has been developed.  On a high level, the proposed scheme
-   is a variant of Output Feedback Mode (OFB) [HAC], with a more
-   elaborate initialization and feedback function.  As in normal OFB,
-   the core consists of a block cipher.  We also define here the use of
-   AES as a block cipher to be used in what we shall call "f8-mode of
-   operation" RTP encryption.  The AES f8-mode SHALL use the same
-   default sizes for session key and salt as AES counter mode.
-
-   Figure 4 shows the structure of block cipher, E, running in f8-mode.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 22]
-
-RFC 3711                          SRTP                        March 2004
-
-
-                    IV
-                    |
-                    v
-                +------+
-                |      |
-           +--->|  E   |
-           |    +------+
-           |        |
-     m -> (*)       +-----------+-------------+--  ...     ------+
-           |    IV' |           |             |                  |
-           |        |   j=1 -> (*)    j=2 -> (*)   ...  j=L-1 ->(*)
-           |        |           |             |                  |
-           |        |      +-> (*)       +-> (*)   ...      +-> (*)
-           |        |      |    |        |    |             |    |
-           |        v      |    v        |    v             |    v
-           |    +------+   | +------+    | +------+         | +------+
-    k_e ---+--->|  E   |   | |  E   |    | |  E   |         | |  E   |
-                |      |   | |      |    | |      |         | |      |
-                +------+   | +------+    | +------+         | +------+
-                    |      |    |        |    |             |    |
-                    +------+    +--------+    +--  ...  ----+    |
-                    |           |             |                  |
-                    v           v             v                  v
-                   S(0)        S(1)          S(2)  . . .       S(L-1)
-
-   Figure 4.  f8-mode of operation (asterisk, (*), denotes bitwise XOR).
-   The figure represents the KG in Figure 3, when AES-f8 is used.
-
-4.1.2.1.  f8 Keystream Generation
-
-   The Initialization Vector (IV) SHALL be determined as described in
-   Section 4.1.2.2 (and in Section 4.1.2.3 for SRTCP).
-
-   Let IV', S(j), and m denote n_b-bit blocks.  The keystream,
-   S(0) ||... || S(L-1), for an N-bit message SHALL be defined by
-   setting IV' = E(k_e XOR m, IV), and S(-1) = 00..0.  For
-   j = 0,1,..,L-1 where L = N/n_b (rounded up to nearest integer if it
-   is not already an integer) compute
-
-            S(j) = E(k_e, IV' XOR j XOR S(j-1))
-
-   Notice that the IV is not used directly.  Instead it is fed through E
-   under another key to produce an internal, "masked" value (denoted
-   IV') to prevent an attacker from gaining known input/output pairs.
-
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 23]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   The role of the internal counter, j, is to prevent short keystream
-   cycles.  The value of the key mask m SHALL be
-
-           m = k_s || 0x555..5,
-
-   i.e., the session salting key, appended by the binary pattern 0101..
-   to fill out the entire desired key size, n_e.
-
-   The sender SHOULD NOT generate more than 2^32 blocks, which is
-   sufficient to generate 2^39 bits of keystream.  Unlike counter mode,
-   there is no absolute threshold above (below) which f8 is guaranteed
-   to be insecure (secure).  The above bound has been chosen to limit,
-   with sufficient security margin, the probability of degenerative
-   behavior in the f8 keystream generation.
-
-4.1.2.2.  f8 SRTP IV Formation
-
-   The purpose of the following IV formation is to provide a feature
-   which we call implicit header authentication (IHA), see Section 9.5.
-
-   The SRTP IV for 128-bit block AES-f8 SHALL be formed in the following
-   way:
-
-        IV = 0x00 || M || PT || SEQ || TS || SSRC || ROC
-
-   M, PT, SEQ, TS, SSRC SHALL be taken from the RTP header; ROC is from
-   the cryptographic context.
-
-   The presence of the SSRC as part of the IV allows AES-f8 to be used
-   when a master key is shared between multiple streams within the same
-   RTP session, see Section 9.1.
-
-4.1.2.3.  f8 SRTCP IV Formation
-
-   The SRTCP IV for 128-bit block AES-f8 SHALL be formed in the
-   following way:
-
-   IV= 0..0 || E || SRTCP index || V || P || RC || PT || length || SSRC
-
-   where V, P, RC, PT, length, SSRC SHALL be taken from the first header
-   in the RTCP compound packet.  E and SRTCP index are the 1-bit and
-   31-bit fields added to the packet.
-
-
-
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 24]
-
-RFC 3711                          SRTP                        March 2004
-
-
-4.1.3.  NULL Cipher
-
-   The NULL cipher is used when no confidentiality for RTP/RTCP is
-   requested.  The keystream can be thought of as "000..0", i.e., the
-   encryption SHALL simply copy the plaintext input into the ciphertext
-   output.
-
-4.2.  Message Authentication and Integrity
-
-   Throughout this section, M will denote data to be integrity
-   protected.  In the case of SRTP, M SHALL consist of the Authenticated
-   Portion of the packet (as specified in Figure 1) concatenated with
-   the ROC, M = Authenticated Portion || ROC; in the case of SRTCP, M
-   SHALL consist of the Authenticated Portion (as specified in Figure 2)
-   only.
-
-   Common parameters:
-
-   *  AUTH_ALG is the authentication algorithm
-   *  k_a is the session message authentication key
-   *  n_a is the bit-length of the authentication key
-   *  n_tag is the bit-length of the output authentication tag
-   *  SRTP_PREFIX_LENGTH is the octet length of the keystream prefix as
-      defined above, a parameter of AUTH_ALG
-
-   The distinct session authentication keys for SRTP/SRTCP are by
-   default derived as specified in Section 4.3.
-
-   The values of n_a, n_tag, and SRTP_PREFIX_LENGTH MUST be fixed for
-   any particular fixed value of the key.
-
-   We describe the process of computing authentication tags as follows.
-   The sender computes the tag of M and appends it to the packet.  The
-   SRTP receiver verifies a message/authentication tag pair by computing
-   a new authentication tag over M using the selected algorithm and key,
-   and then compares it to the tag associated with the received message.
-   If the two tags are equal, then the message/tag pair is valid;
-   otherwise, it is invalid and the error audit message "AUTHENTICATION
-   FAILURE" MUST be returned.
-
-4.2.1.  HMAC-SHA1
-
-   The pre-defined authentication transform for SRTP is HMAC-SHA1
-   [RFC2104].  With HMAC-SHA1, the SRTP_PREFIX_LENGTH (Figure 3) SHALL
-   be 0.  For SRTP (respectively SRTCP), the HMAC SHALL be applied to
-   the session authentication key and M as specified above, i.e.,
-   HMAC(k_a, M).  The HMAC output SHALL then be truncated to the n_tag
-   left-most bits.
-
-
-
-Baugher, et al.             Standards Track                    [Page 25]
-
-RFC 3711                          SRTP                        March 2004
-
-
-4.3.  Key Derivation
-
-4.3.1.  Key Derivation Algorithm
-
-   Regardless of the encryption or message authentication transform that
-   is employed (it may be an SRTP pre-defined transform or newly
-   introduced according to Section 6), interoperable SRTP
-   implementations MUST use the SRTP key derivation to generate session
-   keys.  Once the key derivation rate is properly signaled at the start
-   of the session, there is no need for extra communication between the
-   parties that use SRTP key derivation.
-
-                         packet index ---+
-                                         |
-                                         v
-               +-----------+ master  +--------+ session encr_key
-               | ext       | key     |        |---------->
-               | key mgmt  |-------->|  key   | session auth_key
-               | (optional |         | deriv  |---------->
-               | rekey)    |-------->|        | session salt_key
-               |           | master  |        |---------->
-               +-----------+ salt    +--------+
-
-   Figure 5: SRTP key derivation.
-
-   At least one initial key derivation SHALL be performed by SRTP, i.e.,
-   the first key derivation is REQUIRED.  Further applications of the
-   key derivation MAY be performed, according to the
-   "key_derivation_rate" value in the cryptographic context.  The key
-   derivation function SHALL initially be invoked before the first
-   packet and then, when r > 0, a key derivation is performed whenever
-   index mod r equals zero.  This can be thought of as "refreshing" the
-   session keys.  The value of "key_derivation_rate" MUST be kept fixed
-   for the lifetime of the associated master key.
-
-   Interoperable SRTP implementations MAY also derive session salting
-   keys for encryption transforms, as is done in both of the pre-
-   defined transforms.
-
-   Let m and n be positive integers.  A pseudo-random function family is
-   a set of keyed functions {PRF_n(k,x)} such that for the (secret)
-   random key k, given m-bit x, PRF_n(k,x) is an n-bit string,
-   computationally indistinguishable from random n-bit strings, see
-   [HAC].  For the purpose of key derivation in SRTP, a secure PRF with
-   m = 128 (or more) MUST be used, and a default PRF transform is
-   defined in Section 4.3.3.
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 26]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   Let "a DIV t" denote integer division of a by t, rounded down, and
-   with the convention that "a DIV 0 = 0" for all a.  We also make the
-   convention of treating "a DIV t" as a bit string of the same length
-   as a, and thus "a DIV t" will in general have leading zeros.
-
-   Key derivation SHALL be defined as follows in terms of <label>, an
-   8-bit constant (see below), master_salt and key_derivation_rate, as
-   determined in the cryptographic context, and index, the packet index
-   (i.e., the 48-bit ROC || SEQ for SRTP):
-
-   *  Let r = index DIV key_derivation_rate (with DIV as defined above).
-
-   *  Let key_id = <label> || r.
-
-   *  Let x = key_id XOR master_salt, where key_id and master_salt are
-      aligned so that their least significant bits agree (right-
-      alignment).
-
-   <label> MUST be unique for each type of key to be derived.  We
-   currently define <label> 0x00 to 0x05 (see below), and future
-   extensions MAY specify new values in the range 0x06 to 0xff for other
-   purposes.  The n-bit SRTP key (or salt) for this packet SHALL then be
-   derived from the master key, k_master as follows:
-
-      PRF_n(k_master, x).
-
-   (The PRF may internally specify additional formatting and padding of
-   x, see e.g., Section 4.3.3 for the default PRF.)
-
-   The session keys and salt SHALL now be derived using:
-
-   - k_e (SRTP encryption): <label> = 0x00, n = n_e.
-
-   - k_a (SRTP message authentication): <label> = 0x01, n = n_a.
-
-   - k_s (SRTP salting key): <label> = 0x02, n = n_s.
-
-   where n_e, n_s, and n_a are from the cryptographic context.
-
-   The master key and master salt MUST be random, but the master salt
-   MAY be public.
-
-   Note that for a key_derivation_rate of 0, the application of the key
-   derivation SHALL take place exactly once.
-
-   The definition of DIV above is purely for notational convenience.
-   For a non-zero t among the set of allowed key derivation rates, "a
-   DIV t" can be implemented as a right-shift by the base-2 logarithm of
-
-
-
-Baugher, et al.             Standards Track                    [Page 27]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   t.  The derivation operation is further facilitated if the rates are
-   chosen to be powers of 256, but that granularity was considered too
-   coarse to be a requirement of this specification.
-
-   The upper limit on the number of packets that can be secured using
-   the same master key (see Section 9.2) is independent of the key
-   derivation.
-
-4.3.2.  SRTCP Key Derivation
-
-   SRTCP SHALL by default use the same master key (and master salt) as
-   SRTP.  To do this securely, the following changes SHALL be done to
-   the definitions in Section 4.3.1 when applying session key derivation
-   for SRTCP.
-
-   Replace the SRTP index by the 32-bit quantity: 0 || SRTCP index
-   (i.e., excluding the E-bit, replacing it with a fixed 0-bit), and use
-   <label> = 0x03 for the SRTCP encryption key, <label> = 0x04 for the
-   SRTCP authentication key, and, <label> = 0x05 for the SRTCP salting
-   key.
-
-4.3.3.  AES-CM PRF
-
-   The currently defined PRF, keyed by 128, 192, or 256 bit master key,
-   has input block size m = 128 and can produce n-bit outputs for n up
-   to 2^23.  PRF_n(k_master,x) SHALL be AES in Counter Mode as described
-   in Section 4.1.1, applied to key k_master, and IV equal to (x*2^16),
-   and with the output keystream truncated to the n first (left-most)
-   bits.  (Requiring n/128, rounded up, applications of AES.)
-
-5.  Default and mandatory-to-implement Transforms
-
-   The default transforms also are mandatory-to-implement transforms in
-   SRTP.  Of course, "mandatory-to-implement" does not imply
-   "mandatory-to-use".  Table 1 summarizes the pre-defined transforms.
-   The default values below are valid for the pre-defined transforms.
-
-                         mandatory-to-impl.   optional     default
-
-   encryption            AES-CM, NULL         AES-f8       AES-CM
-   message integrity     HMAC-SHA1              -          HMAC-SHA1
-   key derivation (PRF)  AES-CM                 -          AES-CM
-
-   Table 1: Mandatory-to-implement, optional and default transforms in
-   SRTP and SRTCP.
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 28]
-
-RFC 3711                          SRTP                        March 2004
-
-
-5.1.  Encryption: AES-CM and NULL
-
-   AES running in Segmented Integer Counter Mode, as defined in Section
-   4.1.1, SHALL be the default encryption algorithm.  The default key
-   lengths SHALL be 128-bit for the session encryption key (n_e).  The
-   default session salt key-length (n_s) SHALL be 112 bits.
-
-   The NULL cipher SHALL also be mandatory-to-implement.
-
-5.2.  Message Authentication/Integrity: HMAC-SHA1
-
-   HMAC-SHA1, as defined in Section 4.2.1, SHALL be the default message
-   authentication code.  The default session authentication key-length
-   (n_a) SHALL be 160 bits, the default authentication tag length
-   (n_tag) SHALL be 80 bits, and the SRTP_PREFIX_LENGTH SHALL be zero
-   for HMAC-SHA1.  In addition, for SRTCP, the pre-defined HMAC-SHA1
-   MUST NOT be applied with a value of n_tag, nor n_a, that are smaller
-   than these defaults.  For SRTP, smaller values are NOT RECOMMENDED,
-   but MAY be used after careful consideration of the issues in Section
-   7.5 and 9.5.
-
-5.3.  Key Derivation: AES-CM PRF
-
-   The AES Counter Mode based key derivation and PRF defined in Sections
-   4.3.1 to 4.3.3, using a 128-bit master key, SHALL be the default
-   method for generating session keys.  The default master salt length
-   SHALL be 112 bits and the default key-derivation rate SHALL be zero.
-
-6.  Adding SRTP Transforms
-
-   Section 4 provides examples of the level of detail needed for
-   defining transforms.  Whenever a new transform is to be added to
-   SRTP, a companion standard track RFC MUST be written to exactly
-   define how the new transform can be used with SRTP (and SRTCP).  Such
-   a companion RFC SHOULD avoid overlap with the SRTP protocol document.
-   Note however, that it MAY be necessary to extend the SRTP or SRTCP
-   cryptographic context definition with new parameters (including fixed
-   or default values), add steps to the packet processing, or even add
-   fields to the SRTP/SRTCP packets.  The companion RFC SHALL explain
-   any known issues regarding interactions between the transform and
-   other aspects of SRTP.
-
-   Each new transform document SHOULD specify its key attributes, e.g.,
-   size of keys (minimum, maximum, recommended), format of keys,
-   recommended/required processing of input keying material,
-   requirements/recommendations on key lifetime, re-keying and key
-   derivation, whether sharing of keys between SRTP and SRTCP is allowed
-   or not, etc.
-
-
-
-Baugher, et al.             Standards Track                    [Page 29]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   An added message integrity transform SHOULD define a minimum
-   acceptable key/tag size for SRTCP, equivalent in strength to the
-   minimum values as defined in Section 5.2.
-
-7.  Rationale
-
-   This section explains the rationale behind several important features
-   of SRTP.
-
-7.1.  Key derivation
-
-   Key derivation reduces the burden on the key establishment.  As many
-   as six different keys are needed per crypto context (SRTP and SRTCP
-   encryption keys and salts, SRTP and SRTCP authentication keys), but
-   these are derived from a single master key in a cryptographically
-   secure way.  Thus, the key management protocol needs to exchange only
-   one master key (plus master salt when required), and then SRTP itself
-   derives all the necessary session keys (via the first, mandatory
-   application of the key derivation function).
-
-   Multiple applications of the key derivation function are optional,
-   but will give security benefits when enabled.  They prevent an
-   attacker from obtaining large amounts of ciphertext produced by a
-   single fixed session key.  If the attacker was able to collect a
-   large amount of ciphertext for a certain session key, he might be
-   helped in mounting certain attacks.
-
-   Multiple applications of the key derivation function provide
-   backwards and forward security in the sense that a compromised
-   session key does not compromise other session keys derived from the
-   same master key.  This means that the attacker who is able to recover
-   a certain session key, is anyway not able to have access to messages
-   secured under previous and later session keys (derived from the same
-   master key).  (Note that, of course, a leaked master key reveals all
-   the session keys derived from it.)
-
-   Considerations arise with high-rate key refresh, especially in large
-   multicast settings, see Section 11.
-
-7.2.  Salting key
-
-   The master salt guarantees security against off-line key-collision
-   attacks on the key derivation that might otherwise reduce the
-   effective key size [MF00].
-
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 30]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   The derived session salting key used in the encryption, has been
-   introduced to protect against some attacks on additive stream
-   ciphers, see Section 9.2.  The explicit inclusion method of the salt
-   in the IV has been selected for ease of hardware implementation.
-
-7.3.  Message Integrity from Universal Hashing
-
-   The particular definition of the keystream given in Section 4.1 (the
-   keystream prefix) is to give provision for particular universal hash
-   functions, suitable for message authentication in the Wegman-Carter
-   paradigm [WC81].  Such functions are provably secure, simple, quick,
-   and especially appropriate for Digital Signal Processors and other
-   processors with a fast multiply operation.
-
-   No authentication transforms are currently provided in SRTP other
-   than HMAC-SHA1.  Future transforms, like the above mentioned
-   universal hash functions, MAY be added following the guidelines in
-   Section 6.
-
-7.4.  Data Origin Authentication Considerations
-
-   Note that in pair-wise communications, integrity and data origin
-   authentication are provided together.  However, in group scenarios
-   where the keys are shared between members, the MAC tag only proves
-   that a member of the group sent the packet, but does not prevent
-   against a member impersonating another.  Data origin authentication
-   (DOA) for multicast and group RTP sessions is a hard problem that
-   needs a solution; while some promising proposals are being
-   investigated [PCST1] [PCST2], more work is needed to rigorously
-   specify these technologies.  Thus SRTP data origin authentication in
-   groups is for further study.
-
-   DOA can be done otherwise using signatures.  However, this has high
-   impact in terms of bandwidth and processing time, therefore we do not
-   offer this form of authentication in the pre-defined packet-integrity
-   transform.
-
-   The presence of mixers and translators does not allow data origin
-   authentication in case the RTP payload and/or the RTP header are
-   manipulated.  Note that these types of middle entities also disrupt
-   end-to-end confidentiality (as the IV formation depends e.g., on the
-   RTP header preservation).  A certain trust model may choose to trust
-   the mixers/translators to decrypt/re-encrypt the media (this would
-   imply breaking the end-to-end security, with related security
-   implications).
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 31]
-
-RFC 3711                          SRTP                        March 2004
-
-
-7.5.  Short and Zero-length Message Authentication
-
-   As shown in Figure 1, the authentication tag is RECOMMENDED in SRTP.
-   A full 80-bit authentication-tag SHOULD be used, but a shorter tag or
-   even a zero-length tag (i.e., no message authentication) MAY be used
-   under certain conditions to support either of the following two
-   application environments.
-
-      1. Strong authentication can be impractical in environments where
-         bandwidth preservation is imperative.  An important special
-         case is wireless communication systems, in which bandwidth is a
-         scarce and expensive resource.  Studies have shown that for
-         certain applications and link technologies, additional bytes
-         may result in a significant decrease in spectrum efficiency
-         [SWO].  Considerable effort has been made to design IP header
-         compression techniques to improve spectrum efficiency
-         [RFC3095].  A typical voice application produces 20 byte
-         samples, and the RTP, UDP and IP headers need to be jointly
-         compressed to one or two bytes on average in order to obtain
-         acceptable wireless bandwidth economy [RFC3095].  In this case,
-         strong authentication would impose nearly fifty percent
-         overhead.
-
-      2. Authentication is impractical for applications that use data
-         links with fixed-width fields that cannot accommodate the
-         expansion due to the authentication tag.  This is the case for
-         some important existing wireless channels.  For example, zero-
-         byte header compression is used to adapt EVRC/SMV voice with
-         the legacy IS-95 bearer channel in CDMA2000 VoIP services.  It
-         was found that not a single additional octet could be added to
-         the data, which motivated the creation of a zero-byte profile
-         for ROHC [RFC3242].
-
-   A short tag is secure for a restricted set of applications.  Consider
-   a voice telephony application, for example, such as a G.729 audio
-   codec with a 20-millisecond packetization interval, protected by a
-   32-bit message authentication tag.  The likelihood of any given
-   packet being successfully forged is only one in 2^32.  Thus an
-   adversary can control no more than 20 milliseconds of audio output
-   during a 994-day period, on average.  In contrast, the effect of a
-   single forged packet can be much larger if the application is
-   stateful.  A codec that uses relative or predictive compression
-   across packets will propagate the maliciously generated state,
-   affecting a longer duration of output.
-
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 32]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   Certainly not all SRTP or telephony applications meet the criteria
-   for short or zero-length authentication tags.  Section 9.5.1
-   discusses the risks of weak or no message authentication, and section
-   9.5 describes the circumstances when it is acceptable and when it is
-   unacceptable.
-
-8.  Key Management Considerations
-
-   There are emerging key management standards [MIKEY] [KEYMGT] [SDMS]
-   for establishing an SRTP cryptographic context (e.g., an SRTP master
-   key).  Both proprietary and open-standard key management methods are
-   likely to be used for telephony applications [MIKEY] [KINK] and
-   multicast applications [GDOI].  This section provides guidance for
-   key management systems that service SRTP session.
-
-   For initialization, an interoperable SRTP implementation SHOULD be
-   given the SSRC and MAY be given the initial RTP sequence number for
-   the RTP stream by key management (thus, key management has a
-   dependency on RTP operational parameters).  Sending the RTP sequence
-   number in the key management may be useful e.g., when the initial
-   sequence number is close to wrapping (to avoid synchronization
-   problems), and to communicate the current sequence number to a
-   joining endpoint (to properly initialize its replay list).
-
-   If the pre-defined transforms are used, SRTP allows sharing of the
-   same master key between SRTP/SRTCP streams belonging to the same RTP
-   session.
-
-   First, sharing between SRTP streams belonging to the same RTP session
-   is secure if the design of the synchronization mechanism, i.e., the
-   IV, avoids keystream re-use (the two-time pad, Section 9.1).  This is
-   taken care of by the fact that RTP provides for unique SSRCs for
-   streams belonging to the same RTP session.  See Section 9.1 for
-   further discussion.
-
-   Second, sharing between SRTP and the corresponding SRTCP is secure.
-   The fact that an SRTP stream and its associated SRTCP stream both
-   carry the same SSRC does not constitute a problem for the two-time
-   pad due to the key derivation.  Thus, SRTP and SRTCP corresponding to
-   one RTP session MAY share master keys (as they do by default).
-
-   Note that message authentication also has a dependency on SSRC
-   uniqueness that is unrelated to the problem of keystream reuse: SRTP
-   streams authenticated under the same key MUST have a distinct SSRC in
-   order to identify the sender of the message.  This requirement is
-   needed because the SSRC is the cryptographically authenticated field
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 33]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   used to distinguish between different SRTP streams.  Were two streams
-   to use identical SSRC values, then an adversary could substitute
-   messages from one stream into the other without detection.
-
-   SRTP/SRTCP MUST NOT share master keys under any other circumstances
-   than the ones given above, i.e., between SRTP and its corresponding
-   SRTCP, and, between streams belonging to the same RTP session.
-
-8.1.  Re-keying
-
-   The recommended way for a particular key management system to provide
-   re-key within SRTP is by associating a master key in a crypto context
-   with an MKI.
-
-   This provides for easy master key retrieval (see Scenarios in Section
-   11), but has the disadvantage of adding extra bits to each packet.
-   As noted in Section 7.5, some wireless links do not cater for added
-   bits, therefore SRTP also defines a more economic way of triggering
-   re-keying, via use of <From, To>, which works in some specific,
-   simple scenarios (see Section 8.1.1).
-
-   SRTP senders SHALL count the amount of SRTP and SRTCP traffic being
-   used for a master key and invoke key management to re-key if needed
-   (Section 9.2).  These interactions are defined by the key management
-   interface to SRTP and are not defined by this protocol specification.
-
-8.1.1.  Use of the <From, To> for re-keying
-
-   In addition to the use of the MKI, SRTP defines another optional
-   mechanism for master key retrieval, the <From, To>.  The <From, To>
-   specifies the range of SRTP indices (a pair of sequence number and
-   ROC) within which a certain master key is valid, and is (when used)
-   part of the crypto context.  By looking at the 48-bit SRTP index of
-   the current SRTP packet, the corresponding master key can be found by
-   determining which From-To interval it belongs to.  For SRTCP, the
-   most recently observed/used SRTP index (which can be obtained from
-   the cryptographic context) is used for this purpose, even though
-   SRTCP has its own (31-bit) index (see caveat below).
-
-   This method, compared to the MKI, has the advantage of identifying
-   the master key and defining its lifetime without adding extra bits to
-   each packet.  This could be useful, as already noted, for some
-   wireless links that do not cater for added bits.  However, its use
-   SHOULD be limited to specific, very simple scenarios.  We recommend
-   to limit its use when the RTP session is a simple unidirectional or
-   bi-directional stream.  This is because in case of multiple streams,
-   it is difficult to trigger the re-key based on the <From, To> of a
-   single RTP stream. For example, if several streams share a master
-
-
-
-Baugher, et al.             Standards Track                    [Page 34]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   key, there is no simple one-to-one correspondence between the index
-   sequence space of a certain stream, and the index sequence space on
-   which the <From, To> values are based.  Consequently, when a master
-   key is shared between streams, one of these streams MUST be
-   designated by key management as the one whose index space defines the
-   re-keying points.  Also, the re-key triggering on SRTCP is based on
-   the correspondent SRTP stream, i.e., when the SRTP stream changes the
-   master key, so does the correspondent SRTCP.  This becomes obviously
-   more and more complex with multiple streams.
-
-   The default values for the <From, To> are "from the first observed
-   packet" and "until further notice".  However, the maximum limit of
-   SRTP/SRTCP packets that are sent under each given master/session key
-   (Section 9.2) MUST NOT be exceeded.
-
-   In case the <From, To> is used as key retrieval, then the MKI is not
-   inserted in the packet (and its indicator in the crypto context is
-   zero).  However, using the MKI does not exclude using <From, To> key
-   lifetime simultaneously.  This can for instance be useful to signal
-   at the sender side at which point in time an MKI is to be made
-   active.
-
-8.2.  Key Management parameters
-
-   The table below lists all SRTP parameters that key management can
-   supply.  For reference, it also provides a summary of the default and
-   mandatory-to-support values for an SRTP implementation as described
-   in Section 5.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 35]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   Parameter                     Mandatory-to-support    Default
-   ---------                     --------------------    -------
-
-   SRTP and SRTCP encr transf.       AES_CM, NULL         AES_CM
-   (Other possible values: AES_f8)
-
-   SRTP and SRTCP auth transf.       HMAC-SHA1           HMAC-SHA1
-
-   SRTP and SRTCP auth params:
-     n_tag (tag length)                 80                 80
-     SRTP prefix_length                  0                  0
-
-   Key derivation PRF                 AES_CM              AES_CM
-
-   Key material params
-   (for each master key):
-     master key length                 128                128
-     n_e (encr session key length)     128                128
-     n_a (auth session key length)     160                160
-     master salt key
-     length of the master salt         112                112
-     n_s (session salt key length)     112                112
-     key derivation rate                 0                  0
-
-     key lifetime
-        SRTP-packets-max-lifetime      2^48               2^48
-        SRTCP-packets-max-lifetime     2^31               2^31
-        from-to-lifetime <From, To>
-     MKI indicator                       0                 0
-     length of the MKI                   0                 0
-     value of the MKI
-
-   Crypto context index params:
-     SSRC value
-     ROC
-     SEQ
-     SRTCP Index
-     Transport address
-     Port number
-
-   Relation to other RTP profiles:
-     sender's order between FEC and SRTP FEC-SRTP      FEC-SRTP
-     (see Section 10)
-
-
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 36]
-
-RFC 3711                          SRTP                        March 2004
-
-
-9. Security Considerations
-
-9.1.  SSRC collision and two-time pad
-
-   Any fixed keystream output, generated from the same key and index
-   MUST only be used to encrypt once.  Re-using such keystream (jokingly
-   called a "two-time pad" system by cryptographers), can seriously
-   compromise security.  The NSA's VENONA project [C99] provides a
-   historical example of such a compromise.  It is REQUIRED that
-   automatic key management be used for establishing and maintaining
-   SRTP and SRTCP keying material; this requirement is to avoid
-   keystream reuse, which is more likely to occur with manual key
-   management.  Furthermore, in SRTP, a "two-time pad" is avoided by
-   requiring the key, or some other parameter of cryptographic
-   significance, to be unique per RTP/RTCP stream and packet.  The pre-
-   defined SRTP transforms accomplish packet-uniqueness by including the
-   packet index and stream-uniqueness by inclusion of the SSRC.
-
-   The pre-defined transforms (AES-CM and AES-f8) allow master keys to
-   be shared across streams belonging to the same RTP session by the
-   inclusion of the SSRC in the IV.  A master key MUST NOT be shared
-   among different RTP sessions.
-
-   Thus, the SSRC MUST be unique between all the RTP streams within the
-   same RTP session that share the same master key.  RTP itself provides
-   an algorithm for detecting SSRC collisions within the same RTP
-   session.  Thus, temporary collisions could lead to temporary two-time
-   pad, in the unfortunate event that SSRCs collide at a point in time
-   when the streams also have identical sequence numbers (occurring with
-   probability roughly 2^(-48)).  Therefore, the key management SHOULD
-   take care of avoiding such SSRC collisions by including the SSRCs to
-   be used in the session as negotiation parameters, proactively
-   assuring their uniqueness.  This is a strong requirements in
-   scenarios where for example, there are multiple senders that can
-   start to transmit simultaneously, before SSRC collision are detected
-   at the RTP level.
-
-   Note also that even with distinct SSRCs, extensive use of the same
-   key might improve chances of probabilistic collision and time-
-   memory-tradeoff attacks succeeding.
-
-   As described, master keys MAY be shared between streams belonging to
-   the same RTP session, but it is RECOMMENDED that each SSRC have its
-   own master key.  When master keys are shared among SSRC participants
-   and SSRCs are managed by a key management module as recommended
-   above, the RECOMMENDED policy for an SSRC collision error is for the
-   participant to leave the SRTP session as it is a sign of malfunction.
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 37]
-
-RFC 3711                          SRTP                        March 2004
-
-
-9.2.  Key Usage
-
-   The effective key size is determined (upper bounded) by the size of
-   the master key and, for encryption, the size of the salting key.  Any
-   additive stream cipher is vulnerable to attacks that use statistical
-   knowledge about the plaintext source to enable key collision and
-   time-memory tradeoff attacks [MF00] [H80] [BS00].  These attacks take
-   advantage of commonalities among plaintexts, and provide a way for a
-   cryptanalyst to amortize the computational effort of decryption over
-   many keys, or over many bytes of output, thus reducing the effective
-   key size of the cipher.  A detailed analysis of these attacks and
-   their applicability to the encryption of Internet traffic is provided
-   in [MF00].  In summary, the effective key size of SRTP when used in a
-   security system in which m distinct keys are used, is equal to the
-   key size of the cipher less the logarithm (base two) of m.
-   Protection against such attacks can be provided simply by increasing
-   the size of the keys used, which here can be accomplished by the use
-   of the salting key.  Note that the salting key MUST be random but MAY
-   be public.  A salt size of (the suggested) size 112 bits protects
-   against attacks in scenarios where at most 2^112 keys are in use.
-   This is sufficient for all practical purposes.
-
-   Implementations SHOULD use keys that are as large as possible.
-   Please note that in many cases increasing the key size of a cipher
-   does not affect the throughput of that cipher.
-
-   The use of the SRTP and SRTCP indices in the pre-defined transforms
-   fixes the maximum number of packets that can be secured with the same
-   key.  This limit is fixed to 2^48 SRTP packets for an SRTP stream,
-   and 2^31 SRTCP packets, when SRTP and SRTCP are considered
-   independently.  Due to for example re-keying, reaching this limit may
-   or may not coincide with wrapping of the indices, and thus the sender
-   MUST keep packet counts.  However, when the session keys for related
-   SRTP and SRTCP streams are derived from the same master key (the
-   default behavior, Section 4.3), the upper bound that has to be
-   considered is in practice the minimum of the two quantities.  That
-   is, when 2^48 SRTP packets or 2^31 SRTCP packets have been secured
-   with the same key (whichever occurs before), the key management MUST
-   be called to provide new master key(s) (previously stored and used
-   keys MUST NOT be used again), or the session MUST be terminated.  If
-   a sender of RTCP discovers that the sender of SRTP (or SRTCP) has not
-   updated the master or session key prior to sending 2^48 SRTP (or 2^31
-   SRTCP) packets belonging to the same SRTP (SRTCP) stream, it is up to
-   the security policy of the RTCP sender how to behave, e.g., whether
-   an RTCP BYE-packet should be sent and/or if the event should be
-   logged.
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 38]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   Note: in most typical applications (assuming at least one RTCP packet
-   for every 128,000 RTP packets), it will be the SRTCP index that first
-   reaches the upper limit, although the time until this occurs is very
-   long: even at 200 SRTCP packets/sec, the 2^31 index space of SRTCP is
-   enough to secure approximately 4 months of communication.
-
-   Note that if the master key is to be shared between SRTP streams
-   within the same RTP session (Section 9.1), although the above bounds
-   are on a per stream (i.e., per SSRC) basis, the sender MUST base re-
-   key decision on the stream whose sequence number space is the first
-   to be exhausted.
-
-   Key derivation limits the amount of plaintext that is encrypted with
-   a fixed session key, and made available to an attacker for analysis,
-   but key derivation does not extend the master key's lifetime.  To see
-   this, simply consider our requirements to avoid two-time pad:  two
-   distinct packets MUST either be processed with distinct IVs, or with
-   distinct session keys, and both the distinctness of IV and of the
-   session keys are (for the pre-defined transforms) dependent on the
-   distinctness of the packet indices.
-
-   Note that with the key derivation, the effective key size is at most
-   that of the master key, even if the derived session key is
-   considerably longer.  With the pre-defined authentication transform,
-   the session authentication key is 160 bits, but the master key by
-   default is only 128 bits.  This design choice was made to comply with
-   certain recommendations in [RFC2104] so that an existing HMAC
-   implementation can be plugged into SRTP without problems.  Since the
-   default tag size is 80 bits, it is, for the applications in mind,
-   also considered acceptable from security point of view.  Users having
-   concerns about this are RECOMMENDED to instead use a 192 bit master
-   key in the key derivation.  It was, however, chosen not to mandate
-   192-bit keys since existing AES implementations to be used in the
-   key-derivation may not always support key-lengths other than 128
-   bits.  Since AES is not defined (or properly analyzed) for use with
-   160 bit keys it is NOT RECOMMENDED that ad-hoc key-padding schemes
-   are used to pad shorter keys to 192 or 256 bits.
-
-9.3.  Confidentiality of the RTP Payload
-
-   SRTP's pre-defined ciphers are "seekable" stream ciphers, i.e.,
-   ciphers able to efficiently seek to arbitrary locations in their
-   keystream (so that the encryption or decryption of one packet does
-   not depend on preceding packets).  By using seekable stream ciphers,
-   SRTP avoids the denial of service attacks that are possible on stream
-   ciphers that lack this property.  It is important to be aware that,
-   as with any stream cipher, the exact length of the payload is
-   revealed by the encryption.  This means that it may be possible to
-
-
-
-Baugher, et al.             Standards Track                    [Page 39]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   deduce certain "formatting bits" of the payload, as the length of the
-   codec output might vary due to certain parameter settings etc.  This,
-   in turn, implies that the corresponding bit of the keystream can be
-   deduced.  However, if the stream cipher is secure (counter mode and
-   f8 are provably secure under certain assumptions [BDJR] [KSYH] [IK]),
-   knowledge of a few bits of the keystream will not aid an attacker in
-   predicting subsequent keystream bits.  Thus, the payload length (and
-   information deducible from this) will leak, but nothing else.
-
-   As some RTP packet could contain highly predictable data, e.g., SID,
-   it is important to use a cipher designed to resist known plaintext
-   attacks (which is the current practice).
-
-9.4.  Confidentiality of the RTP Header
-
-   In SRTP, RTP headers are sent in the clear to allow for header
-   compression.  This means that data such as payload type,
-   synchronization source identifier, and timestamp are available to an
-   eavesdropper.  Moreover, since RTP allows for future extensions of
-   headers, we cannot foresee what kind of possibly sensitive
-   information might also be "leaked".
-
-   SRTP is a low-cost method, which allows header compression to reduce
-   bandwidth.  It is up to the endpoints' policies to decide about the
-   security protocol to employ.  If one really needs to protect headers,
-   and is allowed to do so by the surrounding environment, then one
-   should also look at alternatives, e.g., IPsec [RFC2401].
-
-9.5.  Integrity of the RTP payload and header
-
-   SRTP messages are subject to attacks on their integrity and source
-   identification, and these risks are discussed in Section 9.5.1.  To
-   protect against these attacks, each SRTP stream SHOULD be protected
-   by HMAC-SHA1 [RFC2104] with an 80-bit output tag and a 160-bit key,
-   or a message authentication code with equivalent strength.  Secure
-   RTP SHOULD NOT be used without message authentication, except under
-   the circumstances described in this section.  It is important to note
-   that encryption algorithms, including AES Counter Mode and f8, do not
-   provide message authentication.  SRTCP MUST NOT be used with weak (or
-   NULL) authentication.
-
-   SRTP MAY be used with weak authentication (e.g., a 32-bit
-   authentication tag), or with no authentication (the NULL
-   authentication algorithm).  These options allow SRTP to be used to
-   provide confidentiality in situations where
-
-    * weak or null authentication is an acceptable security risk, and
-    * it is impractical to provide strong message authentication.
-
-
-
-Baugher, et al.             Standards Track                    [Page 40]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   These conditions are described below and in Section 7.5.  Note that
-   both conditions MUST hold in order for weak or null authentication to
-   be used.  The risks associated with exercising the weak or null
-   authentication options need to be considered by a security audit
-   prior to their use for a particular application or environment given
-   the risks, which are discussed in Section 9.5.1.
-
-   Weak authentication is acceptable when the RTP application is such
-   that the effect of a small fraction of successful forgeries is
-   negligible.  If the application is stateless, then the effect of a
-   single forged RTP packet is limited to the decoding of that
-   particular packet.  Under this condition, the size of the
-   authentication tag MUST ensure that only a negligible fraction of the
-   packets passed to the RTP application by the SRTP receiver can be
-   forgeries.  This fraction is negligible when an adversary, if given
-   control of the forged packets, is not able to make a significant
-   impact on the output of the RTP application (see the example of
-   Section 7.5).
-
-   Weak or null authentication MAY be acceptable when it is unlikely
-   that an adversary can modify ciphertext so that it decrypts to an
-   intelligible value.  One important case is when it is difficult for
-   an adversary to acquire the RTP plaintext data, since for many
-   codecs, an adversary that does not know the input signal cannot
-   manipulate the output signal in a controlled way.  In many cases it
-   may be difficult for the adversary to determine the actual value of
-   the plaintext.  For example, a hidden snooping device might be
-   required in order to know a live audio or video signal.  The
-   adversary's signal must have a quality equivalent to or greater than
-   that of the signal under attack, since otherwise the adversary would
-   not have enough information to encode that signal with the codec used
-   by the victim.  Plaintext prediction may also be especially difficult
-   for an interactive application such as a telephone call.
-
-   Weak or null authentication MUST NOT be used when the RTP application
-   makes data forwarding or access control decisions based on the RTP
-   data.  In such a case, an attacker may be able to subvert
-   confidentiality by causing the receiver to forward data to an
-   attacker.  See Section 3 of [B96] for a real-life example of such
-   attacks.
-
-   Null authentication MUST NOT be used when a replay attack, in which
-   an adversary stores packets then replays them later in the session,
-   could have a non-negligible impact on the receiver.  An example of a
-   successful replay attack is the storing of the output of a
-   surveillance camera for a period of time, later followed by the
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 41]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   injection of that output to the monitoring station to avoid
-   surveillance.  Encryption does not protect against this attack, and
-   non-null authentication is REQUIRED in order to defeat it.
-
-   If existential message forgery is an issue, i.e., when the accuracy
-   of the received data is of non-negligible importance, null
-   authentication MUST NOT be used.
-
-9.5.1.  Risks of Weak or Null Message Authentication
-
-   During a security audit considering the use of weak or null
-   authentication, it is important to keep in mind the following attacks
-   which are possible when no message authentication algorithm is used.
-
-   An attacker who cannot predict the plaintext is still always able to
-   modify the message sent between the sender and the receiver so that
-   it decrypts to a random plaintext value, or to send a stream of bogus
-   packets to the receiver that will decrypt to random plaintext values.
-   This attack is essentially a denial of service attack, though in the
-   absence of message authentication, the RTP application will have
-   inputs that are bit-wise correlated with the true value.  Some
-   multimedia codecs and common operating systems will crash when such
-   data are accepted as valid video data.  This denial of service attack
-   may be a much larger threat than that due to an attacker dropping,
-   delaying, or re-ordering packets.
-
-   An attacker who cannot predict the plaintext can still replay a
-   previous message with certainty that the receiver will accept it.
-   Applications with stateless codecs might be robust against this type
-   of attack, but for other, more complex applications these attacks may
-   be far more grave.
-
-   An attacker who can predict the plaintext can modify the ciphertext
-   so that it will decrypt to any value of her choosing.  With an
-   additive stream cipher, an attacker will always be able to change
-   individual bits.
-
-   An attacker may be able to subvert confidentiality due to the lack of
-   authentication when a data forwarding or access control decision is
-   made on decrypted but unauthenticated plaintext.  This is because the
-   receiver may be fooled into forwarding data to an attacker, leading
-   to an indirect breach of confidentiality (see Section 3 of [B96]).
-   This is because data-forwarding decisions are made on the decrypted
-   plaintext; information in the plaintext will determine to what subnet
-   (or process) the plaintext is forwarded in ESP [RFC2401] tunnel mode
-   (respectively, transport mode).  When Secure RTP is used without
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 42]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   message authentication, it should be verified that the application
-   does not make data forwarding or access control decisions based on
-   the decrypted plaintext.
-
-   Some cipher modes of operation that require padding, e.g., standard
-   cipher block chaining (CBC) are very sensitive to attacks on
-   confidentiality if certain padding types are used in the absence of
-   integrity.  The attack [V02] shows that this is indeed the case for
-   the standard RTP padding as discussed in reference to Figure 1, when
-   used together with CBC mode.  Later transform additions to SRTP MUST
-   therefore carefully consider the risk of using this padding without
-   proper integrity protection.
-
-9.5.2.  Implicit Header Authentication
-
-   The IV formation of the f8-mode gives implicit authentication (IHA)
-   of the RTP header, even when message authentication is not used.
-   When IHA is used, an attacker that modifies the value of the RTP
-   header will cause the decryption process at the receiver to produce
-   random plaintext values.  While this protection is not equivalent to
-   message authentication, it may be useful for some applications.
-
-10.  Interaction with Forward Error Correction mechanisms
-
-   The default processing when using Forward Error Correction (e.g., RFC
-   2733) processing with SRTP SHALL be to perform FEC processing prior
-   to SRTP processing on the sender side and to perform SRTP processing
-   prior to FEC processing on the receiver side.  Any change to this
-   ordering (reversing it, or, placing FEC between SRTP encryption and
-   SRTP authentication) SHALL be signaled out of band.
-
-11.  Scenarios
-
-   SRTP can be used as security protocol for the RTP/RTCP traffic in
-   many different scenarios.  SRTP has a number of configuration
-   options, in particular regarding key usage, and can have impact on
-   the total performance of the application according to the way it is
-   used.  Hence, the use of SRTP is dependent on the kind of scenario
-   and application it is used with.  In the following, we briefly
-   illustrate some use cases for SRTP, and give some guidelines for
-   recommended setting of its options.
-
-11.1.  Unicast
-
-   A typical example would be a voice call or video-on-demand
-   application.
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 43]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   Consider one bi-directional RTP stream, as one RTP session.  It is
-   possible for the two parties to share the same master key in the two
-   directions according to the principles of Section 9.1.  The first
-   round of the key derivation splits the master key into any or all of
-   the following session keys (according to the provided security
-   functions):
-
-   SRTP_encr_key, SRTP_auth_key, SRTCP_encr_key, and SRTCP_auth key.
-
-   (For simplicity, we omit discussion of the salts, which are also
-   derived.)  In this scenario, it will in most cases suffice to have a
-   single master key with the default lifetime.  This guarantees
-   sufficiently long lifetime of the keys and a minimum set of keys in
-   place for most practical purposes.  Also, in this case RTCP
-   protection can be applied smoothly.  Under these assumptions, use of
-   the MKI can be omitted.  As the key-derivation in combination with
-   large difference in the packet rate in the respective directions may
-   require simultaneous storage of several session keys, if storage is
-   an issue, we recommended to use low-rate key derivation.
-
-   The same considerations can be extended to the unicast scenario with
-   multiple RTP sessions, where each session would have a distinct
-   master key.
-
-11.2.  Multicast (one sender)
-
-   Just as with (unprotected) RTP, a scalability issue arises in big
-   groups due to the possibly very large amount of SRTCP Receiver
-   Reports that the sender might need to process.  In SRTP, the sender
-   may have to keep state (the cryptographic context) for each receiver,
-   or more precisely, for the SRTCP used to protect Receiver Reports.
-   The overhead increases proportionally to the size of the group.  In
-   particular, re-keying requires special concern, see below.
-
-   Consider first a small group of receivers.  There are a few possible
-   setups with the distribution of master keys among the receivers.
-   Given a single RTP session, one possibility is that the receivers
-   share the same master key as per Section 9.1 to secure all their
-   respective RTCP traffic.  This shared master key could then be the
-   same one used by the sender to protect its outbound SRTP traffic.
-   Alternatively, it could be a master key shared only among the
-   receivers and used solely for their SRTCP traffic.  Both alternatives
-   require the receivers to trust each other.
-
-   Considering SRTCP and key storage, it is recommended to use low-rate
-   (or zero) key_derivation (except the mandatory initial one), so that
-   the sender does not need to store too many session keys (each SRTCP
-   stream might otherwise have a different session key at a given point
-
-
-
-Baugher, et al.             Standards Track                    [Page 44]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   in time, as the SRTCP sources send at different times).  Thus, in
-   case key derivation is wanted for SRTP, the cryptographic context for
-   SRTP can be kept separate from the SRTCP crypto context, so that it
-   is possible to have a key_derivation_rate of 0 for SRTCP and a non-
-   zero value for SRTP.
-
-   Use of the MKI for re-keying is RECOMMENDED for most applications
-   (see Section 8.1).
-
-   If there are more than one SRTP/SRTCP stream (within the same RTP
-   session) that share the master key, the upper limit of 2^48 SRTP
-   packets / 2^31 SRTCP packets means that, before one of the streams
-   reaches its maximum number of packets, re-keying MUST be triggered on
-   ALL streams sharing the master key.  (From strict security point of
-   view, only the stream reaching the maximum would need to be re-keyed,
-   but then the streams would no longer be sharing master key, which is
-   the intention.)  A local policy at the sender side should force
-   rekeying in a way that the maximum packet limit is not reached on any
-   of the streams.  Use of the MKI for re-keying is RECOMMENDED.
-
-   In large multicast with one sender, the same considerations as for
-   the small group multicast hold.  The biggest issue in this scenario
-   is the additional load placed at the sender side, due to the state
-   (cryptographic contexts) that has to be maintained for each receiver,
-   sending back RTCP Receiver Reports.  At minimum, a replay window
-   might need to be maintained for each RTCP source.
-
-11.3.  Re-keying and access control
-
-   Re-keying may occur due to access control (e.g., when a member is
-   removed during a multicast RTP session), or for pure cryptographic
-   reasons (e.g., the key is at the end of its lifetime).  When using
-   SRTP default transforms, the master key MUST be replaced before any
-   of the index spaces are exhausted for any of the streams protected by
-   one and the same master key.
-
-   How key management re-keys SRTP implementations is out of scope, but
-   it is clear that there are straightforward ways to manage keys for a
-   multicast group.  In one-sender multicast, for example, it is
-   typically the responsibility of the sender to determine when a new
-   key is needed.  The sender is the one entity that can keep track of
-   when the maximum number of packets has been sent, as receivers may
-   join and leave the session at any time, there may be packet loss and
-   delay etc.  In scenarios other than one-sender multicast, other
-   methods can be used.  Here, one must take into consideration that key
-   exchange can be a costly operation, taking several seconds for a
-   single exchange.  Hence, some time before the master key is
-   exhausted/expires, out-of-band key management is initiated, resulting
-
-
-
-Baugher, et al.             Standards Track                    [Page 45]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   in a new master key that is shared with the receiver(s).  In any
-   event, to maintain synchronization when switching to the new key,
-   group policy might choose between using the MKI and the <From, To>,
-   as described in Section 8.1.
-
-   For access control purposes, the <From, To> periods are set at the
-   desired granularity, dependent on the packet rate.  High rate re-
-   keying can be problematic for SRTCP in some large-group scenarios.
-   As mentioned, there are potential problems in using the SRTP index,
-   rather than the SRTCP index, for determining the master key.  In
-   particular, for short periods during switching of master keys, it may
-   be the case that SRTCP packets are not under the current master key
-   of the correspondent SRTP.  Therefore, using the MKI for re-keying in
-   such scenarios will produce better results.
-
-11.4.  Summary of basic scenarios
-
-   The description of these scenarios highlights some recommendations on
-   the use of SRTP, mainly related to re-keying and large scale
-   multicast:
-
-   - Do not use fast re-keying with the <From, To> feature.  It may, in
-     particular, give problems in retrieving the correct SRTCP key, if
-     an SRTCP packet arrives close to the re-keying time.  The MKI
-     SHOULD be used in this case.
-
-   - If multiple SRTP streams in the same RTP session share the same
-     master key, also moderate rate re-keying MAY have the same
-     problems, and the MKI SHOULD be used.
-
-   - Though offering increased security, a non-zero key_derivation_rate
-     is NOT RECOMMENDED when trying to minimize the number of keys in
-     use with multiple streams.
-
-12.  IANA Considerations
-
-   The RTP specification establishes a registry of profile names for use
-   by higher-level control protocols, such as the Session Description
-   Protocol (SDP), to refer to transport methods.  This profile
-   registers the name "RTP/SAVP".
-
-   SRTP uses cryptographic transforms which a key management protocol
-   signals.  It is the task of each particular key management protocol
-   to register the cryptographic transforms or suites of transforms with
-   IANA.  The key management protocol conveys these protocol numbers,
-   not SRTP, and each key management protocol chooses the numbering
-   scheme and syntax that it requires.
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 46]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   Specification of a key management protocol for SRTP is out of scope
-   here.  Section 8.2, however, provides guidance on the parameters that
-   need to be defined for the default and mandatory transforms.
-
-13.  Acknowledgements
-
-   David Oran (Cisco) and Rolf Blom (Ericsson) are co-authors of this
-   document but their valuable contributions are acknowledged here to
-   keep the length of the author list down.
-
-   The authors would in addition like to thank Magnus Westerlund, Brian
-   Weis, Ghyslain Pelletier, Morgan Lindqvist, Robert Fairlie-
-   Cuninghame, Adrian Perrig, the AVT WG and in particular the chairmen
-   Colin Perkins and Stephen Casner, the Transport and Security Area
-   Directors, and Eric Rescorla for their reviews and support.
-
-14.  References
-
-14.1.  Normative References
-
-   [AES]     NIST, "Advanced Encryption Standard (AES)", FIPS PUB 197,
-             http://www.nist.gov/aes/
-
-   [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
-             Hashing for Message Authentication", RFC 2104, February
-             1997.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
-             Internet Protocol", RFC 2401, November 1998.
-
-   [RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828,
-             May 2000.
-
-   [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
-             "RTP: A Transport Protocol for Real-time Applications", RFC
-             3550, July 2003.
-
-   [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
-             Video Conferences with Minimal Control",  RFC 3551, July
-             2003.
-
-
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 47]
-
-RFC 3711                          SRTP                        March 2004
-
-
-14.2.  Informative References
-
-   [AES-CTR] Lipmaa, H., Rogaway, P. and D. Wagner, "CTR-Mode
-             Encryption", NIST, http://csrc.nist.gov/encryption/modes/
-             workshop1/papers/lipmaa-ctr.pdf
-
-   [B96]     Bellovin, S., "Problem Areas for the IP Security
-             Protocols," in Proceedings of the Sixth Usenix Unix
-             Security Symposium, pp. 1-16, San Jose, CA, July 1996
-             (http://www.research.att.com/~smb/papers/index.html).
-
-   [BDJR]    Bellare, M., Desai, A., Jokipii, E. and P. Rogaway, "A
-             Concrete Treatment of Symmetric Encryption: Analysis of DES
-             Modes of Operation", Proceedings 38th IEEE FOCS, pp. 394-
-             403, 1997.
-
-   [BS00]    Biryukov, A. and A. Shamir, "Cryptanalytic Time/Memory/Data
-             Tradeoffs for Stream Ciphers", Proceedings, ASIACRYPT 2000,
-             LNCS 1976, pp. 1-13, Springer Verlag.
-
-   [C99]     Crowell, W. P., "Introduction to the VENONA Project",
-             http://www.nsa.gov:8080/docs/venona/index.html.
-
-   [CTR]     Dworkin, M., NIST Special Publication 800-38A,
-             "Recommendation for Block Cipher Modes of Operation:
-             Methods and Techniques", 2001.
-             http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-
-             38a.pdf.
-
-   [f8-a]    3GPP TS 35.201 V4.1.0 (2001-12) Technical Specification 3rd
-             Generation Partnership Project; Technical Specification
-             Group Services and System Aspects; 3G Security;
-             Specification of the 3GPP Confidentiality and Integrity
-             Algorithms; Document 1: f8 and f9 Specification (Release
-             4).
-
-   [f8-b]    3GPP TR 33.908 V4.0.0 (2001-09) Technical Report 3rd
-             Generation Partnership Project; Technical Specification
-             Group Services and System Aspects; 3G Security; General
-             Report on the Design, Specification and Evaluation of 3GPP
-             Standard Confidentiality and Integrity Algorithms (Release
-             4).
-
-   [GDOI]    Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The
-             Group Domain of Interpretation, RFC 3547, July 2003.
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 48]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   [HAC]     Menezes, A., Van Oorschot, P. and  S. Vanstone, "Handbook
-             of Applied Cryptography", CRC Press, 1997, ISBN 0-8493-
-             8523-7.
-
-   [H80]     Hellman, M. E., "A cryptanalytic time-memory trade-off",
-             IEEE Transactions on Information Theory, July 1980, pp.
-             401-406.
-
-   [IK]      T. Iwata and T. Kohno: "New Security Proofs for the 3GPP
-             Confidentiality and Integrity Algorithms", Proceedings of
-             FSE 2004.
-
-   [KINK]    Thomas, M. and J. Vilhuber, "Kerberized Internet
-             Negotiation of Keys (KINK)", Work in Progress.
-
-   [KEYMGT]  Arrko, J., et al., "Key Management Extensions for Session
-             Description Protocol (SDP) and Real Time Streaming Protocol
-             (RTSP)", Work in Progress.
-
-   [KSYH]    Kang, J-S., Shin, S-U., Hong, D. and O. Yi, "Provable
-             Security of KASUMI and 3GPP Encryption Mode f8",
-             Proceedings Asiacrypt 2001, Springer Verlag LNCS 2248, pp.
-             255-271, 2001.
-
-   [MIKEY]   Arrko, J., et. al., "MIKEY: Multimedia Internet KEYing",
-             Work in Progress.
-
-   [MF00]    McGrew, D. and S. Fluhrer, "Attacks on Encryption of
-             Redundant Plaintext and Implications on Internet Security",
-             the Proceedings of the Seventh Annual Workshop on Selected
-             Areas in Cryptography (SAC 2000), Springer-Verlag.
-
-   [PCST1]   Perrig, A., Canetti, R., Tygar, D. and D.  Song, "Efficient
-             and Secure Source Authentication for Multicast", in Proc.
-             of Network and Distributed System Security Symposium NDSS
-             2001, pp. 35-46, 2001.
-
-   [PCST2]   Perrig, A., Canetti, R., Tygar, D. and D. Song, "Efficient
-             Authentication and Signing of Multicast Streams over Lossy
-             Channels", in Proc. of IEEE Security and Privacy Symposium
-             S&P2000, pp. 56-73, 2000.
-
-   [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-             Recommendations for Security", RFC 1750, December 1994.
-
-   [RFC2675] Borman, D., Deering, S. and R. Hinden, "IPv6 Jumbograms",
-             RFC 2675, August 1999.
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 49]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukuhsima, H.,
-             Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
-             Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke,
-             T., Yoshimura, T. and H. Zheng, "RObust Header Compression:
-             Framework and Four Profiles: RTP, UDP, ESP, and
-             uncompressed (ROHC)", RFC 3095, July 2001.
-
-   [RFC3242] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
-             (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP ", RFC
-             3242, April 2002.
-
-   [SDMS]    Andreasen, F., Baugher, M. and D. Wing, "Session
-             Description Protocol Security Descriptions for Media
-             Streams", Work in Progress.
-
-   [SWO]     Svanbro, K., Wiorek, J. and B. Olin, "Voice-over-IP-over-
-             wireless", Proc.  PIMRC 2000, London, Sept. 2000.
-
-   [V02]     Vaudenay, S., "Security Flaws Induced by CBC Padding -
-             Application to SSL, IPsec, WTLS...", Advances in
-             Cryptology, EUROCRYPT'02, LNCS 2332, pp. 534-545.
-
-   [WC81]    Wegman, M. N., and  J.L. Carter, "New Hash Functions and
-             Their Use in Authentication and Set Equality", JCSS 22,
-             265-279, 1981.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 50]
-
-RFC 3711                          SRTP                        March 2004
-
-
-Appendix A: Pseudocode for Index Determination
-
-   The following is an example of pseudo-code for the algorithm to
-   determine the index i of an SRTP packet with sequence number SEQ.  In
-   the following, signed arithmetic is assumed.
-
-         if (s_l < 32,768)
-            if (SEQ - s_l > 32,768)
-               set v to (ROC-1) mod 2^32
-            else
-               set v to ROC
-            endif
-         else
-            if (s_l - 32,768 > SEQ)
-               set v to (ROC+1) mod 2^32
-            else
-               set v to ROC
-            endif
-         endif
-         return SEQ + v*65,536
-
-Appendix B: Test Vectors
-
-   All values are in hexadecimal.
-
-B.1.  AES-f8 Test Vectors
-
-   SRTP PREFIX LENGTH  :   0
-
-   RTP packet header   :   806e5cba50681de55c621599
-
-   RTP packet payload  :   70736575646f72616e646f6d6e657373
-                           20697320746865206e65787420626573
-                           74207468696e67
-
-   ROC                 :   d462564a
-   key                 :   234829008467be186c3de14aae72d62c
-   salt key            :   32f2870d
-   key-mask (m)        :   32f2870d555555555555555555555555
-   key XOR key-mask    :   11baae0dd132eb4d3968b41ffb278379
-
-   IV                  :   006e5cba50681de55c621599d462564a
-   IV'                 :   595b699bbd3bc0df26062093c1ad8f73
-
-
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 51]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   j = 0
-   IV' xor j           :   595b699bbd3bc0df26062093c1ad8f73
-   S(-1)               :   00000000000000000000000000000000
-   IV' xor S(-1) xor j :   595b699bbd3bc0df26062093c1ad8f73
-   S(0)                :   71ef82d70a172660240709c7fbb19d8e
-   plaintext           :   70736575646f72616e646f6d6e657373
-   ciphertext          :   019ce7a26e7854014a6366aa95d4eefd
-
-   j = 1
-   IV' xor j           :   595b699bbd3bc0df26062093c1ad8f72
-   S(0)                :   71ef82d70a172660240709c7fbb19d8e
-   IV' xor S(0) xor j  :   28b4eb4cb72ce6bf020129543a1c12fc
-   S(1)                :   3abd640a60919fd43bd289a09649b5fc
-   plaintext           :   20697320746865206e65787420626573
-   ciphertext          :   1ad4172a14f9faf455b7f1d4b62bd08f
-
-   j = 2
-   IV' xor j           :   595b699bbd3bc0df26062093c1ad8f71
-   S(1)                :   3abd640a60919fd43bd289a09649b5fc
-   IV' xor S(1) xor j  :   63e60d91ddaa5f0b1dd4a93357e43a8d
-   S(2)                :   220c7a8715266565b09ecc8a2a62b11b
-   plaintext           :   74207468696e67
-   ciphertext          :   562c0eef7c4802
-
-B.2.  AES-CM Test Vectors
-
-    Keystream segment length: 1044512 octets (65282 AES blocks)
-    Session Key:      2B7E151628AED2A6ABF7158809CF4F3C
-    Rollover Counter: 00000000
-    Sequence Number:  0000
-    SSRC:             00000000
-    Session Salt:     F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000 (already shifted)
-    Offset:           F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000
-
-    Counter                            Keystream
-
-    F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000   E03EAD0935C95E80E166B16DD92B4EB4
-    F0F1F2F3F4F5F6F7F8F9FAFBFCFD0001   D23513162B02D0F72A43A2FE4A5F97AB
-    F0F1F2F3F4F5F6F7F8F9FAFBFCFD0002   41E95B3BB0A2E8DD477901E4FCA894C0
-    ...                                ...
-    F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF   EC8CDF7398607CB0F2D21675EA9EA1E4
-    F0F1F2F3F4F5F6F7F8F9FAFBFCFDFF00   362B7C3C6773516318A077D7FC5073AE
-    F0F1F2F3F4F5F6F7F8F9FAFBFCFDFF01   6A2CC3787889374FBEB4C81B17BA6C44
-
-   Nota Bene: this test case is contrived so that the latter part of the
-   keystream segment coincides with the test case in Section F.5.1 of
-   [CTR].
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 52]
-
-RFC 3711                          SRTP                        March 2004
-
-
-B.3.  Key Derivation Test Vectors
-
-   This section provides test data for the default key derivation
-   function, which uses AES-128 in Counter Mode.  In the following, we
-   walk through the initial key derivation for the AES-128 Counter Mode
-   cipher, which requires a 16 octet session encryption key and a 14
-   octet session salt, and an authentication function which requires a
-   94-octet session authentication key.  These values are called the
-   cipher key, the cipher salt, and the auth key in the following.
-   Since this is the initial key derivation and the key derivation rate
-   is equal to zero, the value of (index DIV key_derivation_rate) is
-   zero (actually, a six-octet string of zeros).  In the following, we
-   shorten key_derivation_rate to kdr.
-
-   The inputs to the key derivation function are the 16 octet master key
-   and the 14 octet master salt:
-
-      master key:  E1F97A0D3E018BE0D64FA32C06DE4139
-      master salt: 0EC675AD498AFEEBB6960B3AABE6
-
-   We first show how the cipher key is generated.  The input block for
-   AES-CM is generated by exclusive-oring the master salt with the
-   concatenation of the encryption key label 0x00 with (index DIV kdr),
-   then padding on the right with two null octets (which implements the
-   multiply-by-2^16 operation, see Section 4.3.3).  The resulting value
-   is then AES-CM- encrypted using the master key to get the cipher key.
-
-      index DIV kdr:                 000000000000
-      label:                       00
-      master salt:   0EC675AD498AFEEBB6960B3AABE6
-      -----------------------------------------------
-      xor:           0EC675AD498AFEEBB6960B3AABE6     (x, PRF input)
-
-      x*2^16:        0EC675AD498AFEEBB6960B3AABE60000 (AES-CM input)
-
-      cipher key:    C61E7A93744F39EE10734AFE3FF7A087 (AES-CM output)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 53]
-
-RFC 3711                          SRTP                        March 2004
-
-
-   Next, we show how the cipher salt is generated.  The input block for
-   AES-CM is generated by exclusive-oring the master salt with the
-   concatenation of the encryption salt label.  That value is padded and
-   encrypted as above.
-
-      index DIV kdr:                 000000000000
-      label:                       02
-      master salt:   0EC675AD498AFEEBB6960B3AABE6
-
-      ----------------------------------------------
-      xor:           0EC675AD498AFEE9B6960B3AABE6     (x, PRF input)
-
-      x*2^16:        0EC675AD498AFEE9B6960B3AABE60000 (AES-CM input)
-
-                     30CBBC08863D8C85D49DB34A9AE17AC6 (AES-CM ouptut)
-
-      cipher salt:   30CBBC08863D8C85D49DB34A9AE1
-
-   We now show how the auth key is generated.  The input block for AES-
-   CM is generated as above, but using the authentication key label.
-
-      index DIV kdr:                   000000000000
-      label:                         01
-      master salt:     0EC675AD498AFEEBB6960B3AABE6
-      -----------------------------------------------
-      xor:             0EC675AD498AFEEAB6960B3AABE6     (x, PRF input)
-
-      x*2^16:          0EC675AD498AFEEAB6960B3AABE60000 (AES-CM input)
-
-   Below, the auth key is shown on the left, while the corresponding AES
-   input blocks are shown on the right.
-
-   auth key                           AES input blocks
-   CEBE321F6FF7716B6FD4AB49AF256A15   0EC675AD498AFEEAB6960B3AABE60000
-   6D38BAA48F0A0ACF3C34E2359E6CDBCE   0EC675AD498AFEEAB6960B3AABE60001
-   E049646C43D9327AD175578EF7227098   0EC675AD498AFEEAB6960B3AABE60002
-   6371C10C9A369AC2F94A8C5FBCDDDC25   0EC675AD498AFEEAB6960B3AABE60003
-   6D6E919A48B610EF17C2041E47403576   0EC675AD498AFEEAB6960B3AABE60004
-   6B68642C59BBFC2F34DB60DBDFB2       0EC675AD498AFEEAB6960B3AABE60005
-
-
-
-
-
-
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 54]
-
-RFC 3711                          SRTP                        March 2004
-
-
-Authors' Addresses
-
-   Questions and comments should be directed to the authors and
-   avt@ietf.org:
-
-   Mark Baugher
-   Cisco Systems, Inc.
-   5510 SW Orchid Street
-   Portland, OR 97219 USA
-
-   Phone:  +1 408-853-4418
-   EMail:  mbaugher@cisco.com
-
-
-   Elisabetta Carrara
-   Ericsson Research
-   SE-16480 Stockholm
-   Sweden
-
-   Phone:  +46 8 50877040
-   EMail:  elisabetta.carrara@ericsson.com
-
-
-   David A. McGrew
-   Cisco Systems, Inc.
-   San Jose, CA 95134-1706
-   USA
-
-   Phone:  +1 301-349-5815
-   EMail:  mcgrew@cisco.com
-
-
-   Mats Naslund
-   Ericsson Research
-   SE-16480 Stockholm
-   Sweden
-
-   Phone:  +46 8 58533739
-   EMail:  mats.naslund@ericsson.com
-
-
-   Karl Norrman
-   Ericsson Research
-   SE-16480 Stockholm
-   Sweden
-
-   Phone:  +46 8 4044502
-   EMail:  karl.norrman@ericsson.com
-
-
-
-Baugher, et al.             Standards Track                    [Page 55]
-
-RFC 3711                          SRTP                        March 2004
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78 and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-Baugher, et al.             Standards Track                    [Page 56]
-