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

Versions: 00 01 02 03 04 05 06 draft-ietf-avt-srtp-ekt

Network Working Group                                          D. McGrew
Internet-Draft                                              F. Andreasen
Intended status: Standards Track                     Cisco Systems, Inc.
Expires: September 2, 2007                                    L. Dondeti
                                                                QUALCOMM
                                                              March 2007


                 Encrypted Key Transport for Secure RTP
                      draft-mcgrew-srtp-ekt-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 2, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).












McGrew, et al.          Expires September 2, 2007               [Page 1]

Internet-Draft                  EKT SRTP                      March 2007


Abstract

   SRTP Encrypted Key Transport (EKT) is an extension to SRTP that
   provides for the secure transport of SRTP master keys, Rollover
   Counters, and other information, within SRTCP.  This facility enables
   SRTP to work for decentralized conferences with minimal control, and
   to handle situations caused by SIP forking and early media.












































McGrew, et al.          Expires September 2, 2007               [Page 2]

Internet-Draft                  EKT SRTP                      March 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Conventions Used In This Document  . . . . . . . . . . . .  5
   2.  Encrypted Key Transport  . . . . . . . . . . . . . . . . . . .  6
     2.1.  Authentication Tag Format  . . . . . . . . . . . . . . . .  6
     2.2.  Packet Processing and State   Machine  . . . . . . . . . .  8
       2.2.1.  Outbound (Tag Generation)  . . . . . . . . . . . . . .  8
       2.2.2.  Inbound (Tag Verification) . . . . . . . . . . . . . .  9
     2.3.  Ciphers  . . . . . . . . . . . . . . . . . . . . . . . . . 12
       2.3.1.  The Default Cipher . . . . . . . . . . . . . . . . . . 13
       2.3.2.  The AES Key Wrap Cipher  . . . . . . . . . . . . . . . 13
       2.3.3.  Other EKT Ciphers  . . . . . . . . . . . . . . . . . . 14
     2.4.  Synchronizing Operation  . . . . . . . . . . . . . . . . . 14
     2.5.  Timing and Reliability Consideration . . . . . . . . . . . 15
   3.  EKT and SDP Security Descriptions  . . . . . . . . . . . . . . 16
     3.1.  SDP Security Descriptions Recap  . . . . . . . . . . . . . 16
     3.2.  Relationship between EKT and SDP Security Descriptions . . 17
     3.3.  Overview of Combined EKT and SDP Security Description
           Operation  . . . . . . . . . . . . . . . . . . . . . . . . 19
     3.4.  EKT Extensions to SDP Security Descriptions  . . . . . . . 19
       3.4.1.  EKT_Cipher . . . . . . . . . . . . . . . . . . . . . . 19
       3.4.2.  EKT_Key  . . . . . . . . . . . . . . . . . . . . . . . 20
       3.4.3.  EKT_SPI  . . . . . . . . . . . . . . . . . . . . . . . 20
     3.5.  Offer/Answer Procedures  . . . . . . . . . . . . . . . . . 20
       3.5.1.  Generating the Initial Offer - Unicast Streams . . . . 20
       3.5.2.  Generating the Initial Answer - Unicast Streams  . . . 22
       3.5.3.  Processing of the Initial Answer - Unicast Streams . . 23
     3.6.  SRTP-Specific Use Outside Offer/Answer . . . . . . . . . . 24
     3.7.  Modifying the Session  . . . . . . . . . . . . . . . . . . 24
     3.8.  Backwards Compatibility Considerations . . . . . . . . . . 24
     3.9.  Grammar  . . . . . . . . . . . . . . . . . . . . . . . . . 25
   4.  Use of EKT with MIKEY  . . . . . . . . . . . . . . . . . . . . 26
     4.1.  EKT transform attribute mapping in MIKEY . . . . . . . . . 26
   5.  Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 29
   6.  RTP Transport  . . . . . . . . . . . . . . . . . . . . . . . . 31
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 32
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 35
     10.2. Informative References . . . . . . . . . . . . . . . . . . 36
   Appendix A.  Alternate Format  . . . . . . . . . . . . . . . . . . 37
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
   Intellectual Property and Copyright Statements . . . . . . . . . . 40






McGrew, et al.          Expires September 2, 2007               [Page 3]

Internet-Draft                  EKT SRTP                      March 2007


1.  Introduction

   RTP is designed to allow decentralized groups with minimal control to
   establish sessions, e.g. for multimedia conferences.  Unfortunately,
   Secure RTP (SRTP, [RFC3711]) cannot be used in many minimal-control
   scenarios, because it requires that SSRC values and other data be
   coordinated among all of the participants in a session.  For example,
   if a participant joins a session that is already in progress, the
   SRTP rollover counter (ROC) of each SRTP source in the session needs
   to be provided to that participant.

   The inability of SRTP to work in the absence of central control was
   well understood during the design of that protocol; that omission was
   considered less important than optimizations such as bandwidth
   conservation.  Additionally, in many situations SRTP is used in
   conjunction with a signaling system that can provide most of the
   central control needed by SRTP.  However, there are several cases in
   which conventional signaling systems cannot easily provide all of the
   coordination required.  It is also desirable to eliminate the layer
   violations that occur when signaling systems coordinate certain SRTP
   parameters, such as SSRC values and ROCs.

   This document defines Encrypted Key Transport (EKT) for SRTP, an
   extension to SRTP that fits within the SRTP framework and reduces the
   amount of signaling control that is needed in an SRTP session.  EKT
   securely distributes the SRTP master key and other information for
   each SRTP source, using SRTCP to transport that information.  With
   this method, SRTP entities are free to choose SSRC values as they see
   fit, and to start up new SRTP sources with new SRTP master keys (see
   Section 2.2) within a session without coordinating with other
   entities via signaling or other external means.  This fact allows to
   reinstate the RTP collision detection and repair mechanism, which is
   nullified by the current SRTP specification because of the need to
   control SSRC values closely.  An SRTP endpoint using EKT can generate
   new keys whenever an existing SRTP master key has been overused, or
   start up a new SRTP source to replace an old SRTP source that has
   reached the packet-count limit.  EKT also solves the problem in which
   the burst loss of the N initial SRTP packets can confuse an SRTP
   receiver, when the initial RTP sequence number is greater than or
   equal to 2^16 - N. These features simplify many architectures that
   implement SRTP.

   EKT provides a way for an SRTP session participant, either sender or
   receiver, to securely transport its SRTP master key and current SRTP
   rollover counter to the other participants in the session.  This
   data, possibly in conjunction with additional data provided by an
   external signaling protocol, furnishes the information needed by the
   receiver to instantiate an SRTP/SRTCP receiver context.



McGrew, et al.          Expires September 2, 2007               [Page 4]

Internet-Draft                  EKT SRTP                      March 2007


   EKT does not control the manner in which the SSRC and master key are
   generated; it is concerned only with their secure transport.  Those
   values may be generated on demand by the SRTP endpoint, or may be
   dictated by an external mechanism such as a signaling agent or a
   secure group controller.

   EKT is not intended to replace external key establishment mechanisms
   such as SDP Security Descriptions [SDES] or MIKEY [RFC3830].
   Instead, it is used in conjunction with those methods, and it
   relieves them of the burden of tightly coordinating every SRTP source
   among every SRTP participant.

   This document is organized as follows.  A complete normative
   definition of EKT is provided in Section 2.  It consists of packet
   processing algorithms (Section 2.2) and cryptographic definitions
   (Section 2.3) .  In Section 3, the use of EKT with SDP Security
   Descriptions is defined.  In Section 4 we outline the use of EKT with
   MIKEY.  Section 5 provides a design rationale.  Security
   Considerations are provided in Section 7, and IANA considerations are
   provided in Section 8.

1.1.  Conventions Used In This Document

   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].

























McGrew, et al.          Expires September 2, 2007               [Page 5]

Internet-Draft                  EKT SRTP                      March 2007


2.  Encrypted Key Transport

   In EKT, an SRTP master key is encrypted with a Key Encrypting Key
   (KEK), and the resulting ciphertext is transported in every SRTCP
   packet.  A single KEK suffices for a single SRTP session, regardless
   of the number of participants in the session.  However, there can be
   multiple KEKs used within a particular session.

   In order to convey the ciphertext of the SRTP master key, and other
   additional information, the SRTCP Authentication Tag field is
   subdivided as shown in Figure 1.  EKT defines a new SRTCP
   authentication function, which uses this format.  It incorporates a
   conventional SRTCP authentication function, which is called the base
   authentication function in this specification.  Any SRTCP
   authentication function, such as the default one of HMAC-SHA1 with a
   160-bit key and an 80-bit authentication tag, can be used as a base
   authentication function.  EKT also defines a new method of providing
   SRTP master keys to an endpoint.

       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                   Base Authentication Tag                     :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                     Encrypted Master Key                      :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Rollover Counter                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Initial Sequence Number    |   Security Parameter Index    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 1: The EKT Authentication Tag format.

2.1.  Authentication Tag Format

   The Authentication Tag field contains the following sub-fields:

   Base Authentication Tag  This field contains the authentication tag
      computed by the base authentication function.  The value of this
      field is used to check the authenticity of the packet.

   Encrypted Master Key  The length of this field is variable, and is
      equal to the ciphertext size N defined in Section 2.3.  Note that
      the length of the field is inferable from the SPI field, since the
      particular EKT cipher used by the sender of a packet is inferable
      from that field.  The Encrypted Master Key field is included
      outside of the authenticated portion of the SRTCP packet,
      immediately following the Authentication Tag. It contains the



McGrew, et al.          Expires September 2, 2007               [Page 6]

Internet-Draft                  EKT SRTP                      March 2007


      ciphertext value resulting from the encryption of the SRTP master
      key corresponding to the SSRC contained in the packet.  The
      encryption and decryption of this value is done using a cipher as
      defined in Section 2.3.

   Rollover Counter  The length of this field is fixed at 32 bits.  This
      field is set to the current value of the SRTP rollover counter in
      the SRTP context associated with the SSRC in the SRTCP packet.
      This field immediately follows the Encrypted Master Key field.

   Initial Sequence Number (ISN)  The length of this field is fixed at
      16 bits.  If this field is nonzero, then it indicates the RTP
      sequence number of the initial RTP packet that is protected using
      the SRTP master key conveyed (in encrypted form) by the Encrypted
      Master Key field of this packet.  If this field is zero, it
      indicates that the initial RTP packet protected using the SRTP
      master key conveyed in this packet preceded, or was concurrent
      with, the last roll-over of the RTP sequence number.  The ISN
      field follows the Rollover Counter field.

   Security Parameter Index (SPI)  The length of this field is fixed at
      16 bits.  This field indicates the appropriate Key Encrypting Key
      and other parameters for the receiver to use when processing the
      packet.  It is an "index" into a table of possibilities (which are
      established via signaling or some other out-of-band means), much
      like the IPsec Security Parameter Index [RFC4301].  The parameters
      that are identified by this field are:

         The Key Encrypting Key used to process the packet.

         The EKT cipher used to process the packet.

         The Secure RTP parameters associated with the SRTP Master Key
         carried by the packet and the SSRC value in the packet.
         Section 8.2. of [RFC3711] summarizes the parameters defined by
         that specification.

      Together, these elements are called an EKT parameter set.  Within
      each SRTP session, each distinct EKT parameter set that may be
      used MUST be associated with a distinct SPI value, to avoid
      ambiguity.  The SPI field follows the Initial Sequence Number.
      Since it is the last field in the packet, and has a fixed length,
      it is always possible to unambiguously parse this field.








McGrew, et al.          Expires September 2, 2007               [Page 7]

Internet-Draft                  EKT SRTP                      March 2007


2.2.  Packet Processing and State   Machine

   At any given time, each SRTP/SRTCP source has associated with it a
   single EKT parameter set.  This parameter set is used to process all
   outbound packets, and is called the outbound parameter set.  There
   may be other EKT parameter sets that are used by other SRTP/SRTCP
   sources in the same session.  All of these EKT parameter sets SHOULD
   be stored by all of the participants in an SRTP session, for use in
   processing inbound SRTCP traffic.

   We next review the SRTCP authentication method and show how the EKT
   authentication method is built on top of the base method.  An SRTCP
   authentication method consists of a tag-generation function and a
   verification function.  The tag-generation function takes as input a
   secret key, the data to be authenticated, and the SRTCP packet index.
   It provides an authentication tag as its sole output, and is used in
   the processing of outbound packets.  The verification function takes
   as input a secret key, the data to be authenticated, the SRTCP packet
   index, and the authentication tag.  It returns an indication of
   whether or not the data, index, and tag are valid or not.  It is used
   in the processing of inbound packets.  EKT defines a tag-generation
   function in terms of the base tag-generation function, and defines a
   verification function in terms of the base verification function.
   The tag-generation function is used to process outbound packets, and
   the verification function is used to process inbound packets.

2.2.1.  Outbound (Tag Generation)

   When an SRTCP packet needs to be sent, the EKT tag generation
   function works as follows.  Given an RTCP packet, the Rollover
   Counter field in the SRTCP packet is set to the current value of the
   SRTP rollover counter (represented as an unsigned integer in network
   byte order).

   The Initial Sequence Number field is set to zero, if the initial RTP
   packet protected using the current SRTP master key for this source
   preceded, or was concurrent with, the last roll-over of the RTP
   sequence number.  Otherwise, that field is set to the value of the
   RTP sequence number of the initial RTP packet that was or will be
   protected by that key.  When the SRTP master key corresponding to a
   source is changed, the new key SHOULD be communicated in advance via
   EKT.  (Note that the ISN field allows the receiver to know when it
   should start using the new key to process SRTP packets.)  This
   enables the rekeying event to be communicated before any RTP packets
   are protected with the new key.  The rekeying event MUST not change
   the value of ROC (otherwise, the current value of the ROC would not
   be known to late joiners of existing sessions).




McGrew, et al.          Expires September 2, 2007               [Page 8]

Internet-Draft                  EKT SRTP                      March 2007


   The Security Parameter Index field is set to the value of the
   Security Parameter Index that is associated with the outbound
   parameter set.

   The Encrypted Master Key field is set to the ciphertext created by
   encrypting the SRTP master key with the EKT cipher, using the KEK as
   the encryption key.  The encryption process is detailed in
   Section 2.3.  Implementations MAY cache the value of this field to
   avoid recomputing it for each packet that is sent.

2.2.1.1.  Base Authentication Tag

   The Base Authentication Tag field is computed using the base tag-
   generation function as follows.  It can only be computed after all of
   the other fields have been set.  The authenticated input consists of
   the following elements, in order:

      the SRTCP authenticated portion,

      a string of zero bits whose length exactly matches that of the
      Base Authentication Tag field,

      the Encrypted Master Key field,

      the Rollover Counter field,

      the Initial Sequence Number field, and

      the Security Parameter Index field.

      Implementation note: the string of zero bits is included in the
      authenticated input in order to allow implementations to compute
      the base authentication tag using a single pass of the base
      authentication function.  Implementations MAY write zeros into the
      Base Authentication Tag field prior to computing that function, on
      the sending side.

2.2.2.  Inbound (Tag Verification)

   The EKT verification function proceeds as follows (see Figure 2), or
   uses an equivalent set of steps.  Recall that the verification
   function is a component of SRTCP processing.  When a packet does not
   pass the verification step, the function indicates this fact to the
   SRTCP packet processing function when it returns control to that
   function.






McGrew, et al.          Expires September 2, 2007               [Page 9]

Internet-Draft                  EKT SRTP                      March 2007


   1.  The Security Parameter Index field is checked to determine which
       EKT parameter set should be used when processing the packet.  If
       multiple parameter sets been defined for the SRTP session, then
       the one that is associated with the Security Parameter Index
       value that matches the Security Parameter Index field in the
       packet is used.  This parameter set is called the matching
       parameter set below.  If there is no matching SPI, then the
       verification function MUST return an indication of authentication
       failure, and the steps described below are not performed.

   2.  The Encrypted Master Key field is decrypted using the EKT
       cipher's decryption function.  That field is used as the
       ciphertext input, and the Key Encrypting Key in the matching
       parameter set is used as the decryption key.  The decryption
       process is detailed in Section 2.3.  The plaintext resulting from
       this decryption is provisionally accepted as the SRTP master key
       corresponding to the SSRC in the packet.  If an MKI is present in
       the packet, then the provisional key corresponds to the
       particular SSRC and MKI combination.  A provisional key MUST be
       used only to process one single packet.  A provisional SRTCP
       authentication key is generated from the provisional master key,
       and the SRTP master salt from the matching parameter set, using
       the SRTP key derivation algorithm (see Section 4.3 of [RFC3711]).

   3.  An authentication check is performed on the packet, using the
       provisional SRTCP authentication key.  This key is provided to
       the base SRTCP authentication function (see Figure 2), which is
       evaluated as described in Section 2.2.1.1.  If the Base
       Authentication Tag field matches the tag computed by the base
       authentication function, then the packet passes the check.

          Implementation note: an SRTP receiver MAY copy the Base
          Authentication Tag field into temporary storage, then write
          zeros into that field, prior to computing the base
          authentication tag value.  This step allows the base
          authentication function to be computed in a single pass.

   4.  If the base authentication check using the provisional key fails,
       then the provisional key MUST be discarded and it MUST NOT affect
       any subsequent processing.  The verification function MUST return
       an indication of authentication failure, and the steps described
       below are not performed.

   5.  Otherwise, if the base authentication check is passed, the
       provisional key is also accepted as the SRTP master key
       corresponding to the SRTP source that sent the packet.  If an MKI
       is present in the packet, then the master key corresponds to the
       particular SSRC and MKI combination.  If there is no SRTP crypto



McGrew, et al.          Expires September 2, 2007              [Page 10]

Internet-Draft                  EKT SRTP                      March 2007


       context corresponding to the SSRC in the packet, then a new
       crypto context is created.  The rollover counter in the context
       is set to the value of the Rollover Counter field.

   6.  If the Initial Sequence Number field is nonzero, then the initial
       sequence number for the SRTP master key is set to the packet
       index created by appending that field to the current rollover
       counter and treating the result as a 48-bit unsigned integer.
       The initial sequence number for the master key is equivalent to
       the "From" value of the < From, To > pair of indices (Section
       8.1.1 of [RFC3711]) that can be associated with a master key.

   7.  The newly accepted SRTP master key, the SRTP parameters from the
       matching parameter set, the SSRC from the packet, and the MKI
       from the packet, if one is present, are stored in the crypto
       context associated with the SRTP source.  The SRTP Key Derivation
       algorithm is run in order to compute the SRTP encryption and
       authentication keys, and those keys are stored for use in SRTP
       processing of inbound packets.

   8.  The verification function then returns an indication that the
       packet passed the verification.

          Implementation note: the value of the Encrypted Master Key
          field is identical in successive packets protected by the same
          KEK and SRTP master key.  This value MAY be cached by an SRTP
          receiver to minimize computational effort, by allowing it to
          recognize when the SRTP master key is unchanged, and thus
          avoid repeating Steps 2, 6, and 7.






















McGrew, et al.          Expires September 2, 2007              [Page 11]

Internet-Draft                  EKT SRTP                      March 2007


                +------- Encrypted Master Key
                |
                v
          +------------+
          | Decryption |
          |  Function  |<-------------------------- Key Encrypting Key
          +------------+
                |                    +----------------+     EKT
       +--------+-- provisional ---->|     SRTCP      |<--  master
       |            master key       | Key Derivation |     salt
       |                             +----------------+
       |                                     |
       |                    provisional SRTCP authentication key
       |                                     |
       |                                     v
       |                             +----------------+
       |   authenticated portion --> |   Base SRTCP   |
       |   authentication tag -----> |  Verification  |
       |                             +----------------+
       |                                     |
       |        +----------------+         +---+
       |        |  return FAIL   |<- FAIL -| ? |
       |        +----------------+         +---+
       |                                     |
       |        +----------------+           |
       +------->| set master key,|<- PASS ---+
                | ROC, and MKI   |
                +----------------+
                        |
                        v
                +----------------+
                |  return PASS   |
                +----------------+

                     Figure 2: EKT inbound processing.

2.3.  Ciphers

   EKT uses a cipher to encrypt the SRTP master keys.  We first specify
   the interface to the cipher, in order to abstract the interface away
   from the details of that function.  We then define the cipher that is
   used in EKT by default.  This cipher MUST be implemented, but another
   cipher that conforms to this interface MAY be used, in which case its
   use MUST be coordinated by external means (e.g. call signaling).

   An EKT cipher consists of an encryption function and a decryption
   function.  The encryption function E(K, P) takes the following
   inputs:



McGrew, et al.          Expires September 2, 2007              [Page 12]

Internet-Draft                  EKT SRTP                      March 2007


      a secret key K with a length of L bytes, and

      a plaintext value P with a length of M bytes.

   The encryption function returns a ciphertext value C whose length is
   N bytes, where N is at least M. The decryption function D(K, C) takes
   the following inputs:

      a secret key K with a length of L bytes, and

      a ciphertext value C with a length of N bytes.

   The decryption function returns a plaintext value P that is M bytes
   long.  These functions have the property that D(K, E(K, P)) = P for
   all values of K and P. Each cipher also has a limit T on the number
   of times that it can be used with any fixed key value.  For each key,
   the encryption function MUST NOT be invoked on more than T distinct
   values of P, and the decryption function MUST NOT be invoked on more
   than T distinct values of C.

   An EKT cipher MUST resist attacks in which both ciphertexts and
   plaintexts can be adaptively chosen.  For each randomly chosen key,
   the encryption and decryption functions cannot be distinguished from
   a random permutation and its inverse with non-negligible advantage.
   This must be true even for adversaries that can query both the
   encryption and decryption functions adaptively.  The advantage is
   defined as the difference between the probability that the adversary
   will identify the cipher as such and the probability that the
   adversary will identify the random permutation as the cipher, when
   each case is equally likely.

2.3.1.  The Default Cipher

   The default cipher is the Advanced Encryption Standard (AES)
   [FIPS197] with 128-bit keys, in Electronic Codebook (ECB) Mode.  Its
   parameters are fixed at L=16, M=16, and T=2^48.  Note that M matches
   the size of the SRTP master keys used by the default SRTP key
   derivation function; if an SRTP cipher with a different SRTP master
   key length is to be used with EKT, then another EKT cipher must be
   used.  ECB is the simplest mode of operation of a block cipher, in
   which the block cipher is used in its raw form.

2.3.2.  The AES Key Wrap Cipher

   The AES Key Wrap [RFC3394] defines a cipher that can be used with
   plaintexts larger than 16 bytes in length.  It requires a plaintext
   length M that is a multiple of eight bytes, and it returns a
   ciphertext with a length of N = M + 8 bytes.  It can be used with key



McGrew, et al.          Expires September 2, 2007              [Page 13]

Internet-Draft                  EKT SRTP                      March 2007


   sizes of L = 16, 24, and 32.  The key size determines the length of
   the AES key used by the Key Wrap algorithm.  With this cipher,
   T=2^48.

2.3.3.  Other EKT Ciphers

   Other specification MAY extend this one by defining other EKT
   ciphers.  This section defines how those ciphers interact with this
   specification.

   An EKT cipher determines how the Encrypted Master Key field is
   written, and how it is processed when it is read.  This field is
   opaque to the other aspects of EKT processing.  EKT ciphers are free
   to use this field in any way, but they SHOULD NOT use other EKT or
   SRTP fields as an input.  The values of the parameters L, M, N, and T
   MUST be defined by each EKT cipher, and those values MUST be
   inferable from the EKT parameter set.

2.4.  Synchronizing Operation

   EKT is transported over SRTCP, but some of the information that it
   conveys is used for SRTP processing; some elements of the EKT
   parameter set apply to both SRTP and SRTCP.  Furthermore, SRTCP
   packets can be lost and both SRTP and SRTCP packets may be delivered
   out-of-order.  This can lead to various race conditions, which we
   review below.

   When joining an SRTP session, SRTP packets may be received before any
   SRTCP (EKT) packets, which implies the crypto context has not been
   established, unless other external signaling mechanism has done so.
   Rather than automatically discarding such SRTP packets, the receiver
   MAY want to provisionally place them in a jitter buffer and delay
   discarding them until playout time.

   When an SRTP source using EKT performs a rekeying operation, there is
   a race between the actual rekeying signaled via SRTCP and the SRTP
   packets secured by the new keying material.  If the SRTP packets are
   received first, they will fail authentication; alternatively, if
   authentication is not being used, they will decrypt to unintelligible
   random-looking plaintext.  (Note, however, that [RFC3711] says that
   SRTP "SHOULD NOT be used without message authentication".)  In order
   to address this problem, the rekeying event can be sent before
   packets using the new SRTP master key are sent (by use of the ISN
   field).  Another solution involves using an MKI at the expense of
   added overhead in each SRTP packet.  Alternatively, receivers MAY
   want to delay discarding packets from known SSRCs that fail
   authentication in anticipation of receiving a rekeying event via EKT
   (SRTCP) shortly.



McGrew, et al.          Expires September 2, 2007              [Page 14]

Internet-Draft                  EKT SRTP                      March 2007


   The ROC signaled via EKT over SRTCP may be off by one when it is
   received by the other party(ies) in the session.  In order to deal
   with this, receivers should simply follow the SRTP packet index
   estimation procedures defined in [SRTP] Section 3.3.1.

2.5.  Timing and Reliability Consideration

   SRTCP communicates the master key and ROC for the SRTP session.
   Thus, as explained above, if SRTP packets are received prior to the
   corresponding SRTCP (EKT) packet, a race condition occurs.  From an
   EKT point of view, it is therefore desirable for an SRTP sender to
   send an SRTCP packet as soon as possible, and in no case any later
   than when the initial SRTP packet is sent.  SRTCP however MUST obey
   the timing rules associated with the profile under which it runs
   (e.g.  RTP/SAVP or RTP/SAVPF).  Subject to that constraint, SRTP
   senders SHOULD send an SRTCP packet as soon as possible after joining
   a session.  Note that there is no need for SRTP receivers to do so.
   Also note, that per RFC 3550, Section 6.2, it is permissible to send
   a compound RTCP packet immediately after joining a unicast session
   (but not a multicast session).

   SRTCP is not reliable and hence SRTCP packets may be lost.  This is
   obviously a problem for endpoints joining an SRTP session and
   receiving SRTP traffic (as opposed to SRTCP), or for endpoints
   receiving SRTP traffic following a rekeying event.  To reduce the
   impact of lost packets, SRTP senders SHOULD send SRTCP packets as
   often as allowed by the profile under which they operate.
























McGrew, et al.          Expires September 2, 2007              [Page 15]

Internet-Draft                  EKT SRTP                      March 2007


3.  EKT and SDP Security Descriptions

   The SDP Security Descriptions (SDES) [SDES] specification defines a
   generic framework for negotiating security parameters for media
   streams negotiated via the Session Description Protocol by use of a
   new SDP "crypto" attribute and the Offer/Answer procedures defined in
   [RFC3264].  In addition to the general framework, SDES also defines
   how to use that framework specifically to negotiate security
   parameters for Secure RTP.  Below, we first provide a brief recap of
   the crypto attribute when used for SRTP and we then explain how it is
   complementary to EKT.  In the rest of this Section, we provide
   extensions to the crypto attribute and associated offer/answer
   procedures to define its use with EKT.

3.1.  SDP Security Descriptions Recap

   The SRTP crypto attribute defined for SDP Security Descriptions
   contains a tag followed by three types of parameters (refer to [SDES]
   for details):

      Crypto-suite.  Identifies the encryption and authentication
      transform

      Key parameters.  SRTP keying material and parameters.

      Session parameters.  Additional (optional) SRTP parameters such as
      Key Derivation Rate, Forward Error Correction Order, use of
      unencrypted SRTP, etc.

   The crypto attributes in the example SDP in Figure 3 illustrate these
   parameters.




















McGrew, et al.          Expires September 2, 2007              [Page 16]

Internet-Draft                  EKT SRTP                      March 2007


         v=0
         o=sam 2890844526 2890842807 IN IP4 192.0.2.5
         s=SRTP Discussion
         i=A discussion of Secure RTP
         u=http://www.example.com/seminars/srtp.pdf
         e=marge@example.com (Marge Simpson)
         c=IN IP4 192.0.2.12
         t=2873397496 2873404696
         m=audio 49170 RTP/SAVP 0
         a=crypto:1 AES_CM_128_HMAC_SHA1_80
          inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
          FEC_ORDER=FEC_SRTP
         a=crypto:2 F8_128_HMAC_SHA1_80
          inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4;
          inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4
          FEC_ORDER=FEC_SRTP

     Figure 3: SDP Security Descriptions example.    Line breaks  are
                  included for formatting purposes only.

   The first crypto attribute has the tag "1" and uses the crypto-suite
   "AES_CM_128_HMAC_SHA1_80".  The "inline" parameter provides the SRTP
   master key and salt, the master key lifetime (number of packets), and
   the (optional) Master Key Identifier (MKI) whose value is "1" and has
   a byte length of "4" in the SRTP packets.  Finally, the FEC_ORDER
   session parameter indicates the order of Forward Error Correction
   used (FEC is applied before SRTP processing by the sender of the SRTP
   media).

   The second crypto attribute has the tag "2" and uses the crypto-suite
   "F8_128_HMAC_SHA1_80".  It includes two SRTP master keys and
   associated salts.  The first one is used with the MKI value 1,
   whereas the second one is used with the MKI value 2.  Finally, the
   FEC_ORDER session parameter indicates the order of Forward Error
   Correction used.

3.2.  Relationship between EKT and SDP Security Descriptions

   SDP Security Descriptions [SDES] define a generic framework for
   negotiating security parameters for media streams negotiated via the
   Session Description Protocol by use of the Offer/Answer procedures
   defined in [RFC3264].  In addition to the general framework, SDP
   Security Descriptions (SDES) also defines how to use it specifically
   to negotiate security parameters for Secure RTP.

   EKT and SDES are complementary.  SDP Security Descriptions can
   negotiate several of the SRTP security parameters (e.g. cipher and
   use of Master Key Identifier/MKI) as well as SRTP master keys.  SDP



McGrew, et al.          Expires September 2, 2007              [Page 17]

Internet-Draft                  EKT SRTP                      March 2007


   Security Descriptions however does not negotiate SSRCs and their
   associated Rollover Counter (ROC).  Instead, SDES relies on a so-
   called "late binding", where a newly observed SSRC will have its
   crypto context initialized to a ROC value of zero.  Clearly, this
   does not work for participants joining an SRTP session that has been
   established for a while and hence has a non-zero ROC.  The use of EKT
   solves this problem by communicating the ROC associated with the SSRC
   in the media plane.

   SDP Security Descriptions negotiates different SRTP master keys in
   the send and receive direction.  The offer contains the master key
   used by the offerer to send media, and the answer contains the master
   key used by the answerer to send media.  Consequently, if media is
   received by the offerer prior to the answer being received, the
   offerer does not know the master key being used.  Use of SDP security
   preconditions can solve this problem, however it requires an
   additional round-trip as well as a more complicated state machine.
   EKT solves this problem by simply sending the master key used in the
   media plane thereby avoiding the need for security preconditions.

   If multiple crypto-suites were offered, the offerer also will not
   know which of the crypto-suites offered was selected until the answer
   is received.  EKT solves this problem by using a correlator, the
   Security Parameter Index (SPI), which uniquely identifies each crypto
   attribute in the offer.

   One of the primary call signaling protocols using offer/answer is the
   Session Initiation Protocol (SIP) [RFC3261].  SIP uses the INVITE
   message to initiate a media session and typically includes an offer
   SDP in the INVITE.  An INVITE may be "forked" to multiple recipients
   which potentially can lead to multiple answers being received.  SDP
   Security Descriptions however does not properly support this
   scenario, mainly because SDP and RTP/RTCP does not contain sufficient
   information to allow for correlation of an incoming RTP/RTCP packet
   with a particular answer SDP.  Note that extensions providing this
   correlation do exist, e.g.  Interactive Connectivity Establishment
   (ICE).  SDP Security Descriptions addresses this point-to-multipoint
   problem by moving each answer to a separate RTP transport address
   thereby turning a point-to-multipoint scenario into multiple point-
   to-point scenarios.  There are however significant disadvantages to
   doing so.  As long as the crypto attribute in the answer does not
   contain any declarative parameters that differ from those in the
   offer, EKT solves this problem by use of the SPI correlator and
   communication of the answerer's SRTP master key in EKT.

   As can be seen from the above, the combination of EKT and SDES
   provides a better solution to SRTP negotiation for offer/answer than
   either of them alone.  SDES negotiates the various SRTP crypto



McGrew, et al.          Expires September 2, 2007              [Page 18]

Internet-Draft                  EKT SRTP                      March 2007


   parameters (which EKT does not), whereas EKT addresses the
   shortcomings of SDES.

3.3.  Overview of Combined EKT and SDP Security Description   Operation

   We define three session extension parameters to SDES to communicate
   the EKT cipher, EKT key, and Security Parameter Index to the peer.
   The original SDES parameters are used as defined in [SDES], however
   the procedures associated with the SRTP master key differ slightly,
   since both SDES and EKT communicate an SRTP master key.  In
   particular, the SRTP master key communicated via SDES is used only if
   there is currently no crypto context established for the SSRC in
   question.  This will be the case when an entity has received only the
   offer or answer, but has yet to receive a valid EKT message from the
   peer.  Once a valid EKT message is received for the SSRC, the crypto
   context is initialized accordingly, and the SRTP master key will then
   be derived from the EKT message.  Subsequent offer/answer exchanges
   do not change this: The most recent SRTP master key negotiated via
   EKT will be used, or, if none is available for the SSRC in question,
   the most recent SRTP master key negotiated via offer/answer will be
   used.  Note that with these rules, once a valid EKT message has been
   received for a given SSRC, rekeying for that SSRC can only be done
   via EKT.  The associated SRTP crypto parameters however can be
   changed via SDES.

3.4.  EKT Extensions to SDP Security Descriptions

   In order to use EKT and SDES in conjunction, we now define the
   following new SDES session parameters, each of which MUST NOT appear
   more than once in a given crypto attribute:

   EKT_Cipher   The EKT cipher used to encrypt the SRTP Master Key

   EKT_Key  The EKT key used to encrypt the SRTP Master Key

   EKT_SPI  The EKT Security Parameter Index

   Below, we provide additional detail on each of these attributes.

3.4.1.  EKT_Cipher

   The (optional) EKT_Cipher parameter parameter defines the EKT cipher
   used to encrypt the EKT key with in SRTCP packets.  The default value
   is "AES_128" in accordance with Section 2.3.1.  For the AES Key Wrap
   cipher (see Section 2.3.2, the values "AESKW_128", "AESKW_192", and
   "AESKW_256" are defined for values of L=16, 24, and 32 respectively.
   In the Offer/Answer model, the EKT_Cipher parameter is a negotiated
   parameter.



McGrew, et al.          Expires September 2, 2007              [Page 19]

Internet-Draft                  EKT SRTP                      March 2007


3.4.2.  EKT_Key

   The (mandatory) EKT_Key parameter is the key K used to encrypt the
   SRTP Master Key in SRTCP packets.  The value is base64 encoded (see
   [RFC3548], Section 3).  When base64 decoding the key, padding
   characters (i.e., one or two "=" at the end of the base64 encoded
   data) are discarded (see [RFC3548] for details).  Base64 encoding
   assumes that the base64 encoding input is an integral number of
   octets.  If a given EKT cipher requires the use of a key with a
   length that is not an integral number of octets, said cipher MUST
   define a padding scheme that results in the base64 input being an
   integral number of octets.  For example, if the length defined was
   250 bits, then 6 padding bits would be needed, which could be defined
   to be the last 6 bits in a 256 bit input.  In the Offer/Answer model,
   the EKT_Key parameter is a negotiated parameter.

3.4.3.  EKT_SPI

   The (mandatory) EKT_SPI parameter is the Security Parameter Index.
   It is encoded as an ASCII string representing the hexadecimal value
   of the Security Parameter Index.  The SPI identifies the *offer*
   crypto attribute (including the EKT Key and Cipher) being used for
   the associated SRTP session.  A crypto attribute corresponds to an
   EKT Parameter Set and hence the SPI effectively identifies a
   particular EKT parameter set.  Note that the scope of the SPI is the
   SRTP session, which may or may not be limited to the scope of the
   associated SIP dialog.  In particular, if one of the participants in
   an SRTP session is an SRTP translator, the scope of the SRTP session
   is not limited to the scope of a single SIP dialog.  However, if all
   of the participants in the session are endpoints or mixers, the scope
   of the SRTP session will correspond to a single SIP dialog.  In the
   Offer/Answer model, the EKT_SPI parameter is a negotiated parameter.

3.5.  Offer/Answer Procedures

   In this section, we provide the offer/answer procedures associated
   with use of the three new SDES parameters defined in Section
   Section 3.4.  Since SDES is defined only for unicast streams, we
   provide only offer/answer procedures for unicast streams here as
   well.

3.5.1.  Generating the Initial Offer - Unicast Streams

   When the initial offer is generated, the offerer MUST follow the
   steps defined in [SDES] Section 7.1.1 as well as the following steps.

   For each unicast media line using SDES and where use of EKT is
   desired, the offerer MUST include one EKT_Key parameter and one



McGrew, et al.          Expires September 2, 2007              [Page 20]

Internet-Draft                  EKT SRTP                      March 2007


   EKT_SPI parameter in at least one "crypto" attribute (see [SDES]).
   The EKT_SPI parameter serves to identify the EKT parameter set used
   for a particular SRTCP packet.  Consequently, within a single media
   line, a given EKT_SPI value MUST NOT be used with multiple crypto
   attributes.  Note that the EKT parameter set to use for the session
   is not yet established at this point; each offered crypto attribute
   contains a candidate EKT parameter set.  Furthermore, if the media
   line refers to an existing SRTP session, then any SPI values used for
   EKT parameter sets in that session MUST NOT be remapped to any
   different EKT parameter sets.  When an offer describes an SRTP
   session that is already in progress, the offer SHOULD use an EKT
   parameter set (incl.  EKT_SPI and EKT_KEY) that is already in use.

   If an EKT_Cipher other than the default cipher is to be used, then
   the EKT_Cipher parameter MUST be included as well.

   If a given crypto attribute includes more than one set of SRTP key
   parameters (SRTP master key, salt, lifetime, MKI), they MUST all use
   the same salt.  (EKT requires a single shared salt between all the
   participants in the direct SRTP session).

   Important Note: The scope of the offer/answer exchange is the SIP
   dialog(s) established as a result of the INVITE, however the scope of
   EKT is the direct SRTP session, i.e. all the participants that are
   able to receive SRTP and SRTCP packets directly.  If an SRTP session
   spans multiple SIP dialogs, the EKT parameter sets MUST be
   synchronized between all the SIP dialogs where SRTP and SRTCP packets
   can be exchanged.  In the case where the SIP entity operates as an
   RTP mixer (and hence re-originates SRTP and SRTCP packets with its
   own SSRC), this is not an issue, unless the mixer receives traffic
   from the various participants on the same destination IP address and
   port, in which case further coordination of SPI values and crypto
   parameters may be needed between the SIP dialogs (note that SIP
   forking with multiple early media senders is an example of this).
   However if it operates as an RTP translator, synchronized negotiation
   of the EKT parameter sets on *all* the involved SIP dialogs will be
   needed.  This is non-trivial in a variety of use cases, and hence use
   of the combined SDES/EKT mechanism with RTP translators should be
   considered very carefully.  It should be noted, that use of SRTP with
   RTP translators in general should be considered very carefully as
   well.

   The EKT session parameters can either be included as optional or
   mandatory parameters, however within a given crypto attribute, they
   MUST all be either optional or mandatory.






McGrew, et al.          Expires September 2, 2007              [Page 21]

Internet-Draft                  EKT SRTP                      March 2007


3.5.2.  Generating the Initial Answer - Unicast Streams

   When the initial answer is generated, the answerer MUST follow the
   steps defined in [SDES] Section 7.1.2 as well as the following steps.

   For each unicast media line using SDES, the answerer examines the
   associated crypto attribute(s) for the presence of EKT parameters.
   If mandatory EKT parameters are included with a "crypto" attribute,
   the answerer MUST support those parameters in order to accept that
   offered crypto attribute.  If optional EKT parameters are included
   instead, the answerer MAY accept the offered crypto attribute without
   using EKT.  However, doing so will prevent the offerer from
   processing any packets received before the answer.  If neither
   optional nor mandatory EKT parameters are included with a crypto
   attribute, and that crypto attribute is accepted in the answer, EKT
   MUST NOT be used.  If a given a crypto attribute includes a mixture
   of optional and mandatory EKT parameters, or an incomplete set of
   mandatory EKT parameters, that crypto attribute MUST be considered
   invalid.

   When EKT is used with SDES, the offerer and answerer MUST use the
   same SRTP salt.  Thus, the SRTP key parameter(s) in the answer crypto
   attribute MUST use the same salt as the one accepted from the offer.

   When the answerer accepts the offered media line and EKT is being
   used, the crypto attribute included in the answer MUST include the
   same EKT parameter values as found in the accepted crypto attribute
   from the offer (however, if the default EKT cipher is being used, it
   may be omitted).  Furthermore, the EKT parameters included MUST be
   mandatory (i.e. no "-" prefix).

   Acceptance of a crypto attribute with EKT parameters leads to
   establishment of the EKT parameter set for the corresponding SRTP
   session.  Consequently, the answerer MUST send packets in accordance
   with that particular EKT parameter set only.  If the answerer wants
   to enable the offerer to process SRTP packets received by the offerer
   before it receives the answer, the answerer MUST NOT include any
   declarative session parameters that either were not present in the
   offered crypto attribute, or were present but with a different value.
   Otherwise, the offerer's view of the EKT parameter set would differ
   from the answerer's until the answer is received.  Similarly, unless
   the offerer and answerer has other means for correlating an answer
   with a particular SRTP session, the answer SHOULD NOT include any
   declarative session parameters that either were not present in the
   offered crypto attribute, or were present but with a different value.
   If this recommendation is not followed and the offerer receives
   multiple answers (e.g. due to SIP forking), the offerer may not be
   able to process incoming media stream packets correctly.



McGrew, et al.          Expires September 2, 2007              [Page 22]

Internet-Draft                  EKT SRTP                      March 2007


3.5.3.  Processing of the Initial Answer - Unicast Streams

   When the offerer receives the answer, it MUST perform the steps in
   [SDES] Section 7.1.3 as well as the following steps for each SRTP
   media stream it offered with one or more crypto lines containing EKT
   parameters in it.

   If the answer crypto line contains EKT parameters, and the
   corresponding crypto line from the offer contained the same EKT
   values, use of EKT has been negotiated successfully and MUST be used
   for the media stream.  When determining whether the values match,
   optional and mandatory parameters MUST be considered equal.
   Furthermore, if the default EKT cipher is being used, it MAY be
   either present or absent in the offer and/or answer.

   If the answer crypto line does not contain EKT parameters, then EKT
   MUST NOT be used for the corresponding SRTP session.  Note that per
   [SDES] Section 5.1.3, if the accepted crypto attribute contained
   mandatory EKT parameters in the offer, and the crypto attribute in
   the answer does not contain EKT parameters, then negotiation has
   failed.

   If the answer crypto line contains EKT parameters but the
   corresponding offered crypto line did not, or if the parameters don't
   match or are invalid, then the offerer MUST consider the crypto line
   invalid (see [SDES] Section 7.1.3 for further operation).

   The EKT parameter set is established when the answer is received,
   however there are a couple of special cases to consider here.  First
   of all, if an SRTCP packet is received prior to the answer, then the
   EKT parameter set is established provisionally based on the SPI
   included.  Once the answer (which may include declarative session
   parameters) is received, the EKT parameter set is fully established.
   The second case involves receipt of multiple answers due to SIP
   forking.  In this case, there will be multiple EKT parameter sets;
   one for each SRTP session.  As mentioned earlier, reliable
   correlation of SIP dialogs to SRTP sessions requires extensions, and
   hence if one or more of the answers include declarative session
   parameters, it may be difficult to fully establish the EKT parameter
   set for each SRTP session.  In the absence of a specific correlation
   mechanism, it is RECOMMENDED, that such correlation be done based on
   the signaled receive IP-address in the SDP and the observed source
   IP-address in incoming SRTP/SRTCP packets, and, if necessary, the
   signaled receive UDP port and the observed source UDP port.







McGrew, et al.          Expires September 2, 2007              [Page 23]

Internet-Draft                  EKT SRTP                      March 2007


3.6.  SRTP-Specific Use Outside Offer/Answer

   SDES use for SRTP is not defined outside offer/answer and hence
   neither is SDES with EKT.

3.7.  Modifying the Session

   When a media stream using the SRTP security descriptions has been
   established, and a new offer/answer exchange is performed, the
   offerer and answerer MUST follow the steps in [SDES] Section 7.1.4 as
   well as the following steps.  SDES allows for all parameters of the
   session to be modified, and the EKT session parameters are no
   exception to that, however, there are a few additional rules to be
   adhered to when using EKT.

   It is permissible to start a session without the use of EKT, and then
   subsequently start using EKT, however the converse is not.  Thus,
   once use of EKT has been negotiated on a particular media stream, EKT
   MUST continue to be used on that media stream in all subsequent
   offer/answer exchanges.

   The reason for this is that both SDES and EKT communicate the SRTP
   Master Key with EKT Master Keys taking precedence.  Reverting back to
   an SDES controlled master key in a synchronized manner is difficult.

   Once EKT is being used, the salt for the direct SRTP session MUST NOT
   be changed.  Thus, a new offer/answer which does not create a new
   SRTP session (e.g. because it reuses the same IP address and port)
   MUST use the same salt for all crypto attributes as is currently used
   for the direct SRTP session.

   Finally, subsequent offer/answer exchanges MUST NOT remap a given SPI
   value to a different EKT parameter set until 2^32 other mappings have
   been used within the SRTP session.  In practice, this requirements is
   most easily met by using a monotonically increasing SPI value (modulo
   2^32 and starting with zero) per direct SRTP session.  Note that a
   direct SRTP session may span multiple SIP dialogs, and in such cases
   coordination of SPI values across those SIP dialogs will be required.
   In the simple point-to-point unicast case without translators, the
   requirement simply applies within each media line in the SDP.  In the
   point-to-multipoint case, the requirement applies across all the
   associated SIP dialogs.

3.8.  Backwards Compatibility Considerations

   Backwards compatibility can be achieved in a couple of ways.  First
   of all, SDES allows for session parameters to be prefixed with "-" to
   indicate that they are optional.  If the answerer does not support



McGrew, et al.          Expires September 2, 2007              [Page 24]

Internet-Draft                  EKT SRTP                      March 2007


   the EKT session parameters, such optional parameters will simply be
   ignored.  When the answer is received, absence of the parameters will
   indicate that EKT is not being used.  Receipt of SRTCP packets prior
   to receipt of such an answer will obviously be problematic (as is
   normally the case for SDES without EKT).

   Alternatively, SDES allows for multiple crypto lines to be included
   for a particular media stream.  Thus, two crypto lines that differ in
   their use of EKT parameters (presence in one, absence in the other)
   can be used as a way to negotiate use of EKT.  When the answer is
   received, the accepted crypto attribute will indicate whether EKT is
   being used or not.

3.9.  Grammar

   The Augmented Backus-Naur Form (ABNF) syntax [RFC4234] for the three
   new SDES session parameters is as in Figure 4.

  EKT_Cipher = "EKT_Cipher=" EKT_Cipher_Name
  EKT_Cipher_Name = 1*(ALPHA / DIGIT / "_") ; "AES_128", "AESKW_128"
                                           ; "AESKW_192" and "AESKW_256"
                                           ; defined in this document.
  EKT_Key = 1*(base64)    ; See Section 3 in RFC3548
  base64  =  ALPHA / DIGIT / "+" / "/" / "="
  EKT_SPI = 4HEXDIG   ; See RFC4234

              Figure 4: ABNF for the EKT session parameters.
























McGrew, et al.          Expires September 2, 2007              [Page 25]

Internet-Draft                  EKT SRTP                      March 2007


4.  Use of EKT with MIKEY

   The advantages outlined in Section 1 are useful in some scenarios in
   which MIKEY is used to establish SRTP sessions.  In this section, we
   briefly review MIKEY and related work, and discuss these scenarios.
   A n SRTP sender or a group controller can use MIKEY to establish a
   SRTP cryptographic context.  This capability includes the
   distribution of the TEK or a TEK generation key (TGK) , security
   policy payload, crypto session bundle ID (CSB_ID), and a crypto
   session ID (CS_ID).  The TEK directly maps to an SRTP master key,
   whereas the TGK is used along with the CSB_ID and a CS_ID to generate
   a TEK.  The CS_ID can be used to generate multiple TEKs from a single
   TGK.  For group communication, the sender or group controller sends
   the same TGK, CSB_ID, and CS_ID to all the members.  For interactive
   conferencing, each sender distributes the same SRTP crypto context to
   the rest of the members.

   The MIKEY specification [RFC3830] suggests the use of unicast for
   rekeying.  This method does not scale well to large groups or
   interactive groups.  MIKEY also provides a way to provide ROC values
   to members when they join the group.  It is desirable to not require
   the group controller to track the ROC values of each member.  For
   example, in mobile and wireless environments, members may go in and
   out of coverage, and in those cases, key management based ROC
   synchronization is not reliable or sufficient.  A better alternative
   to support ROC synchronization is to send ROC values via SRTP, as EKT
   does.  A separate SRTP extension is being proposed [RCC] to include
   the ROC as part of a modified authentication tag.  Unlike EKT, this
   extension uses SRTP and not SRTCP as its transport.  A new MIKEY
   extension [KEYID] specifies the use of MIKEY to update group keys via
   multicast or broadcast for 3GPP MBMS networks.

   The EKT extension of SRTP/SRTCP provides a combined solution for
   rekeying and ROC synchronization.  It also offers several advantages.
   With EKT, an SRTP session participant can start a new SRTP source
   without coordinating with a group controller about the selection of
   keys or SSRC values.  With EKT, SRTP can handle early media, since
   its SPI allows the receiver to identify the cryptographic keys and
   parameters used by the source.  EKT also allows SRTP to work with SIP
   forking.

   MIKEY can readily be extended so that it can establish the EKT key,
   cipher and SPI values.

4.1.  EKT transform attribute mapping in MIKEY

   Interactive group communication using MIKEY currently requires each
   member to send its own TGK and SSRC information to the other members,



McGrew, et al.          Expires September 2, 2007              [Page 26]

Internet-Draft                  EKT SRTP                      March 2007


   resulting in O(n^2) MIKEY sessions.  That is not desirable.  With
   EKT, the conference organizer or only one of the members needs to
   distribute the EKT parameters to all the members.  After that, each
   member can distribute its SRTP master key and ROC values using EKT.
   Cryptographic policy initially distributed via MIKEY will apply to
   all sessions.  MIKEY specifies a security policy (SP) payload to
   negotiate or distribute SRTP security policy.  Policy payload
   attributes include Session Encryption key length, Authentication
   algorithm, Session Authentication key length, Session Salt key
   length, SRTP PRF, Authentication tag length and other fields (see
   Section 6.10.1 of RFC 3830).

   For the EKT_Cipher parameter, we propose to specify a new SRTP Policy
   Type in the Security Policy (SP) payload of MIKEY (see Section 6.10
   of RFC 3830).  The SP payload contains a number of Policy Param TLVs.
   We define Type = TBD: (will be requested from IANA) for EKT_Cipher.
   As with other payloads specifying cryptographic algorithms, we only
   specify Type and Values only.



       EKT_Cipher | Value
       -------------------
       AES_128    |  0
       AESKW_128  |  1
       AESKW_192  |  2
       AESKW_256  |  3


                        Figure 5: EKT_Cipher Table

   We propose to use the KEMAC payload to transport the two mandatory
   EKT parameters: EKT_Key and EKT_SPI MIKEY KEMAC payload, as specified
   in RFC 3830 carries the Traffic Encryption Key (TEK) or the TEK
   Generation Key (TGK).  One or more TEKs or TGKs are carried in
   individual Key Data sub-payloads within the KEMAC payload.  The KEMAC
   payload is encrypted as part of MIKEY.  The Key Data sub- payload,
   specified in Section 6.13 of RFC 3830, has the following format:













McGrew, et al.          Expires September 2, 2007              [Page 27]

Internet-Draft                  EKT SRTP                      March 2007


                            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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !  Next Payload ! Type  ! KV    ! Key data len                  !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !                         Key data                              ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ! Salt len (optional)           ! Salt data (optional)          ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !                        KV data (optional)                     ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 6: Key Data Sub-Payload of MIKEY

   The Type field, 4 bits in length, indicates the type of key included
   in the payload.  We define Type = TBD (will be requested from IANA)
   to indicate transport of EKT_Key.

   KV (4 bits): indicates the type of key validity period specified.
   KV=1 is currently specified as an SPI.  We propose to use that value
   to indicate the KV_data contains the ETK_SPI.  KV_data would be 16
   octets in length, but it is also possible to interpret the length
   from the 'Key data len' field.

   KV data MUST NOT be optional when KV = 1.

























McGrew, et al.          Expires September 2, 2007              [Page 28]

Internet-Draft                  EKT SRTP                      March 2007


5.  Design Rationale

   From [RFC3550], a primary function of RTCP is to carry the CNAME, a
   "persistent transport-level identifier for an RTP source" since
   "receivers require the CNAME to keep track of each participant."  EKT
   works in much the same way, using SRTCP to carry information needed
   for the proper processing of the SRTP traffic.

   With EKT, SRTP gains the ability to synchronize the creation of
   cryptographic contexts across all of the participants in a single
   session.  This feature provides some, but not all, of the
   functionality that is present in IKE phase two (but not phase one).
   Importantly, EKT does not provide a way to indicate SRTP options.

   With EKT, external signaling mechanisms provide the SRTP options and
   the EKT Key, but need not provide the key(s) for each individual SRTP
   source.  EKT provides a separation between the signaling mechanisms
   and the details of SRTP.  The signaling system need not coordinate
   all SRTP streams, nor predict in advance how many streams will be
   present, nor communicate SRTP-level information (e.g. rollover
   counters) of current sessions.

   EKT is especially useful for multi-party sessions, and for the case
   where multiple RTP sessions are sent to the same destination
   transport address (see the example in the definition of "RTP session"
   in [RFC3550]).  A SIP offer that is forked in parallel (sent to
   multiple endpoints at the same time) can cause multiple RTP sessions
   to be sent to the same transport address, making EKT useful for use
   with SIP.

   EKT can also be used in conjunction with a scalable group-key
   management system like GDOI.  Such a system provides a secure entity
   authentication method and a way to revoke group membership, both of
   which are out of scope of EKT.

   It is natural to use SRTCP to transport encrypted keying material for
   SRTP, as it provides a secure control channel for (S)RTP.  However,
   there are several different places in SRTCP in which the encrypted
   SRTP master key and ROC could be conveyed.  We briefly review some of
   the alternatives in order to motivate the particular choice used in
   this specification.  One alternative is to have those values carried
   as a new SDES item or RTCP packet.  This would require that the
   normal SRTCP encryption be turned off for the packets containing that
   SDES item, since on the receiver's side, SRTCP processing completes
   before the RTCP processing starts.  This tension between encryption
   and the desire for RTCP privacy is highly undesirable.  Additionally,
   this alternative makes SRTCP dependent upon the parsing of the RTCP
   compound packet, which adds complexity.  It is simpler to carry the



McGrew, et al.          Expires September 2, 2007              [Page 29]

Internet-Draft                  EKT SRTP                      March 2007


   encrypted key in a new SRTCP field.  One way to do this and to be
   backwards compatible with the existing specification is to define a
   new crypto function that incorporates the encrypted key.  We define a
   new authentication transform because EKT relies on the normal SRTCP
   authentication to provide implicit authentication of the encrypted
   key.

   An SRTP packet containing an SSRC that has not been seen will be
   discarded.  This practice may induce a burst of packet loss at the
   outset of an SRTP stream, due to the loss or reorder of the first
   SRTCP packet with the EKT containing the key and rollover counter for
   that stream.  However, this practice matches the conservative RTP
   memory-allocation strategy; many existing applications accept this
   risk of initial packet loss.  Alternatively, implementations may wish
   to delay discarding such packets for a short period of time as
   described in Section 2.4.

   EKT adds eight additional bytes to each SRTCP packet, plus the length
   of the Encrypted Master Key field.  Using the SRTP and EKT defaults,
   the total overhead is 24 bytes.  This overhead does not detract from
   the total bandwidth used by SRTP, since it is included in the RTCP
   bandwidth computation.  However, it will cause the control protocol
   to issue packets less frequently.

   If EKT is used of SRTP, there will be a loss of bandwidth due to the
   additional 24 bytes in each RTP packet.  For some applications, this
   bandwidth loss is significant.  It may be desirable to carry the EKT
   fields only in some of the SRTP packets, e.g. by adding a flag bit
   that indicates the presence or absence of those fields.  A data
   format that uses this approach is defined in Appendix A.  We leave
   this point open for discussion.

   The only motivation for defining the ability to run EKT over SRTP
   instead of RTCP is the unfortunate fact that RTCP is not always
   available, because some RTP stacks are incomplete and some firewalls
   and NAT devices can pass RTP but not RTCP.















McGrew, et al.          Expires September 2, 2007              [Page 30]

Internet-Draft                  EKT SRTP                      March 2007


6.  RTP Transport

   EKT MAY be used over SRTP instead of SRTCP if the latter protocol is
   not available, though implementations SHOULD otherwise use SRTCP.  If
   EKT over SRTP is used in an SRTP session in which SRTCP is available,
   then EKT MUST be used for both SRTP and SRTCP.

   The packet processing, state machine, and Authentication Tag format
   for EKT over SRTP is identical to that for EKT over SRTCP.










































McGrew, et al.          Expires September 2, 2007              [Page 31]

Internet-Draft                  EKT SRTP                      March 2007


7.  Security Considerations

   With EKT, each SRTP sender and receiver can generate distinct SRTP
   master keys.  This property avoids any security concern over the re-
   use of keys, by empowering the SRTP layer to create keys on demand.
   Note that the inputs of EKT are the same as for SRTP with key-
   sharing: a single key is provided to protect an entire SRTP session.
   However, EKT provides complete security, even in the absence of
   further out-of-band coordination of SSRCs, and even when SSRC values
   collide.

   EKT uses encrypted key transport with implicit authentication.  A
   strong cipher is used to ensure the confidentiality of the master
   keys as they are transported.  The authenticity of the master keys is
   ensured by the base authentication check, which uses the plaintext
   form of that key.  If the base authentication function and the cipher
   cannot be defeated by a particular attacker, then that attacker will
   be unable to defeat the implicit authentication.

   In order to avoid potential security issues, the SRTP authentication
   tag length used by the base authentication method MUST be at least
   ten octets.





























McGrew, et al.          Expires September 2, 2007              [Page 32]

Internet-Draft                  EKT SRTP                      March 2007


8.  IANA Considerations

   This section registers with IANA the following SRTP session
   parameters for SDP Security Descriptions [SDES]:

      EKT_KEY

      EKT_CIPHER

      EKT_SPI

   The definition of these parameters is provided in Section 3.4.

   We request the following IANA assignments from existing MIKEY IANA
   tables:

      From the "Key Data payload name spaces:" a value to indicate the
      type as the "EKT_Key."

      From the "SRTP" policy table name space, a new value to be
      assigned for "EKT_Cipher."

   Furthermore, we need a new table to be defined:


       EKT_Cipher | Value
       -------------------
       AES_128    |  0
       AESKW_128  |  1
       AESKW_192  |  2
       AESKW_256  |  3


                        Figure 7: EKT_Cipher Table

















McGrew, et al.          Expires September 2, 2007              [Page 33]

Internet-Draft                  EKT SRTP                      March 2007


9.  Acknowledgements

   Thanks to Dan Wing, Rob Raymond, and Nermeen Ismail for fruitful
   discussions.















































McGrew, et al.          Expires September 2, 2007              [Page 34]

Internet-Draft                  EKT SRTP                      March 2007


10.  References

10.1.  Normative References

   [FIPS197]  "The Advanced Encryption Standard (AES)", FIPS-197 Federal
              Information Processing Standard.

   [KEYID]    Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID
              Information Type for the General Extension Payload in
              MIKEY", Work In
              Progress. <draft-ietf-msec-newtype-keyid-04.txt>.

   [RCC]      Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity
              Transform Carrying Roll-over Counter", Work In
              Progress. <draft-lehtovirta-srtp-rcc-01.txt>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC3394]  Schaad, J. and R. Housley, "Advanced Encryption Standard
              (AES) Key Wrap Algorithm", RFC 3394, September 2002.

   [RFC3548]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 3548, July 2003.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

   [SDES]     Andreasen, F., Baugher, M., and D. Wing, "Session
              Description Protocol Security Descriptions for Media
              Streams", Work In



McGrew, et al.          Expires September 2, 2007              [Page 35]

Internet-Draft                  EKT SRTP                      March 2007


              Progress. <draft-ietf-mmusic-sdescriptions-11.txt>.

10.2.  Informative References

   [RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
              Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
              August 2004.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.









































McGrew, et al.          Expires September 2, 2007              [Page 36]

Internet-Draft                  EKT SRTP                      March 2007


Appendix A.  Alternate Format

   In this appendix we describe an alternate Authentication Tag format,
   which is intended for the purposes of discussion.  It allows a sender
   to optionally omit the EKT data from a packet.  As discussed in
   Section 5, this feature is desirable because it allows bandwidth
   conservation, and it gives the sender the discretion of when to send
   the EKT data, without any need for external coordination.

   The alternate format is shown in Figure 8.  The top diagram shows the
   format in the case that the final bit is set to one, in which case
   all of the EKT fields are present.  The bottom diagram shows the
   format in the case that the final bit is set to zero, in which case
   the Encrypted Master Key, Rollover Counter, Initial Sequence Number,
   and Security Parameter Index fields are absent.  The Reserved field
   MUST be set to the all-zero value.  These two cases can always be
   unambiguously distinguished by the final bit, or by checking to see
   if the final byte in the packet has the all-zero value.

       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                   Base Authentication Tag                     :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                     Encrypted Master Key                      :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Rollover Counter                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Initial Sequence Number    |   Security Parameter Index  |1|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                   Base Authentication Tag                     :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Reserved   |0|
       +-+-+-+-+-+-+-+-+

            Figure 8: Alternate EKT Authentication Tag format.

   In the alternate format, the SPI field is 15 bits long, instead of 16
   bits long.  Sender-side implementations using the existing format can
   achieve interoperability with the alternate format by selecting SPI
   values have a final bit that is equal to one.  Receiver
   implementations using the existing format can interoperate with the
   alternate format if SPI values ending in one are used, and the sender
   always sends all of the EKT fields.



McGrew, et al.          Expires September 2, 2007              [Page 37]

Internet-Draft                  EKT SRTP                      March 2007


   The main motivation for the alternate format is the case when RTCP is
   not available and EKT data is carried by RTP, and bandwidth
   conservation is important.  However, it may be acceptable to use it
   for RTCP as well.















































McGrew, et al.          Expires September 2, 2007              [Page 38]

Internet-Draft                  EKT SRTP                      March 2007


Authors' Addresses

   David A. McGrew
   Cisco Systems, Inc.
   510 McCarthy Blvd.
   Milpitas, CA  95035
   US

   Phone: (408) 525 8651
   Email: mcgrew@cisco.com
   URI:   http://www.mindspring.com/~dmcgrew/dam.htm


   Flemming   Andreason
   Cisco Systems, Inc.
   499 Thornall Street
   Edison, NJ  08837
   US

   Email: fandreas@cisco.com


   Lakshminath Dondeti
   QUALCOMM
   5775 Morehouse Drive
   San Diego, CA  92121
   US

   Email: ldondeti@qualcomm.com






















McGrew, et al.          Expires September 2, 2007              [Page 39]

Internet-Draft                  EKT SRTP                      March 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





McGrew, et al.          Expires September 2, 2007              [Page 40]


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