[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-mcgrew-avt-srtp) 00 01 02 03 04 05 06 07 08 09 RFC 3711

        Internet Engineering Task Force                    Baugher, McGrew,
        AVT Working Group                                      Oran (Cisco)
        INTERNET-DRAFT                              Blom, Carrara, Naslund,
        EXPIRES: July 2002                               Norrman (Ericsson)
                                                              February 2002
     
                     The Secure Real Time Transport Protocol
                           <draft-ietf-avt-srtp-03.txt>
     
     
     
     Status of this memo
     
        This document is an Internet-Draft and is in full conformance with
        all provisions of Section 10 of RFC2026.
     
        Internet-Drafts are working documents of the Internet Engineering
        Task Force (IETF), its areas, and its working groups. Note that
        other groups may also distribute working documents as Internet-
        Drafts.
     
        Internet-Drafts are draft documents valid for a maximum of six
        months and may be updated, replaced, or obsoleted by other documents
        at any time. It is inappropriate to use Internet-Drafts as reference
        material or cite them other than as "work in progress".
     
        The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/lid-abstracts.txt
     
        The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html
     
     
     
     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/RTCP traffic.
     
        SRTP can achieve high throughput and low packet expansion. SRTP
        proves to be a suitable protection for heterogeneous environments,
        i.e., environments including both wired and wireless links. 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).
     
     
     
     
     
     
      
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
     
        TABLE OF CONTENTS
     
     1. Notational Conventions............................................3
     2. Goals.............................................................3
     3. SRTP Framework....................................................4
      3.1 SRTP Cryptographic Contexts.....................................5
        3.1.1 Transform-independent parameters............................6
        3.1.2 Transform-dependent parameters..............................7
        3.1.3 Mapping SRTP Packets to Cryptographic Contexts..............8
      3.2 SRTP Packet Processing..........................................8
        3.2.1 Packet Index Determination, and ROC, s_l Update............10
        3.2.2 Replay Protection..........................................12
      3.3 Secure RTCP....................................................12
     4. Pre-Defined Cryptographic Transforms.............................16
      4.1 Encryption.....................................................16
        4.1.1 AES in Counter Mode........................................18
        4.1.2 AES in f8-mode.............................................19
        4.1.3 NULL Cipher................................................21
      4.2 Message Authentication and Integrity...........................21
        4.2.1. HMAC/SHA1.................................................22
        4.2.2 TMMH.......................................................22
      4.3 Key Derivation.................................................25
        4.3.1 Key Derivation Algorithm...................................25
        4.3.2 SRTCP Key Derivation.......................................27
        4.3.3 AES-CM PRF.................................................27
     5. Default and Mandatory Transforms.................................27
      5.1 Encryption: AES-CM and NULL....................................27
      5.2 Message Authentication/Integrity: HMAC/SHA1....................27
      5.3 Key Derivation: AES-CM PRF.....................................27
     6. SRTP/SRTCP Parameters............................................28
     7. Adding SRTP Transforms...........................................28
     8. Rationale........................................................29
      8.1 Key derivation.................................................29
      8.2 Salting key....................................................29
      8.3 TMMH: Message Integrity from Universal Hashing.................30
      8.4 Data Origin Authentication Considerations......................30
     9. Key Management Considerations....................................30
     10. Security Considerations.........................................32
      10.1 SSRC collision and two-time pad...............................32
      10.2 Key Usage.....................................................33
      10.3 Confidentiality of the RTP Payload............................34
      10.4 Confidentiality of the RTP Header.............................34
      10.5 Integrity of the RTP packet...................................35
        10.5.1 Integrity of the RTP header: IHA..........................35
     11. Interaction with Forward Error Correction mechanisms............36
     12. Scenarios.......................................................36
      12.1 Two-party Unicast.............................................37
        12.1.1 One bi-directional RTP stream.............................37
        12.1.2 One master key per party..................................37
      12.2 Multicast.....................................................38
     
     
     
     Baugher, et al.                                               [Page 2]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        12.2.1 Small conference with one sender..........................38
        12.2.2 Large multicast with one sender...........................39
      12.3 Re-keying and access control..................................39
      12.4 Summary of basic scenarios....................................41
     13. IANA Considerations.............................................41
     14. Acknowledgements................................................41
     15. Author's Addresses..............................................41
     16. References......................................................42
     Appendix A: Pseudocode for Index Determination......................44
     Appendix B: Test Vectors............................................44
      B.1 AES-f8 Test Vectors............................................44
      B.2 AES-CM Test Vectors............................................45
      B.3 TMMH Test Vectors..............................................46
     
     
     1. Notational Conventions
     
        The key words "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].
        Terminology is conform to [RFC2828].
     
        By convention, the left most bit (byte) 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.
     
     
     2. Goals
     
        The security goals for SRTP are to ensure:
     
        * the confidentiality of the RTP and RTCP payloads, and
     
        * the integrity protection 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.
     
        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:
     
     
     
     Baugher, et al.                                               [Page 3]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
     
        * 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, and robustness to transmission bit-errors in the
          encrypted payload.
     
        These properties ensure that SRTP is a suitable protection scheme
        for RTP/RTCP in both wired and wireless scenarios.
     
     
     3. SRTP Framework
     
        RTP is the Real Time Transport Protocol [RFC1889]. We define SRTP as
        a profile of RTP, in a way analogous to RFC1890 which defines the
        audio/video profile for RTP. Conceptually, we consider it to be a
        'bump in the stack' implementation which resides between the RTP
        application and the transport layer, which intercepts RTP packets
        and then forwards an equivalent SRTP packet on the sending side, and
        which intercepts SRTP packets and passes an equivalent RTP packet up
        the stack on the receiving side.
     
        The format of an SRTP packet is illustrated in Figure 1.
     
        The Encrypted Portion of an SRTP packet consists of the encryption
        of the RTP payload of the equivalent RTP packet. (Our use of the
        word 'encryption' includes also the possibility of a 'NULL'-
        encryption.)
     
        The optional MKI and optional authentication tag are the only fields
        defined by SRTP that are not in RTP. Only 8-bit alignment is
        assumed.
     
        MKI (Master Key Identifier): variable 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.1.3.  The MKI MAY be used by key management for the
               purposes of re-keying and identifies a particular master key
               within the cryptographic context, viz. Section 3.1.1.
     
        Authentication tag: variable length, optional
     
     
     
     Baugher, et al.                                               [Page 4]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
               The authentication tag shall be 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, note that 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.
     
          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                             |
     | | |                             ....                              |
     +-+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | | ~                     SRTP MKI (optional)                       ~
     | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | | ~                  authentication tag (optional)                ~
     | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | |
     | +- Encrypted Portion
     +---- Authenticated Portion
     
        Figure 1.  The format of an SRTP packet.
     
     3.1 SRTP Cryptographic Contexts
     
        Each SRTP session requires the sender and receiver to maintain
        cryptographic state information. This information is called the
        cryptographic context.
     
        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
        cryptographically secure way.
     
     
     
     
     Baugher, et al.                                               [Page 5]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
     3.1.1 Transform-independent parameters
     
        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.2.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 is the
          last received sequence number (possibly authenticated, if
          authentication is provided),
     
        * an identifier for the encryption algorithm, i.e., the cipher and
          its mode of operation, and related parameters (when encryption is
          provided),
     
        * an identifier for the message authentication algorithm, and
          related parameters (when authentication is provided),
     
        * a replay list, maintained by the receiver only (when
          authentication and replay protection are provided), containing
          indexes of recently received and authenticated SRTP packets,
     
        * an 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 bytes) of the
          MKI field, and (for the sender) the actual value of the currently
          active MKI,
     
        (the value of the last three MKI-related parameters above MUST be
        kept fixed for the life-time of the context)
     
        * the master key(s),
     
        * for each master key, means to maintain a count of the number of
          SRTP packets that has been processed with that master key
          (essential for security, see Sections 3.2.1 and 10), either in the
          form of an explicit counter, or, the value of the first SRTP index
          for which the key was used,
     
        * non-negative integers n_e, and n_a, determining the length of the
          session keys for encryption, and message authentication.
     
     
     
     Baugher, et al.                                               [Page 6]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
     
        The master key(s) MUST be random and kept secret. In addition, for
        each master key, SRTP MAY choose to specify 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 10.2. A 'NULL'-
          salt is treated as 00...0.
     
        * an integer in the set {1,2,4,...,2^16}, the 'key_derivation_rate',
          where an unspecified value is treated as zero,
     
        * if the MKI-indicator is one, the actual MKI value for which the
          master key is valid,
     
        * <'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.
          These values are absolute quantities, not relative.
     
        SRTCP by default uses the same cryptographic context parameters,
        except:
     
        * no rollover counter or s_l-value needs 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 (c.f. above).
     
        Note in particular that the master key(s) MAY be shared between SRTP
        and SRTCP, if the pre-defined transforms (including the key
        derivation) are used but the session key(s) MUST NOT be so shared.
     
     3.1.2 Transform-dependent parameters
     
        All encryption, authentication/integrity, and key derivation
        parameters are defined in the Transforms section dedicated to the
        particular encryption, authentication, or key derivation transform
        (see Section 4). Typical examples of such parameters are block size
        of ciphers, session keys, data for IV formation, etc. We note again
        (it cannot be stressed enough) that SRTP and SRTCP MUST use distinct
        (pseudo-)random session keys. Future SRTP transform specifications
        MUST include a section to list the additional cryptographic
        context's parameters for that transform, if any.
     
     
     
     
     Baugher, et al.                                               [Page 7]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
     3.1.3 Mapping SRTP Packets to Cryptographic Contexts
     
        Recall that an RTP session for each participant is defined [RFC1889]
        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 current RTP packet (for the sender) or SRTP
        packet (for the receiver). It is assumed that, when presented with
        this information, the key management returns a context with the
        information as described in Section 3.1.
     
        As noted above, SRTP and SRTCP by default shares 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 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.
     
        If no valid context can be found for a packet corresponding to a
        certain context identifier, that packet MUST be discarded from
        further processing.
     
     
     3.2 SRTP Packet Processing
     
        The following applies to SRTP. SRTCP is described in Section 3.3.
     
        Assuming initialization of the cryptographic context(s) has taken
        place via key management, and as described in Section 3.2.1, to
        construct a proper SRTP packet, given an RTP packet, the sender has
        to do the following:
     
        1. Determine which cryptographic context to use as described in
        Section 3.1.3.
     
     
     
     
     Baugher, et al.                                               [Page 8]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        2. Determine the index of the SRTP packet as described in Section
        3.2.1, using the rollover counter in the cryptographic context and
        the sequence number in the RTP packet.
     
        3. Determine the master key and master salt. If the MKI indicator in
        the context is set to one, this is done using the current MKI in the
        cryptographic context, otherwise, the index determined in the
        previous step is used.
     
        4. Determine the session keys and 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 and the index, determined in Steps 2 and 3.
     
        5. If encryption is provided, encrypt the RTP payload to produce the
        Encrypted Portion of the packet (see Section 4.1, for the defined
        ciphers), using the encryption algorithm indicated in the
        cryptographic context, the session encryption key and salt (if used)
        found in Step 4, and the index found in Step 2.
     
        6. If the MKI indicator is set to one, append the MKI to the packet.
     
        7. If message authentication is provided, compute the authentication
        tag for the Authenticated Portion of the packet, as described in
        Section 4.2, using the current rollover counter (if used by the
        transform), the authentication 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.2.1, using the
        packet index determined in Step 2.
     
     
        To authenticate and decrypt a SRTP packet, the receiver has to do
        the following:
     
        1. Determine which cryptographic context to use as described in
        Section 3.1.3.
     
        2. Estimate the index of the SRTP packet from the rollover counter
        in the cryptographic context and the sequence number in the SRTP
        packet, as described in Section 3.2.1.
     
        3. Determine the master key and master salt. If the MKI indicator in
        the context is set to one, this is done using the MKI in the SRTP
        packet, otherwise, the index from the previous step is used.
     
        4. Determine the session keys, and session salt (if used by the
        transform) as described in Section 4.3, using master key,
        key_derivation_rate and session key-lengths in the cryptographic
        context and the index, determined in Steps 2 and 3.
     
     
     
     Baugher, et al.                                               [Page 9]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
     
        5. If message authentication and replay protection are provided,
        first check if the packet has been replayed, as described in Section
        3.2.2, using the Replay List in the context 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
        index (rollover counter when used by the transform) 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. If encryption is provided, 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 found in Step 4, and the index from
        Step 2.
     
        7. Update the rollover counter and last sequence number, s_l, in the
        cryptographic context as in Section 3.2.1, using the packet index
        estimated in Step 2. If replay protection is provided, also update
        the Replay List as described in Section 3.2.2.
     
        8. When applicable, delete the MKI and authetication tag fields from
        the packet.
     
     3.2.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,
        as described below. For the pre-defined transforms, the index i is
        used in replay protection (Section 3.2.3), encryption and message
        authentication (Sections 4.1 and 4.2), and for the key derivation
        (Section 4.3). It MAY also be used to determine the correct master
        key as indicated above.
     
        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
        estimate the correct index. That is, estimating the location in the
        sequence of all SRTP packets. Here, the index is defined as 2^16 * v
        + SEQ, where the RTP sequence number is SEQ, and v is an estimate
        for the current value of the rollover counter, ROC. This estimate is
     
     
     
     Baugher, et al.                                              [Page 10]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        based on SEQ, a previous estimate for ROC and the value s_l. The
        latter two are maintained locally by the receiver as described
        below.
     
        A robust approach for the proper use of a rollover counter for the
        pre-defined transforms 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 dealt with.
     
        Initially, the receiver MUST be given the current ROC value from the
        sender using out of band signaling (or ROC is zero at the beginning
        of the session), see Section 9. Furthermore, the receiver SHALL
        initialize s_l to the RTP sequence number (SEQ) of the first
        observed SRTP packet.
     
        On consecutive SRTP packets, the receiver MAY 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.
     
        After the packet has been processed using the estimated index, the
        receiver MUST decide if s_l and ROC should be updated. For instance,
        a simple (but not error robust) method is to simply set s_l to SEQ
        and, if the value v = ROC+1 was used, to update ROC to v.
     
        Caveat: if message authentication is not present, neither the
        initialization of s_l, nor the ROC update can be made completely
        robust on the receiving side.
     
     
        After a re-keying (changing to a new master key) occurs, the roll-
        over counter maintains its sequence of values, i.e., it MUST NOT be
        reset to zero, to avoid inconsistencies in key life-times.
     
        As the rollover counter is 32 bits long and the sequence number is
        16 bits long, the maximum number of packets that can be secured with
        the same key is 2^48 using the pre-define 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 3.3 and the summary in Section
        10.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 9) MUST be
        triggered, before this amount of traffic, and MAY be triggered
        earlier, e.g., for increased security and access control to media.
        Re-occurring key derivation, as determined by a non-zero
        key_derivation_rate (see Section 4.3), also gives stronger security,
     
     
     
     Baugher, et al.                                              [Page 11]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        but does not change the above absolute maximum value, i.e. the
        master key shall still be used for a maximum of 2^48 SRTP packets
        (or 2^31 SRTCP packets, see below).
     
        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 in order for synchronization
        to be lost. Such drastic loss or reorder is likely to disrupt the
        RTP application itself.
     
     3.2.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. SRTP provides protection against such
        attacks whenever message authentication is provided, through the
        storage of the indices of the most recently received and
        authenticated packets.
     
        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 (successfully) 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.3 Secure RTCP
     
     
     
     
     Baugher, et al.                                              [Page 12]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
     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                         |
     +-|>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | | ~                     SRTP 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 Report and
        SDES packet.
     
        Secure RTCP follows the definition of Secure RTP. SRTCP adds three
        new fields to the RTCP packet definition, the SRTCP index, an
     
     
     
     Baugher, et al.                                              [Page 13]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        'encrypt-flag', and the authentication tag. Those fields MUST be
        appended to an RTCP packet when at least integrity protection (which
        is mandatory) is applied to the RTCP packet, in order to form an
        equivalent SRTCP packet, so that the added fields follow any other
        profile specific extensions. SRTCP adds an optional fourth field,
        the MKI, which functions according ot the MKI definition in section
        3.  An SRTCP packet is illustrated in Figure 2.
     
        According to [RFC1889] there is a 'recommended' packet format for
        compound packets. SRTCP MUST be given packets according to that
        recommendation in the sense that the first part MUST be a
        send/receive report. However, the so-called encryption prefix
        (Section 6.1 of [RFC1889]), a random 32-bit quantity intended to
        deter known plaintext attacks, MUST NOT be used (see below).
     
        The Encrypted Portion of an SRTCP packet consists of the encryption
        of the RTCP payload of the equivalent compound RTCP packet, from the
        first RTCP packet, i.e., from the ninth (9) byte 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, SRTCP index (after any encryption has been applied to
        the payload).
     
        The added fields are:
     
        E-flag: 1 bit, mandatory
               The E-flag indicates if the current SRTCP packet is encrypted
               or unencrypted. Section 9.1 of [RFC1889] 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, mandatory
               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 (c.f. Section 3.2.1).
     
        Authentication Tag: variable length, mandatory
               The authentication tag shall be used to carry message
               authentication data.
     
        The optional field is the variable-length MKI (see Section 3).
     
        SRTCP uses the cryptographic context parameters and packet
        processing of SRTP, with the following changes:
     
     
     
     
     Baugher, et al.                                              [Page 14]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        * The receiver need not to 'estimate' the index, as it is explicitly
        signaled in the packet.
     
        * If the MKI indicator in the cryptographic context is zero, the
        master keys is determined by the current SRTP index, even though
        SRTCP has its own index. Since the SRTCP source as with any SSRC in
        an SRTP session has its own sequence number space, the master key
        <From, To> lifetime MUST be based on the SRTP master key lifetime.
        The concomitant re-keying issues are discussed in sections 9 and 10.
     
        * Pre-defined SRTCP encryption is as defined in Section 4, but using
        the definition of the SRTCP Encrypted Portion as defined 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. Note that the master key and salt is shared between SRTP
        and SRTCP, but the (encryption) session key and salt will be
        distinct due to the key derivation definition (Section 4.3).
     
        The E-flag is assigned values 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.2.3, but using
        the SRTCP index as the index i, and as noted maintains a separate
        replay list specific to SRTCP.
     
        * The pre-defined SRTCP authentication tag is defined as in Section
        4, but with the Authenticated Portion of the SRTCP packet defined 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). (Exception: when SRTP is not authenticated, the default
        authentication transform MUST be used for SRTCP.) Note that the
        master key is shared between SRTP and SRTCP, but the
        (authentication) session key will be distinct due to the key
        derivation definition (Section 4.3).
     
     * 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 RTCP packets
     processed, see below).
     
        There MAY also exist some minor transform specific changes, see
        Section 4 for the defined transforms.
     
     
     
     
     Baugher, et al.                                              [Page 15]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        As noted, the encryption prefix (Section 6.1 of [RFC1889]), is not
        to be used because this mechanism supports ciphers that are not
        secure against known plaintext attacks.  Ciphers that are not secure
        against known-plaintext attacks SHOULD not be used to encrypt RTP
        messages. The pre-defined SRTP encryption uses a secure, additive
        stream cipher, and thus the prefix offers no benefit at all.
     
        The maximum number of SRTCP packets with a given session or master
        key is limited to 2^31. Due to for example re-keying, reaching this
        limit may or may not coincide with wrapping of the SRTCP index, and
        thus the sender MUST be able to deduce the packet count, e.g., as
        indicated before.  Also, since the session keys for SRTP and SRTCP
        are by default derived from the same master key, new session and
        master keys for both protocols MUST be obtained before any of the
        two protocols reaches its maximum key-usage limit (c.f. 3.2.1).
     
        Message authentication for RTCP is REQUIRED, as it is the control
        protocol (e.g., it has a BYE packet). Note also that the cost in
        total bandwidth for RTCP authentication is not as high as the one of
        RTP authentication, as the recommended session bandwidth allocated
        to RTCP is at most 5% and the RTCP packets are less frequent.
        However, when adding authentication to RTCP, the overhead in
        bandwidth SHOULD be considered (the bandwidth will be more than 5%).
     
        Note however, that large-scale multicast application of SRTCP might
        require careful consideration in the configuration and use, see
        Section 12. The security risks that can occur wherever SRTCP is not
        used, MUST be taken seriously under consideration.
     
     
     4. Pre-Defined Cryptographic Transforms
     
        While there are numerous encryption and message authentication
        algorithms that can be used in SRTP, we define below 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 7.
     
     4.1 Encryption
     
        The following parameters are generic and common to all pre-defined,
        non-NULL, encryption transforms.
     
        * BLOCK CIPHER and mode are the block cipher used and its mode of
         operation (the default is AES in counter mode, see below)
        * n_b is the bit-size of the block for the block cipher
        * k_e is the session encrypting key
        * n_e is the bit-length of k_e (the default is 128 bits)
        * k_s is the so called session salting key
     
     
     
     Baugher, et al.                                              [Page 16]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        * n_s is the bit-length of k_s. n_s is at most n_b - 16 bits, and
         the default value is the maximum (n_b - 16).
        * SRTP_PREFIX_LENGTH is the octet length of the keystream prefix, an
         (at least) 8-bit non-negative integer, inferred from 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 use a 'seekable' segmented
        keystream generator (KG), which for each secret key maps the SRTP
        packet index into a pseudorandom keystream segment, used to encrypt
        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. Decryption is done the same way, but swapping the roles of
        the plaintext and ciphertext.
     
        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 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 so-called 'encryption prefix' of
        [RFC1889, Section 6.1]), and the remaining octets are called the
        keystream suffix. This process is illustrated in Figure 3.
     
     
        +----+   +------------------+---------------------------------+
        | KG |-->| Keystream Prefix |          Keystream Suffix       |---+
        +----+   +------------------+---------------------------------+   |
                                                                          |
                                    +---------------------------------+   v
                                    | Encrypted Portion 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 number of octets in the keystream prefix is denoted as
     
     
     
     Baugher, et al.                                              [Page 17]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        SRTP_PREFIX_LENGTH. The keystream prefix is reserved for use with
        certain message authentication transforms, such as the pre-defined
        TMMH transform (Section 4.2.2). The Prefix is indicated by a
        positive, non-zero value of this latter parameter. 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), and we
        define two modes of running AES, Segmented Integer Counter Mode AES
        and AES in f8-mode. In the sequel, let E(k,x) be AES applied to key
        k and input block x. AES has (default) n_e = 128-bit key size and
        (always) n_b = 128-bit block size.
     
     
     4.1.1 AES in Counter Mode
     
        Conceptually, counter mode 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 is
        computed as follows.
     
     
     4.1.1.1 Keystream Generation
     
        A keystream segment is 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)
     
        The inclusion of the SSRC allows the use of the same key to protect
        distinct SRTP streams. Exploiting such features is conditioned by
        requirements, see the security caveats in Section 10.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_s SHALL be replaced
        by the SRTCP session salt.)
     
        Note that the initial value, IV, is fixed for each packet. The
        number of blocks of keystream generated for any fixed value of IV
        MUST NOT exceed 2^16. 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
     
     
     
     Baugher, et al.                                              [Page 18]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        '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].
     
     
     4.1.2 AES in f8-mode
     
        To encrypt UMTS (Universal Mobile Telecommunications System, as 3G
        networks) data, a solution (see [ES3D]) 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 f8-mode for RTP encryption, with default
        128-bit key and block size.
     
        Figure 4 shows the structure of block cipher, E, running in what we
        shall call 'f8-mode of operation'.
     
                         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).
     
     
     
     Baugher, et al.                                              [Page 19]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        The figure represents the KG in Figure 3, when AES-f8 is used.
     
     4.1.2.1 f8 Keystream Generation
     
        As above, let E(k_e,x) be the 128-bit output of AES in the encrypt
        direction when applied to the key k_e and n_b = 128-bit plaintext
        block x. The Initialization Vector (IV) is determined as described
        in Section 4.1.2.2.
     
        Let IV', S(j), and m denote n_b-bit blocks, determined below. The
        keystream, S(0) || ... || S(L-1), for an N-bit message is 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) 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.
        The role of the internal counter is to prevent short keystream
        cycles. The value of the key mask m is defined to 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 maximum allowable packet size can be determined as follows. The
        AES has a block size of 128 bits, and assuming that AES behaves like
        a random function, it is (heuristically) secure to generate somewhat
        less than 2^64 output blocks, we suggest a maximum of 2^32 blocks,
        which is sufficient to generate 2^39 bits of keystream. For
        practical sizes of the RTP packets, much fewer blocks are required
        though, and the counter j above will often be sufficient if
        implemented as a 16-bit counter.
     
     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
        10.5.1.
     
        The SRTP IV for 128-bit block AES-f8 is 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.
     
     
     
     
     Baugher, et al.                                              [Page 20]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        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, see Section
        10.1.
     
     4.1.2.3 f8 SRTCP IV Formation
     
        The SRTCP IV for 128-bit block AES-f8 is 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- and
        31-bit fields added to the packet.
     
     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", e.g., the
        encryption simply copies the plaintext input into the ciphertext
        output.
     
     
     4.2 Message Authentication and Integrity
     
        Common parameters:
     
        * k_a is the session message authentication key
        * n_a is the bit-length of the authentication key (the default for
          the default transform is 128 bits)
        * n_tag is the bit-length of the output authentication tag (the
          default is 32 bits)
        * SRTP_PREFIX_LENGTH is the octet length of the keystream prefix as
          defined above
        * M is the Authenticated Portion as specified in Section 3 for RTP
          and in Section 3.3 for RTCP.
     
        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.
     
        Below we describe the process of computing authentication tags. The
        sender computes the tag of the Authenticated Portion and appends it
        to the packet. The SRTP receiver verifies a message/authentication
        tag pair as follows. A new authentication tag is computed over the
        Authenticated Portion using the selected algorithm and key, and it
        is compared to the tag associated with the received message. If the
        two tags are equal, then the message/tag pair is valid; otherwise,
     
     
     
     Baugher, et al.                                              [Page 21]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        it is invalid and the error audit message "AUTHENTICATION FAILURE"
        MUST be returned.
     
     4.2.1. HMAC/SHA1
     
        When HMAC/SHA1 is used, the SRTP_PREFIX_LENGTH is 0. For SRTP, the
        HMAC is applied to the concatenation of the Authenticated Portion of
        the packet (M) and the rollover counter in the cryptographic
        context, i.e. HMAC(k_a, M || ROC). For SRTCP, we apply HMAC to the
        corresponding M, only (as it already includes the SRTCP index). By
        default, the output shall be truncated to the n_tag left-most bits.
        Default value for n_a is 128 bits, and for n_tag it is 32 bits.
     
     4.2.2 TMMH
     
        This document describes TMMH version two, which is not interoperable
        with the earlier version. In the following, the term TMMH
        refers to version two.
     
        TMMH is a simple function that maps a key and a message to a hash
        value. This hash value is encrypted by combining it with the
        keystream prefix to make the authentication tag, as described below.
     
        The key, message, and hash value are treated as sequences of
        unsigned sixteen bit integers in network byte order. In the
        following, we call such a 16-bit integer a word. The number of
        octets in the key and hash value MUST be a multiple of two (to be
        word-aligned). (Thus, n_tag and n_a MUST be multiples of 16.)
        Besides the above common parameters, we define the following
        parameters for TMMH:
     
        * TAG_WORDS, the number of words in the hash value, i.e., n_tag/16.
          The default is 2.
     
        The value of TAG_WORDS also defines the quantity SRTP_PREFIX_LENGTH
        to be TAG_WORDS * 2 (see Section 4.1).
     
        The number of words of the key, i.e. n_a/16, depends on the maximum
        length of any message to be authenticated as follows:
     
     
               MAX_MSG_LENGTH (octets)      Key size (16-bit words)
               ----------------------------------------------------
                    16                        7 + 2 * TAG_WORDS
                   128                       14 + 3 * TAG_WORDS
                  1024                       21 + 4 * TAG_WORDS
                  8192                       28 + 5 * TAG_WORDS
                 65536                       35 + 6 * TAG_WORDS
     
     
     
     
     
     Baugher, et al.                                              [Page 22]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        For instance, an RTP packet of length 80 bytes to be authenticated
        with a 32-bit (2 word) tag, requires a 320-bit TMMH key. The default
        key-size is defined below. However, applications that know on
        beforehand the size of the longest message they will ever encounter
        MAY choose a smaller key-size.
     
        * TAG is the authentication tag, which is the output of TMMH
     
        * PREFIX is the keystream prefix for the current packet as defined
          in Section 4.1.
     
        * K is the key, i.e., k_a as obtained by applying the key   *
          derivation. The default key-size is 94 octets, or 752 bits (to
          accommodate messages up to 65536 byte with a 2-word tag).
     
        * MSG_LEN, the number of octets in the message (before padding, when
          all-zero padding is needed to align to a word boundary when the
          message contains an odd number of octets)
     
        * p is equal to the prime number 2^16 + 1.
     
        In the following, we use the symbol * to denote integer
        multiplication and the symbol +32 to denote integer addition modulo
        2^32.
     
        TMMH uses several key-dependent internal data structures: the length
        multiplier array L, and an array of subkeys A. The length multiplier
        array L is an array of words, the ith element of which is denoted as
        L[i], with i ranging from zero to (TAG_WORDS - 1). A subkey is an
        array consisting of (TAG_WORDS + 7) words, and the ith element of
        the subkey S is denoted as S[i]. Five subkeys are used in TMMH. The
        subkeys are stored in an array denoted A.The ith subkey is denoted
        as A[i], with i ranging from zero to 4.
     
     
               +----+----+----+----+----+----+----+----+----+----+----+---
         Key   |K[0]|K[1]|K[2]|K[3]|K[4]|K[5]|K[6]|K[7]|K[8]|K[9]|K[a]|...
               +----+----+----+----+----+----+----+----+----+----+----+---
               +----+----+--------------------------------------------+---
         Field |L[0]|L[1]|                    A[0]                    |...
               +----+----+--------------------------------------------+---
     
        Figure 5.  An illustration of how the arrays L and A are assigned
        from the words of the TMMH key K. In this example, TAG_WORDS is
        equal to two. Here K[i] denotes the ith word of the TMMH key (where
        i is a hexadecimal number). The field A[0] is the 0:th subkey.
     
     
        The length multiplier array L and the subkey array A are taken from
        the TMMH key K as follows.
     
     
     
     
     Baugher, et al.                                              [Page 23]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
           1.  The value L[i] is set to K[i], for i = 0 to TAG_WORDS-1.
     
           2.  The value A[i][j] (the jth element of the ith subkey) is set
               to K[ TAG_WORDS + j + (TAG_WORDS + 7) * i ].
     
        This process is illustrated in Figure 5.
     
        We introduce the following notation: Let A_ij be the eight word
        vector A[i][j] ||  A[i][j + 1]  ||  ... ||  A[i][j + 7].
     
     
        The function V(S, M) defined below maps a subkey S and an eight-word
        data string M to a 32-bit unsigned integer.
     
          V(S,M) = S[0] * M[0] +32 S[1] * M[1] +32 ... +32 S[7] * M[7]
     
        Here +32 denotes integer addition modulo 2^32. The length of the
        subkey S may be greater than eight, but the excess words are ignored
        by the function V. (The definition of V such that the most
        significant words of the subkey may be ignored simplifies the
        exposition below.) If the message consists of less than 8 words, the
        remaining words are set to zero.
     
        The function U(S, M) is defined as
     
          U(S, M) = [ V(S, M) modulo p ] modulo 2^16.
     
        The core of TMMH is a 'compression' function C which maps a subkey
        value and an input string to an output string which is about eight
        times smaller than the input string. To compute C(S, D) for a given
        subkey value S and data string D of w words, do the following.
     
        1) Divide up D into blocks of eight words each (note that the last
           word may contain less than eight words) i.e.,
     
             D = D[0] || D[1] || ... || D[ ceil(w/8) ]
     
           where D[i] is the ith block, || denotes concatenation, and
           ceil(x) denotes the largest integer not less than x.
     
        2) Apply the function U to each block, using the subkey value S
           each time, then concatenate the outputs as follows:
     
            C(S, D) = U(S, D[0]) || U(S, D[1]) || ... || U(S, D[ceil(w/8)]).
     
        The j:th word (j starting from zero), T[j], of the TMMH tag is
        computed using the following algorithm:
     
           set X to M and set i to zero
           while the number of words in X is greater than eight, do
              set X to C(A_ij, X)
     
     
     
     Baugher, et al.                                              [Page 24]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
              increment i
           end while
           return [ [ [ L[j] * MSG_LEN ] +32 V(A_ij, X) ] mod p ] mod 2^16
     
     
        To use TMMH to compute the authentication tag TAG of a message, the
        TMMH hash value of that message is computed, then that value is
        combined with the keystream prefix defined in Section 4.1. The
        combining operation is word-wise addition modulo 2^16:
     
        TAG[j] = (T[j] + PREFIX[j]) mod 2^16, for j = 0 to TAG_WORDS-1.
     
        Note that for RTP, where HMAC is applied to M || ROC, TMMH is
        applied to M only. This is so, because the dependence on ROC is for
        TMMH inherent to the PREFIX quantity.
     
     
     4.3 Key Derivation
     
     4.3.1 Key Derivation Algorithm
     
        Regardless of the encryption or message authentication transform
        that is employed (it may be a defined transform or newly introduced
        according to Section 7), SRTP key derivation is the process of
        generating session keys, without extra communication between the
        parties and in a sender-receiver synchronized way.
     
     
                    master salt, packet index ---+
                                                 |
                                                 |
                                                 v
                       +-----------+         +--------+ session encr_key
                       | ext       | master  |        |---------->
                       | key mgmt  | key     |  key   | session auth_key
                       | (optional |-------->| deriv  |---------->
                       | rekey)    |         |        | session salt_key
                       |           |         |        |---------->
                       +-----------+         +--------+
     
     
        Figure 6: SRTP key derivation.
     
     
        At least one initial key derivation is always performed by SRTP,
        i.e., the first key derivation is mandatory. Further applications of
        the key derivation MAY be performed, according to the 'key
        derivation-rate' value in the cryptographic context. The key
        derivation function is defined to be initially invoked before the
        first packet and then, if derivation rate is r > 0, to be further
        invoked on every r:th packet, and produce session keys according to
     
     
     
     Baugher, et al.                                              [Page 25]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        the non-zero key derivation rate. 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.
     
        There is also a derivation of session salting keys for encryption
        transforms that so require, e.g., 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) is needed, and a default PRF transform is defined in
        Section 4.3.2.
     
        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 is defined as follows. To generate session key(s)(and
        session salt(s)) for the current packet, let the n-bit SRTP key (or
        salt) for this packet be
     
        PRF_n(k_master, ((<label> || (index DIV key_derivation_rate)) XOR
              master_salt)*2^16)
     
        where <label> is an 8-bit constant (see below), master_salt and
        key_derivation_rate is as determined in the cryptographic context,
        and index is the packet index (i.e., the 48-bit ROC || SEQ for
        SRTP).
     
        The session keys and salt are now 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 also as determined in the cryptographic
        context.
     
        The master key and master salting key MUST be random, but the master
        salt MAY be public. Default size for master key is 128-bits and for
        the master salt, 112 bits.
     
        Note that for a key_derivation_rate of 0, the initial application of
        the key derivation will take place once. The derivation operation is
        facilitated if the non-zero rates are chosen to be powers of 256.
     
     
     
     
     Baugher, et al.                                              [Page 26]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        The upper limit in the number of packets that can be secured using
        the same master key (see Section 10.2) is independent of the key
        derivation.
     
     4.3.2 SRTCP Key Derivation
     
        SRTCP uses the same master key as SRTP, i.e., it is shared between
        the two protocols. To do this securely, the following changes are
        done to 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 to 256 bit (master) keys,
        has input block size m = 128 and can produce n-bit outputs for n up
        to 2^23. We define PRF_n(k,x) to be AES in counter mode as described
        in Section 4.1.1, applied to key k, and IV equal to x, 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 Transforms
     
        The default transforms also are mandatory to implement transforms in
        SRTP. Of course, 'mandatory-to-implement' does not imply 'mandatory-
        to-use'.
     
     5.1 Encryption: AES-CM and NULL
     
        AES running in Segmented Integer Counter Mode, as defined in Section
        4.1.1, is the default and mandatory-to-implement encryption
        algorithm. The NULL cipher is mandatory to implement too.
     
     
     5.2 Message Authentication/Integrity: HMAC/SHA1
     
        HMAC/SHA1, as defined in Section 4.2.1, is the default and
        mandatory-to-implement message authentication code.
     
     
     5.3 Key Derivation: AES-CM PRF
     
        The AES Counter Mode PRF defined in Sections 4.3.1 and 4.3.2, using
        a 128-bit key, is the default and mandatory-to-implement method for
        generating keys.
     
     
     
     Baugher, et al.                                              [Page 27]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
     
     
     6. SRTP/SRTCP Parameters
     
        The parameters for SRTP are listed in the following. Unless
        otherwise stated, SRTCP by default applies the same transforms and
        parameters of the correspondent SRTP, though they MAY also be
        independently selected.
     
     
        The SRTP-WINDOW-SIZE is defined to be at least 64 (Section 3.2.3).
     
        The current defined modes are Segmented Integer Counter Mode
        (default), f8-mode (Section 4), and the NULL Cipher. The default
        cipher is AES (Section 4), which has a block size of n_b = 128 bits
        and default encryption key size n_e = 128 bits.
     
        The currently defined message authentication functions are the
        HMAC/SHA1 and TMMH. Default is absence of authentication for SRTP
        and HMAC/SHA1 for SRTCP. For HMAC/SHA1, the default key-size is n_a
        = 128 bits and the output length is n_tag = 32 bits.
        SRTP_PREFIX_LENGTH is 0. For TMMH, default n_tag is also 32 bits,
        and default n_a is 752 bits.
     
        The default size of the master key shall be 128 bits, and the
        default size of the master- and session salting keys shall be n_s =
        112 bits.
     
        The default value for the session key_derivation_rate field in the
        cryptographic context is "0", in practice meaning that the first
        application of the key derivation is performed (as it is mandatory),
        but not other further applications of it.
     
     
     7. Adding SRTP Transforms
     
        Section 4 provides examples of the level of details needed for
        defining transforms. Whenever a new transform is to be added to
        SRTP, a companion standards-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 to overlap with the SRTP protocol
        document. Note however, that it might be necessary to extend the
        cryptographic context's definition with new parameters, or add steps
        to the packet processing. The companion RFC shall explain any known
        issues regarding interactions between the transform and other
        aspects of SRTP.
     
        Encryption and message authentication transforms require some set of
        optional parameters or have optional modes of operation. The
        companion RFC shall select fixed or default values for these
        parameters (whenever possible), to reduce key management complexity.
     
     
     
     Baugher, et al.                                              [Page 28]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        The mode of operation of ciphers and related parameters (e.g. IV-
        formation for SRTP and SRTCP) shall be defined.
     
        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 re-keying and key derivation, etc.
     
     
     8. Rationale
     
     8.1 Key derivation
     
       Key derivation has been introduced to lighten the burden on the key
       exchange: the (up to) six different keys necessary to protect the RTP
       session (SRTP and SRTCP encryption keys and salts, SRTP and SRTCP
       authentication keys) are derived from a single master key in a
       cryptographically secure way. Note however that the key management
       protocol may provide SRTP with more than one master key, e.g., two
       distinct master keys with their respective lifetime.
     
        The security stands (and falls) with the master key as the derived
        session keys are cryptographically independent (under reasonable
        assumptions on the PRF, here AES-based).
     
        Subsequent (after the first) applications of the key derivation are
        optional but will give security benefits when enabled. They prevent
        a cryptanalysist from obtaining large amounts of ciphertext produced
        by a single fixed session key. They provide backwards and forward
        security in the sense that a compromised session key does not
        compromise other session keys derived from the same master (but of
        course, a leaked master key reveals all session keys).
     
        Considerations arise with high-rate key-refresh, especially in large
        multi-cast settings, see Section 12.
     
        As the TMMH keys may be quite large, the key derivation provides a
        simple and secure way to obtain sufficient amount of keying
        material.
     
     
     8.2 Salting key
     
        The master salt is introduced to guarantee security against off-line
        key-collision attacks on the key derivation that might otherwise
        reduce the effective key size.
     
        The derived session salting key used in the encryption, has been
        introduced to protect against some attacks on additive stream
        ciphers, see Section 10.2. The explicit inclusion method of the salt
        in the IV has been selected for ease of hardware implementation.
     
     
     
     Baugher, et al.                                              [Page 29]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
     8.3 TMMH: Message Integrity from Universal Hashing
     
        The Truncated Multi-Modular Hash Function (TMMH) is a so-called
        universal hash function family, suitable for message authentication
        in the Wegman-Carter paradigm [WC81]. It is simple, quick, and
        especially appropriate for Digital Signal Processors and other
        processors with a fast multiply operation, though a straightforward
        implementation requires storage equal in length to the largest
        message to be hashed.
     
        TMMH offers secure (provably secure under randomness assumptions on
        the added prefix) and very efficient MACs. For a given tag size
        (TAG_WORDS), the forgery probability can be shown to be upper
        bounded by approximately 2^(-11*TAG_WORDS).
     
        However, as this approach to message integrity is new (not
        conceptually, but within standardization), we have chosen to make
        HMAC the default transform as many devices already have an HMAC
        implementation used for other purposes. We envision a migration to
        TMMH so that HMAC may eventually be phased-out from SRTP.
     
     8.4 Data Origin Authentication Considerations
     
        Note that in unicast, 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 prove the actual sender. 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 message authentication in the pre-defined
        packet-integrity transforms.
     
        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 type of middle entities also disrupt
        end-to-end confidentiality (as the IV formation depends e.g. on the
        RTP header preservation).
     
     
     9. Key Management Considerations
     
        For initialization, the key management needs to be given the SSRC
        and initial RTP sequence-number for the RTP stream, and thus has a
        dependency on RTP operational parameters.
     
     
     
     
     Baugher, et al.                                              [Page 30]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        A particular key management system might allow different RTP
        sessions to share the same cryptographic master keys. The SRTP
        sender and receiver typically share a master key to derive session
        keys for encryption and decryption; SRTCP sources will typically
        derive keys from the same master key used by the SRTP session for
        which sender and receiver reports are sent. This is secure if the
        design of the synchronization mechanism, i.e., the IV, avoids
        keystream re-use (the two-time pad, Section 10.1). If this feature
        is used, the SSRCs MUST be unique between all the RTP streams
        sharing the same master key. In other words, when a master key is
        shared among RTP sessions, SRTP/SRTCP cryptographic transforms are
        vulnerable to unfortunate SSRC collisions owing to normal operation
        of a compliant RTP implementation. SRTCP implementations that share
        master keys introduce a non-standard constraint on RTP operation:
        SSRC values must be unique among RTP sessions that share an SRTP
        master key.  A secure key management system can mitigate this
        problem by assigning SSRC values to SSRC participants at the time of
        master key establishment.
     
        A particular key management system might choose to provide re-key by
        associating a master key for a crypto context with and MKI or a pair
        of index (sequence number and ROC) values, <From, To>. In the latter
        case, such values are always specified, or the default value, 'from
        the first observed packet' and 'until further notice', respectively,
        are used. The key management specification may therefore require the
        SRTP implementation to check the index of an incoming SRTP packet
        against the interval for the master key in the context before using
        the key. An SSRC in an RTP Session, however, defines its own
        sequence number space so knowledge of how many packets have used the
        same master key is dispersed among multiple RTP session
        participants.  SRTP senders can reasonably estimate the amount of
        SRTP and SRTCP traffic being used for a master key and invoke key
        management to re-key if needed. These interactions are defined by
        the key management interface to SRTP and are not defined by this
        protocol specification.
     
        Considerations arise with high-rate re-keying, especially in large
        multi-cast settings, see Section 12.
     
        The key management interface might use the defaults for the SRTP
        protocol or define values for any and all SRTP parameters such as
        the following:
     
        - cipher and related parameters, including mode of operation
        - key(s), i.e., master (and salting) key(s), and related
          parameters,
        - message authentication algorithm(s), and related parameter,
        - re-keying (key lifetime) and key derivation parameters,
        - MKI(s),
        - SSRC, network address, RTP port pair
        - Current value of ROC (or zeros prior to session
     
     
     
     Baugher, et al.                                              [Page 31]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
          commencement) and SEQ
        - Replay window size
     
     
     10. Security Considerations
     
     10.1 SSRC collision and two-time pad
     
        Any fixed keystream output, generated from the same key and index
        should 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. In SRTP, a 'two-
        time pad' is avoided by requiring the key, or some other parameter
        of cryptographic significance, to be unique per RTP stream and
        packet.
     
        The pre-defined SRTP transforms accomplish packet-uniqueness by
        including the packet index. Stream-uniquness require distinct keys,
        or, inclusion of the SSRC, which then (as noted) has to be unique to
        each RTP stream among the RTP sessions sharing the key.
     
        It may in some cases be desirable that multiple crypto contexts
        applied to multiple RTP streams contain identical master keys. For
        instance, there could be a desire for a group to share a single key,
        or, a simple bi-directional flow might want to use the same key in
        both directions. A multi-media sender might desire to use the same
        master key to protect multiple streams. Issues as above (two-time
        pad) MUST then be considered. As discussed in Section 9, the pre-
        defined transforms (AES-CM and AES-f8) allow such sharing by the use
        of the SSRC in the IV. Unlike multiple streams in a single RTP
        session, however, sharing a key among RTP sessions requires the
        added constraint that SSRC values be unique across RTP sessions (see
        Section 9).
     
        Thus, the SSRC MUST be unique between all the RTP streams and
        sessions sharing the same master key. It is incumbent upon SRTP
        implementations to ensure SSRC uniqueness across RTP sessions that
        share a master key, to avoid unfortunate IV combinations and end up
        in two-time pad. Even with distinct SSRCs, extensive use of the same
        key MAY improve chances of probabilistic collision and time-memory-
        tradeoff attacks succeeding.
     
        Also, the effect of an eventual RTP SSRC collision detection MUST be
        taken into account, as a collision could duplicate the SSRC leading
        temporarily to a two-time pad before the collision is detected.  As
        discussed above in Section 9, this is a problem that key management
        can solve.
     
     
     
     
     
     Baugher, et al.                                              [Page 32]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
     10.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,Bi96]. 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, 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 indexes in the pre-defined transforms
        fixes the maximum number of packets that can be secured with the
        same key. Such limit is fixed to 2^48 SRTP packets for SRTP, and
        2^31 SRTCP packets, when SRTP and SRTCP are considered
        independently. However, since the session keys for related SRTP and
        SRTCP are derived from the same master key (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. 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).
     
        Still, note that even at 200 SRTCP packets/sec, the 2^31 index space
        of SRTCP is enough to secure approximately 4 months of
        communication.
     
        Note that the purpose of key derivation only is to limit the amount
        of plaintext that is encrypted with a fixed session key, and made
        available to an attacker for analysis. It 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
     
     
     
     Baugher, et al.                                              [Page 33]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        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 distincness of the packet indicies.
     
        For the TMMH-based message integrity, the keystream prefixes MUST
        NOT be correlated with each other, nor with the messages they
        protect in the sense that given the messages, the prefixes together
        with the TMMH key MUST be computationally indistinguishable from
        random bits. This is assured by our predefined keystream generators
        and key-derivation.
     
     
     10.3 Confidentiality of the RTP Payload
     
        By using 'seekable' stream ciphers, SRTP avoids the denial of
        service attacks that are possible on stream ciphers that lack this
        property (these attacks are described in Section 3.4 of [B96]). 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 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]), knowledge of a few bits of
        the keystream will not aid an attacker in predicting the following
        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).
     
     
     10.4 Confidentiality of the RTP Header
     
        With the described proposal, 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'.
     
        The described proposal 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 the header
        compression is omitted, other solutions might be applicable. In
        other words, we provide a solution that works in the most general
        scenario, even in the most demanding one (like conversational
        multimedia over low-bandwidth, unreliable media). Of course the
        solution will then also work in less restricted environments, but we
     
     
     
     Baugher, et al.                                              [Page 34]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        suggest that 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.
     
     10.5 Integrity of the RTP packet
     
        Additive ciphers do not provide any security service other than
        confidentiality. In particular, they do not provide message
        authentication (see [RK99] or [HAC] for a discussion of this
        security service).
     
        However, SRTP uses a message authentication code to provide that
        security service.
     
        With HMAC being a well-studied authentication scheme, based on a
        provably secure construction, the security against MAC forgery
        depends on the key-size and the size of the output tags (or for some
        attacks, half the size of the tag due to the 'birthday-paradox').
     
        The default size for HMAC has been fixed to 32 bits. Other size
        values may be chosen (via the key management protocol). The use of a
        truncated size is motivated by the fact that it may be desirable,
        e.g., in wireless environments, to save bandwidth. The choice of
        such a truncation MUST be evaluated to the reduction in security it
        implies. The default 32-bit size is a compromise, offering a
        reasonable level of security, taking into account the real-time
        aspects of the protected protocol. High security applications SHOULD
        however use larger tags.
     
        The fact that message authentication is optional (for SRTP) is
        motivated by the fact that, while the function is typically highly
        desired, there are certain cases (notably in cellular environments)
        where it has an impact in terms of cost, e.g. for bandwidth
        consumption. Also, independently of the tag length, a single
        transmission bit error in the protected part of the packet or in the
        tag itself forces the entire packet to be dropped. Given a fixed
        quality of service, it implies the necessity of higher protection of
        the transmitted unit, hence higher cost. In those cases, it is up to
        the user's security profile to request authentication.
     
        The use of error detection mechanism (e.g., Unequal Error Detection,
        UED and UEP) is compatible with SRTP and the pre-defined encryption
        transforms, since stream ciphers maintain the position of the bits.
        However, the use of UED/UEP may be difficult to combine with
        authentication because any bit errors will cause authentication to
        fail.
     
     
     10.5.1 Integrity of the RTP header: IHA
     
     
     
     
     Baugher, et al.                                              [Page 35]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        The IV formation of the f8-mode gives implicit authentication (IHA)
        of the RTP header, even if no cryptographic integrity protection is
        present. This means that modifying bits of the RTP header will cause
        the decryption process at the receiver to produce essentially random
        garbage.
     
     
     11. Interaction with Forward Error Correction mechanisms
     
        Some considerations are due when Forward Error Correction mechanisms
        are performed, e.g., as specified in RFC 2733. In particular, the
        order in which SRTP processing and the error correction processing
        are applied, is of concern.
     
        The optimal order would be the following:
     
        - on the sender side, first encrypt the packet, then perform the FEC
          processing, finally authenticate
     
        - on the receiver side, first authenticate the packet, then perform
          the FEC processing, finally decrypt.
     
        The motivations for the above ordering are:
     
        - FEC expands the packet, so performing encryption after FEC would
          be more expensive
     
        - on the receiver side, authentication has to be verified before
          getting engaged in the FEC processing, to reduce effects of
          certain denial of service attacks
     
        - adding redundancy before encrypting, slightly reduces the
          effective key-size and resistance to attacks.
     
        However, this implies to split the security processing (FEC
        processing occurs between encryption/decryption and authentication).
        Implementations could gain in keeping the security process strictly
        tied, in this case the recommendation is that the security
        processing takes place after FEC on the sender's side, and before
        FEC on the receiver's side. This implies the cost of placing
        encryption after FEC processing, as above explained, hence a
        convenient choice is left to the application. For interoperability
        clearness, implementations are requested to place the security
        process after FEC on the sender's side, and before FEC on the
        receiver's side. This is also default behavior; another choice has
        to be agreed out-of-band.
     
     
     12. Scenarios
     
     
     
     
     Baugher, et al.                                              [Page 36]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        SRTP can be used as security protocol for the RTP/RTCP traffic in
        different scenarios. SRTP has a number of configuration options, and
        can have impact on the total performance of the application
        according to the way it is used. Hence, it appears that the use of
        SRTP is very 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.
     
     
     12.1 Two-party Unicast
     
     12.1.1 One bi-directional RTP stream
     
        A typical example would be a voice call, or perhaps some streaming
        application.
     
        It is possible for the two parties to share the same master key in
        the two directions. 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, and SRTCP_encr_key, 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 unspecified lifetime (i.e. unrestricted key
        lifetime, not using explicit <From, To> values). 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 without problems. 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 two-party unicast
        scenario with multiple RTP sessions sharing the master key if
        particular care is taken to guarantee unique SSRCs for the streams.
     
     
     12.1.2 One master key per party
     
        Here, each sender provides the security for its own RTP and RTCP
        streams, as well as for the RTCP receiver reports sent back to him.
        This will turn out into two master keys, split (by key derivation)
        into a maximum of eight session keys (on each side of the
        communication link). The SSRC-uniqueness MUST be guaranteed for the
        streams on each side. It is recommended not to restrict the master
        key lifetimes using the <From, To> fields. This anyway gives in most
        cases a sufficient key lifetime, with the benefit of a minimum set
     
     
     
     Baugher, et al.                                              [Page 37]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        of keys in place, and a smooth run of SRTCP. The same storage
        considerations as above apply for the optional key derivation.
     
        The same considerations can be extended to the two-party unicast
        scenario with multiple mono-directional RTP sessions. Unique SSRCs
        MUST be guaranteed to the streams.
     
     
     12.2 Multicast
     
        Just as with (unprotected) RTP, a scalability issue arises in big
        groups due to the possibly very large amount of (S)RTCP 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 problem increases proportionally to the size of the
        group. In particular, re-keying requires special concern, see below.
     
        We describe in the following multicast for small groups, and give
        guidelines for use with large group multicast.
     
     
     12.2.1 Small conference with one sender
     
        The sender secures his RTP stream using one cryptographic context.
        The sender's RTP and RTCP is secured with the same master key. Key
        derivation gives the necessary session keys, i.e.
     
        SRTP_encr_key, SRTP_auth_key, and SRTCP_encr_key,  SRTCP_auth key.
     
        If the streams are multiple, the SSRCs MUST as noted be unique to
        avoid two-time pad (see Section 9). Key derivation may (for
        increased security) be enabled for the sender’s outgoing SRTP
        streams.
     
        There are many possible setups with the distribution of the master
        keys.
     
        One possibility is that the receivers share the same master key to
        secure their respective SRTCP (this requires the receivers to trust
        each other). This shared master key could be the same used by the
        sender to protect its outcoming traffic. Alternatively, it could be
        a master key shared only among the receivers and used solely for
        their SRTCP.
     
        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
        in time, as the SRTCP sources send at different times). Thus, in
        case key derivation is wanted for SRTP, the cryptographic context
     
     
     
     Baugher, et al.                                              [Page 38]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        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.
     
        Re-keying gives two problems: the number of master keys stored a the
        sender side, and re-keying triggering. Forcing re-keying using the
        <From, To> fields creates the problem that the sender needs to
        maintain multiple keys, as the re-keying will typically happen at
        different times on each SRTCP stream from the receivers (because
        each SSRC defines a sequence number space). Also, problems may occur
        in retrieving the current master key for the SRTCP packets in some
        cases, since that is done based on SRTP index, not SRTCP index.  Use
        of the MKI for re-keying is probably best for most applications (see
        Section 9).
     
        Moreover, the upper limit of 2^48 SRTP packets / 2^31 RTCP packets
        means that, as soon as (or rather, shortly before) one of the stream
        reaches such maximum number of packets, re-keying MUST be triggered
        on ALL the streams. A possible solution to this, may be to keep the
        SRTP/SRTCP contexts separated, but still sharing master key. The
        sender then has to estimate which stream (among the sender's
        SRTP/SRTCP streams and the receiver's SRTCP streams) that will first
        reach the 2^48 / 2^31 limit, and well in advance force a re-keying.
        The MKI or <From, To> may be employed for key synchronization during
        changeover to a new key. Use of <From, To> fields to obtain key-
        synchonization in such case is described in Section 12.3.
     
     
     12.2.2 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 receive reports.
        At minimum, a replay window might be maintained for each RTCP
        source. Therefore, with big groups and where the load at the sender
        is considered not acceptable, it might be an option to simply
        disable all security for RTCP. This is STRONGLY NOT RECOMMENDED from
        a security point of view, but may appear a reasonable compromise to
        have at least security guaranteed on the RTP traffic.
     
        Alternatively, an SRTCP receiver may choose not to authenticate or
        protect against replay for SRTCP messages or do so selectively
        (e.g., only messages containing sender reports are authenticated).
        Of course, security impacts of neglecting to authenticate certain
        packets MUST be carefully considered.
     
     
     12.3 Re-keying and access control
     
     
     
     
     Baugher, et al.                                              [Page 39]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        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. As mentioned, the master key MUST be replaced before any of
        the index spaces (2^48 for SRTP, 2^31 for SRTCP) are exhausted for
        any of the streams protected by one and the same master key. Thus,
        there is always the necessity of keeping track of when the master
        key has to be replaced due to exhaustion of the index spaces. In
        addition to this, it is possible to control the master key lifetime
        using the <From, To> fields, which could mean that a key expires,
        and a new one is needed.
     
        One may choose to have key management provide at the start, arrays
        of master keys with associated lifetimes. Alternatively, key
        management is called each time the master key has to be changed.
     
        In one-sender multicast, it is responsibility of the sender to
        determine when a new key is needed. The sender is the only one 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 other scenarios other than one-
        sender multicast, it is recommended that the Initiator of the key
        management/session requires new key material well before any stream
        reaches the maximum key lifetime. 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 in a new master key shared with the
        reciever(s). To maintain synchronization when switching to the new
        key, one could use the MKI or assign the new master key a 'valid-
        from' index, far enough into the future so that key management will
        be finished before that, but still before the current key is
        exhausted.
     
        For access control purposes, the <From, To> periods are set at the
        desired granularity, dependent on the packet rate. High rate re-
        keying SHOULD NOT be used in some large-group scenarios when SRTCP
        is enabled. This is an effect of 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. Therfore, using the MKI for re-keying in such
        scenarios is the recommended method.
     
        Note that even if the MKI is used to signal key-usage to the
        receiver, there might still be cases when the <From,To> fields are
        also in use at the same time. For instance, a From-value could be
        used to signal when a certain master key (MKI) is to be activated
        for the first time.
     
     
     
     
     
     Baugher, et al.                                              [Page 40]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
     12.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 SRTP for fast re-keying using 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 share the same master key, also moderate
          rate re-keying MAY have the same problems, and the MKI SHOULD be
          used.
     
        - Carefully consider the additional load at the sender side in
          multicast scenarios. Optionally, but NOT RECOMMENDED, SRTCP could
          be disabled altogether by the SRTCP receiver.
     
        - 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.
     
     
     13. 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".
     
     
     14. Acknowledgements
     
        The authors would like to thank Magnus Westerlund, Brian Weis,
        Robert Fairlie-Cuninghame, and Adrian Perrig for their reviews and
        comments.
     
     
     15. Author's Addresses
     
        Questions and comments should be directed to the authors and
        avt@ietf.org:
     
     
           Mark Baugher
           Cisco Systems, Inc.
           5510 SW Orchid Street     Phone:  +1 408-853-4418
           Portland, OR 97219 USA    Email:  mbaugher@cisco.com
     
           Rolf Blom
     
     
     
     Baugher, et al.                                              [Page 41]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
           Ericsson Research
           SE-16480 Stockholm     Phone:  +46 8 58531707
           Sweden                 EMail:  rolf.blom@era.ericsson.se
     
           Elisabetta Carrara
           Ericsson Research
           SE-16480 Stockholm     Phone:  +46 8 50877040
           Sweden                 EMail:  elisabetta.carrara@era.ericsson.se
     
           David A. McGrew
           Cisco Systems, Inc.
           San Jose, CA 95134-1706   Phone:  +1 301-349-5815
           USA                       EMail:  mcgrew@cisco.com
     
           Mats Naslund
           Ericsson Research
           SE-16480 Stockholm     Phone:  +46 8 58533739
           Sweden                 EMail:  mats.naslund@era.ericsson.se
     
           Karl Norrman
           Ericsson Research
           SE-16480 Stockholm     Phone:  +46 8 4044502
           Sweden                 EMail:  karl.norrman@era.ericsson.se
     
           David Oran
           Cisco Systems, Inc.
           San Jose, CA 95134-1706
           USA                       EMail:  oran@cisco.com
     
     
     16. References
     
        Normative
     
        [AES] NIST, "Advanced Encryption Standard (AES)", FIPS PUB 197,
              http://www.nist.gov/aes/
     
        [HMAC] Krawczyk, H., Bellare, M., and Canetti, R.: "HMAC: Keyed-
              hashing for message authentication". IETF RFC 2104, February
              1997.
     
        [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., Jacobson,V.,
                "RTP: A Transport Protocol for Real-Time Applications", IETF
                RFC 1889.
     
        [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", IETF RFC 2119, March 1997.
     
        [RFC2401] Kent, S., and R. Atkinson, "Security Architecture for IP",
               IETF RFC 2401, November 1998.
     
     
     
     
     Baugher, et al.                                              [Page 42]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        [RFC2675] Borman, D., Deering, S., Hinden, R., "IPv6 Jumbograms",
               IETF RFC 2675, August 1999.
     
        [RFC2828] Shirey, R., "Internet Security Glossary", IETF RFC 2828,
                 May 2000.
     
     
       Informative
     
        [BDJR] Bellare, M., Desai, A., Jokipii, E., and Rogaway, P.,
               "A Concrete Treatment of Symmetric Encryption: Analysis of
                 DES Modes of Operation", Proceedings 38th IEEE FOCS,
               pp. 394-403, 1997.
     
        [C99]  Crowell, W. P., "Introduction to the VENONA Project",
               http://www.nsa.gov:8080/docs/venona/index.html.
     
        [CTR] Morris Dworkin, NIST Special Publication 800-38A,
              "Recommendation for Block Cipher Modes of Operation: Methods
              and Techniques",  2001.  Online at
              http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-
              38a.pdf.
     
        [ES3D] ETSI SAGE 3GPP Standard Algorithms Task Force, "Security
               Algorithms Group of Experts (SAGE); General Report on the
               Design, Specification and Evaluation of 3GPP Standard
               Confidentiality and Integrity Algorithms", Public report,
               Draft Version 1.0, Dec 1999.
     
        [ES3E] ETSI SAGE 3GPP Standard Algorithms Task Force, "Security
               Algorithms Group of Experts (SAGE) Report on the Evaluation
               of 3GPP Standard Confidentiality and Integrity Algorithms",
               Public report, Draft Version 1.0, Dec 1999.
     
        [HAC]  Menezes, A., Van Oorschot, P., and Vanstone, S., "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.
     
        [KSYH] Kang, J-S., Shin, S-U., Hong, D., and Yi, O., “Provable
               Security of KASUMI and 3GPP Encryption Mode f8”,
               Proceedings Asiacrypt 2001, Springer Verlag LNCS 2248,
               pp. 255-271, 2001.
     
        [MF00] McGrew, D., and Fluhrer, S., "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.
     
     
     
     
     Baugher, et al.                                              [Page 43]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
     
        [RK99] Rescorla, E., and Korver, B., "Guidelines for Writing RFC
              Text on Security Considerations," draft-rescorla-sec-cons-
              00.txt
     
        [PCST1] Perrig, A., Canetti, R., Tygar, D., Song, D., "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., Song, D., "Efficient
                Authentication and Signing of Multicast Streams over Lossy
               Channels", in Proc. of IEEE Security and Privacy Symposium
               S&P2000, pp. 56-73, 2000.
     
        [WC81] M. N. Wegman and J. L. Carter, "New Hash Functions and Their
              Use in Authentication and Set Equality", JCSS 22, 265-279,
              1981.
     
     
     
     Appendix A: Pseudocode for Index Determination
     
        The following is an example of pseudocode for the algorithm to
        process an SRTP packet with sequence number SEQ and estimating its
        index i. 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
     
     B.1 AES-f8 Test Vectors
     
        All values are in hexadecimal.
     
     
     
     
     Baugher, et al.                                              [Page 44]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        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
     
        j                   :   0
        IV' XOR j           :   595b699bbd3bc0df26062093c1ad8f73
        S(-1)               :   00000000000000000000000000000000
        S(-1) XOR IV' XOR j :   595b699bbd3bc0df26062093c1ad8f73
        S(0)                :   71ef82d70a172660240709c7fbb19d8e
        plaintext           :   70736575646f72616e646f6d6e657373
        ciphertext          :   019ce7a26e7854014a6366aa95d4eefd
     
        j                   :   1
        IV' XOR j           :   595b699bbd3bc0df26062093c1ad8f72
        S(0)                :   71ef82d70a172660240709c7fbb19d8e
        S(0) XOR IV' XOR j  :   28b4eb4cb72ce6bf020129543a1c12fc
        S(1)                :   3abd640a60919fd43bd289a09649b5fc
        plaintext           :   20697320746865206e65787420626573
        ciphertext          :   1ad4172a14f9faf455b7f1d4b62bd08f
     
        j                   :   2
        IV' XOR j           :   595b699bbd3bc0df26062093c1ad8f70
        S(1)                :   3abd640a60919fd43bd289a09649b5fc
        S(1) XOR IV' XOR j  :   63e60d91ddaa5f0b1dd4a93357e43a8c
        S(2)                :   584d14a591acfca846b3aa3a0ab50fec
        plaintext           :   74207468696e67
        ciphertext          :   2c6d60cdf8c29b
     
     
     
     B.2 AES-CM Test Vectors
     
        Keystream segment length: 1044512 octets (65282 AES blocks)
        Key:              2B7E151628AED2A6ABF7158809CF4F3C
        Rollover Counter: 00000000
        Sequence Number:  0000
        SSRC:             00000000
        Salt:             F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000
     
     
     
     Baugher, et al.                                              [Page 45]
     

     INTERNET-DRAFT                    SRTP                  February, 2002
     
     
        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].
     
     
     B.3 TMMH Test Vectors
     
        This section provides test vectors which can be used to test an
        implementation of TMMH. The key, message, and outputs are expressed
        as octet sequences, with each octet in hexadecimal.
     
           TAG_WORDS: 2
           key:     { e627 6a01 5ea7 f27a c536 2192 11be ea35
                      db9d 63d6 fa8a fc45 e08b d216 ced2 7853
                      1a82 22f5 90fb 1c29 708e d06f 82c3 bee6
                      4f21 6f33 65c0 d211 c25e 9138 4fa3 7c1f
                      61ac 3489 2976 8c19 8252 ddbf cad3 c28f
                      68d6 58dd 504f 2bbf 0278 70b7 cfca }
           L:       { e627 6a01 }
           A[0]:    { 5ea7 f27a c536 2192 11be ea35 db9d 63d6 fa8a }
           A[1]:    { fc45 e08b d216 ced2 7853 1a82 22f5 90fb 1c29 }
           A[2]:    { 708e d06f 82c3 bee6 4f21 6f33 65c0 d211 c25e }
           A[3]:    { 9138 4fa3 7c1f 61ac 3489 2976 8c19 8252 ddbf }
           A[4]:    { cad3 c28f 68d6 58dd 504f 2bbf 0278 70b7 cfca }
           message: { 6015 f141 5ba1 29a0 f604 0d1c 02d9 aa8a 7931 }
           tag:     { 8a82 4bb0 }
     
     
     
     
     
     
     
     
     
     
     
        This Internet-Draft expires in July 2002.
     
     
     
     
     Baugher, et al.                                              [Page 46]
     

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/