rfc3711.txt

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

     |           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