rfc3711.txt

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

   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 fro