rfc3711.txt

mediastreamer2是开源的网络传输媒体流的库

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