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

Versions: (draft-baugher-msec-gdoi-srtp) 00 01

Network Working Group                                         M. Baugher
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                          A. Rueegsegger
Expires: June 5, 2008                                 secunet SwissIT AG
                                                               S. Rowles
                                                     Cisco Systems, Inc.
                                                        December 3, 2007


       GDOI Key Establishment for the SRTP Data Security Protocol
                    draft-ietf-msec-gdoi-srtp-01.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 June 5, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).











Baugher, et al.           Expires June 5, 2008                  [Page 1]


Internet-Draft                  GDOI-SRTP                  December 2007


Abstract

   The Secure Real-time Transport Protocol (SRTP) protects unicast and
   multicast RTP packets.  Multicast receivers of SRTP session data
   therefore share an SRTP master key for message authentication and
   decryption.  This document describes how to establish a shared,
   "group key" for an SRTP session using RFC 3547, the Group Domain of
   Interpretation (GDOI) and RFC 2408, the Internet Security Association
   and Key Management Protocol.  This document extends GDOI for SRTP
   group key establishment.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Overview of This Document  . . . . . . . . . . . . . . . .  3
     1.2.  Conformance Language . . . . . . . . . . . . . . . . . . .  3
   2.  GDOI Signaling of an SRTP Crypto Context . . . . . . . . . . .  4
     2.1.  GDOI Signaling and SDP Signaling . . . . . . . . . . . . .  6
     2.2.  GDOI and EKT . . . . . . . . . . . . . . . . . . . . . . .  7
     2.3.  GDOI Exchanges for SRTP  . . . . . . . . . . . . . . . . .  8
     2.4.  SRTP SA-TEK Definitions  . . . . . . . . . . . . . . . . . 10
     2.5.  EKT SA-TEK Definitions . . . . . . . . . . . . . . . . . . 14
     2.6.  SRTP Key Download  . . . . . . . . . . . . . . . . . . . . 15
   3.  NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 16
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
     4.1.  No Sharing Counter-Mode Encryption Keys  . . . . . . . . . 17
     4.2.  Enable Distributed Key Management  . . . . . . . . . . . . 17
     4.3.  Support Strong Source Authentication . . . . . . . . . . . 18
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
   Intellectual Property and Copyright Statements . . . . . . . . . . 24















Baugher, et al.           Expires June 5, 2008                  [Page 2]


Internet-Draft                  GDOI-SRTP                  December 2007


1.  Introduction

   The Group Domain of Interpretation (GDOI) is an authenticated key
   establishment protocol for groups, which is specified by RFC 3547
   [RFC3547].  GDOI is based upon ISAKMP, the Internet Security
   Association and Key Management Protocol [RFC2408].  GDOI extends
   ISAKMP for group key management whereby a cryptographic key is shared
   among multiple receivers and optionally multiple senders.  GDOI uses
   unicast (ISAKMP) as well as multicast key establishment method and
   supports member revocation algorithms, such as the "key hierarchy"
   algorithm of RFC 2627 [RFC2627].  GDOI preserves the ISAKMP design,
   which supports new data security protocols through documented
   procedures, but it currently supports only one data security
   protocol, IPsec.

   This document extends GDOI to a new data security protocol, the
   Secure Real-time Transport Protocol (SRTP) as specified by RFC 3711
   [RFC3711].  SRTP extensions to GDOI use two new GDOI payloads.  The
   GDOI-SRTP payload definitions apply GDOI key establishment procedures
   to groups of SRTP receivers in accordance with Section 5.4.2 of the
   GDOI protocol specification [RFC3547].  The SRTP payloads carry keys,
   parameters, and other values needed for an SRTP session's
   "cryptographic context", which is described in Section 8 of the SRTP
   specification [RFC3711].  In addition to signaling SRTP, GDOI-SRTP
   payloads MAY signal use of the Encrypted Key Transport (EKT) protocol
   as an option [I-D.mcgrew-srtp-ekt].  These options, parameters and
   keys are defined in two GDOI payloads, the "Security Association
   Traffic Encrypting Key" (SA-TEK) payloads for SRTP (SRTP SA-TEK) and
   EKT (EKT SA-TEK).

1.1.  Overview of This Document

   Section 2 of this document presents the GDOI-SRTP payloads.  The SRTP
   SA-TEK payload MAY carry IP address and port information, which have
   implications for network address translation (NAT).  Section 3 gives
   NAT considerations, Section 4 discusses Security Considerations, and
   Section 5 lists IANA requirements.

1.2.  Conformance Language

   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 RFC 2119 [RFC2119].








Baugher, et al.           Expires June 5, 2008                  [Page 3]


Internet-Draft                  GDOI-SRTP                  December 2007


2.  GDOI Signaling of an SRTP Crypto Context

   A service can use GDOI to establish keys (security associations) for
   a data security protocol provided that GDOI is extended with one or
   more payload definitions for that data security protocol.  For GDOI,
   a "data security protocol" is any protocol that uses the services of
   GDOI.  By contrast, TLS key establishment is packaged with the TLS
   data-security protocol.  This memo will review the GDOI model and how
   the key management correlates to the traffic for which it provides
   keys.  GDOI follows the ISAKMP model in which key management and data
   security may use separate transport addresses and underlying
   transport protocols, typically UDP or TCP.  By default, GDOI uses UDP
   to negotiate an IKE phase 1 security association between a GDOI Group
   Controller/Key Server (GCKS) and group member; the IKE phase 1
   protects an exchange to establish a security association on behalf of
   an application security protocol.  In SRTP, a "security association"
   is called a "cryptographic context", and this is the application-
   specific information carried in GDOI payloads between the GCKS and a
   GDOI member.  This section defines these SRTP payloads for GDOI.
































Baugher, et al.           Expires June 5, 2008                  [Page 4]


Internet-Draft                  GDOI-SRTP                  December 2007


   Figure 2.0-1: Member and SRTP Interfaces in a Central GCKS
   Configuration

                    +-------+
                    |  GDOI |
                    |  GCKS |
                    +-------+
                        ^
                        |
                        V
           +--------------------------+
           | GDOI with SRTP payloads  |
           V                          V
      +----------+               +----------+
      |+--------+|               |+--------+|
      ||  GDOI  ||               ||  GDOI  ||
      || Member ||               || Member ||
      |+--------+|               |+--------+|
      |    ^     |               |    ^
      |    |     |               |    |     |
      |   API    |               |   API    |
      |    |     |               |    |     |
      |    V     |               |    V     |
      |+--------+|   SRTP/SRTCP  |+--------+|
      ||  SRTP  |---------------->|  SRTP  ||
      || Source |<----------------|Receiver||
      |+--------+|     SRTCP     |+--------+|
      +----------+               +----------+
        MEMBERi                    MEMBERj


   This section gives the SRTP payloads for GDOI key management
   exchanges.  SRTP is an application-layer security protocol that
   operates above the transport layer.  GDOI also operates above the
   transport service.  SRTP communicates with GDOI using the API shown
   in Figure 2.0-1.  SRTP or another application uses the API to request
   that GDOI establish an SRTP cryptographic context (i.e. a GDOI
   "security association"), which is described in Section 3.2 of the
   SRTP specification [RFC3711].  The API of Figure 2.0-1 is not
   considered further in this document, which is concerned solely with
   extending the GDOI protocol with new payloads for SRTP.  Using this
   protocol extension, the GDOI Group Controller/Key Server (GCKS) can
   provide the cryptographic keys, cryptographic parameters and session
   parameters to SRTP (via the API to a GDOI Member) in accordance with
   pre-configured group policy regarding which parameters are acceptable
   and which are not.  The GCKS might obtain policy and some SRTP
   crypto-context information through a user console or event database.
   The GCKS generates some information automatically, such as keying



Baugher, et al.           Expires June 5, 2008                  [Page 5]


Internet-Draft                  GDOI-SRTP                  December 2007


   materials.  How the GCKS obtains or generates policy information for
   the SRTP payload fields is specific to an implementation and not
   considered further in this document.

   Figure 2.0-2: A Distributed GCKS Configuration
                                +----------+
     +----------+               |+--------+|
    +|+--------+|  GDOI with    ||  GDOI  ||
    ||| GCKS & |<--------------->| GCKS & ||
    ||| Member ||  SRTP payloads|| Member ||
    ||+--------+|               |+--------+|
    ||    ^     |               |    ^     |
    ||    |     |               |    |     |
    ||   API    |               |   API    |
    ||    |     |               |    |     |
    ||    V     |               |    V     |
    ||+--------+|   SRTP/SRTCP  |+--------+|
    |||  SRTP  |---------------->|  SRTP  ||
    ||| Source |<----------------|Receiver||
    ||+--------+|     SRTCP     |+--------+|
    || MEMBERi  |               |  MEMBERj |
    |+----------+               +----------+
    |  MEMBERk |
    +----------+


   In the Distributed GCKS, each group member is physically co-located
   with its own GKCS.  This configuration is labeled a "Distributed
   GCKS" in Figure 2.0-2 in that the function of establishing the key
   for a particular sender to the group is distributed among each such
   sender to the group.  Whereas a centralized GCKS establishes keys for
   all senders to a group (Figure 2.0-1), a distributed GCKS establishes
   keys for a single sender to a group.  A distributed GCKS, therefore,
   is co-located with each sender to a group and is dedicated to
   maintaining the group keys for that member's "SRTP Source".  In this
   configuration, the GCKS can more easily obtain the SRTP-specific
   information for its payload across an API.  The distinction between
   Figures 2.0-1 and 2.0-2 are important because the SRTP data security
   protocol has tight coupling with its key management in the use of the
   SSRC, SEQ,and ROC parameters as discussed in the next section.

2.1.  GDOI Signaling and SDP Signaling

   SDP is a standard means to signal SRTP sessions when the SDP (RFC
   4566) transport identifier for a media session is "SAVP."  Some of
   the information contained in an SDP message is identical to the
   information conveyed in an GDOI-SRTP message such as the transport
   addresses.  This is unavoidable since both signaling messages need to



Baugher, et al.           Expires June 5, 2008                  [Page 6]


Internet-Draft                  GDOI-SRTP                  December 2007


   identify and describe the SRTP session.  There is generally more
   information in the GDOI-SRTP message than in the SDP such as the
   keying material for the session, and it is possible that the two
   messages may be linked.  For example, an SDP message could be used to
   trigger the initiation of the GDOI exchange for the SRTP session.
   For example, an RFC 4566 "k=" field can designate the URI of a GDOI
   key server in the SDP message.  In this case, k=http://
   GCKS.example.com would direct the receiver of the SDP message to
   obtain the keys for the SRTP session.  Such usage is Informative
   according to this document, not Normative, and further consideration
   of SDP signaling is beyond the scope of this document.

2.2.  GDOI and EKT

   When the Group Controller/Key Server (GCKS) is centralized as a
   third-party device, it is not co-located with the SRTP source, and it
   is not always possible for the GCKS to get access to important SRTP
   keystream parameters, which are the SSRC, the Rollover Counter (ROC)
   and current SRTP sequence number (SEQ).  This information is
   generated internally by the SRTP source and used in the SRTP ciphers
   and SRTP replay protection; the SSRC is used in combination with the
   destination transport address to identify an RTP session [RFC3550]
   and thus identify an SRTP session's crypto context.  When the GCKS is
   co-located with the SRTP source, this information can be obtained via
   the API shown in the above figures.  Such an API can be defined in an
   implementation.  But when the GCKS is physically separate from the
   SRTP source, GDOI has no over-the-wire protocol for collecting the
   SSRC, ROC and SEQ information from the source.  The Encrypted Key
   Transport (EKT) protocol solves this problem.

   EKT extends SRTCP to securely provide the SSRC, ROC and the SEQ from
   the SRTP source to the SRTP receiver, and EKT correctly initializes
   the SSRC, ROC and SEQ for late joiners to the multicast group or
   following RTP SSRC collision repair [I-D.mcgrew-srtp-ekt].  In a
   centralized GCKS configuration (Fig 2.0-1), EKT is RECOMMENDED in
   this document for transporting an SRTP sender's SSRC, ROC and SEQ to
   SRTP receivers.  In a distributed GCKS configuration, it is possible
   for the GCKS to correctly initialize the SSRC, ROC and SEQ by
   obtaining these values through an API with the GDOI member; in this
   case, it is RECOMMENDED that GDOI peform this function.  When the
   GCKS provides current SSRC, ROC and SEQ values, these are carried in
   GDOI-SRTP SA-TEK payload and the GDOI Key Download payload carries
   the SRTP master key and salt.  When EKT is used instead, the GDOI Key
   Download payload carries the EKT key.

   Whether or not to use EKT or to provide SRTP SSRC, ROC and SEQ
   parameters via GDOI SHALL be a configurable option in GDOI-SRTP.
   When the EKT option is not used, the SRTP receiver can begin



Baugher, et al.           Expires June 5, 2008                  [Page 7]


Internet-Draft                  GDOI-SRTP                  December 2007


   validating and decrypting packets without waiting for an EKT message
   to arrive in the SRTCP session.  EKT is needed, however, when the
   GCKS cannot reliably initialize the SA-TEK with SSRC, ROC and SEQ
   fields.

   When EKT is used, there are two SA-TEK payloads.  First, there is an
   SRTP SA-TEK payload that describes an SRTP master key and salt; the
   SRTP SA-TEK is always present.  Second, there is an EKT SA-TEK
   payload that describes an EKT key.  In either case, there is exactly
   one Key Download payload sent in a GDOI-SRTP exchange.  If EKT is
   signaled by the presence of an EKT SA-TEK, then the Key Download
   payload SHALL carry an EKT key.  If EKT is not signaled, then the KEY
   Download payload SHALL carry an SRTP master key and master salt.  In
   either case, there MUST be exactly one Key Download payload when
   signaling SRTP in GDOI.

2.3.  GDOI Exchanges for SRTP

   As mentioned above, GDOI exchanges for SRTP are protected by a "phase
   1 security association", which is an IKE phase 1 connection in which
   the GCKS and the member identify and authenticate each other.  For
   the IKE phase 1, RFC 3547 allows any defined IKE identity such as IP
   address, fully-qualified domain name or an opaque byte string that
   identifies a pre-shared key[ISAKMP-REG].  Also, any of the IKE
   authentication methods MAY be used including pre-shared key, public-
   key encryption, and digital signatures.  The IKE phase 1 connection
   is established using a six-message "Main Mode" exchange if identity
   protection is desired or a 3-message "Aggressive Mode" if identity
   protection is not needed [RFC2409].  With identity protection, a
   passive attack will not reveal the identities that the initiator or
   responder use to authenticate themselves.

   In GDOI, the initiator is usually the group member and the responder
   is usually the Group Controller/Key Server.  This is true in both the
   phase 1 and phase 2 exchanges.  The phase 2 exchange uses a 4-message
   exchange as defined in RFC 3547, Section 3 [RFC3547] and is
   reproduced below for the convenience of the reader.














Baugher, et al.           Expires June 5, 2008                  [Page 8]


Internet-Draft                  GDOI-SRTP                  December 2007


   Figure 2.3-1: GDOI Phase 2 Exchange, from Section 3.2 [RFC3547]

       Initiator (Member)                   Responder (GCKS)
       ------------------                   ----------------
       HDR*, HASH(1), Ni, ID     -->
                                 <--     HDR*, HASH(2), Nr, SA
       HDR*, HASH(3) [,KE_I]     -->
          [,CERT] [,POP_I]
                                 <--     HDR*, HASH(4),[KE_R,][SEQ,]
                                           KD [,CERT] [,POP_R]

    * Protected by the Phase 1 SA, encryption occurs after HDR


   When sent to the GDOI port, the message header (HDR) of Fig. 2.3-1
   identifies the phase 2 exchange, i.e. by the ISAKMP message id (M-ID)
   field of HDR.  Everything else is encrypted using the phase 1
   encryption key and authenticated in the HASH payloads that appear in
   each message.  A nonce and an ID are sent in the first message from
   the member to the GCKS, which responds by downloading the
   cryptographic parameters, session parameters, authentication policy
   and other information that the member needs to identify and
   authenticate itself to the GCKS.  The GCKS provides these parameters
   and policy information in the Security-Association (SA) payload of
   the second message along with its nonce, Nr.  As described in the
   previous section of this document, how these policies and parameters
   are defined is out of scope for this document.  The successful GDOI-
   SRTP exchange establishes an SRTP cryptographic context (i.e. a
   security association among SRTP endpoints).

   The third message of Fig 2.3-1 is from the member to the GCKS.  If
   perfect forward secrecy is desired, Diffie-Hellman public value are
   exchanged in the Key-Exchange (KE) payloads (KE_I and KE_R), which
   are optional.  If additional authorization and authentication are
   desired beyond the IKE Phase 1, then a digital certificate can be
   passed in a Cerficate (CERT) payload with an optional proof-of-
   possession exchange to prove possession of the corresponding private
   key (POP_I and POP_R).

   The fourth and final message concludes a successful GDOI phase 2
   exchange by passing a Key-Download (KD) payload.  Any KE, CERT or POP
   exchanges are completed in the final message.  Another optional field
   is SEQ, which is the sequence number associated with messages that
   are sent (pushed) from the GCKS to the member.  For pushed messages,
   the SA payload will include a GDOI key-encrypting key (KEK)
   definition in an SA-KEK payload.  A GDOI group will not use pushed
   messages if it does not need to perform key update of the SRTP Master
   Key (SA-TEK) or member revocation.  Thus, an SA-KEK is OPTIONAL



Baugher, et al.           Expires June 5, 2008                  [Page 9]


Internet-Draft                  GDOI-SRTP                  December 2007


   whereas one or two SA-TEKs are REQUIRED by this document; these are
   the SRTP SA-TEK and the optional EKT SA-TEK.  The SA-KEK and SA-TEK
   are part of the SA payload shown in Figure 2.3-1.

2.4.  SRTP SA-TEK Definitions

   The RFC 3547 SA TEK payload has a header and a protocol-specific
   payload.  The SRTP SA TEK is identified by the GDOI_PROTO_SRTP value
   (assigned by IANA) in the Protocol-ID field of the SA TEK header,
   which is defined in Section 5.4 of RFC 3547 [RFC3547].  The SA TEK
   protocol-specific payload for SRTP is given in Figure 2.3-1.  The SAT
   Payload fields are shown in Figure 2.4-1.

   Figure 2.4-1: SRTP SA-TEK

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
       !  SRC ID Type  !         SRC ID Port           !SRC ID Data Len!
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
       !                    SRC Identification Data                    ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
       ! DST ID Type   !         DST ID Port           !DST ID Data Len!
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
       !                    DST Identification Data                    ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
       ! Replay Window !     KD Rate   ! SRTP Lifetime ! SRTCP Lifetime!
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
       !   Options     ! Crypto Suite  !      SPI      !  Attributes   ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

     Attribute Class       Value      Type
     ---------------       -----      ----
     RESERVED                0
     SSRC                    1          B
     ROC                     2          B
     SEQ                     3          B
     MKI                     4          V


   The Group Controller/Key Server (GCKS) provides SA-TEK and Key-
   Download payload information to an SRTP implementation through the
   GDOI member to SRTP, which uses this information to initialize the
   cryptographic context of an SRTP session.  An SRTP crypto context is
   identified by the SSRC and RTP destination transport address as
   explained in Section 8 of the SRTP specification [RFC3711].  The RTP
   destination address is identified in the SA-TEK, which is shown in
   Figure 2.4-1.  The "DST ID Type" defines the type of DST



Baugher, et al.           Expires June 5, 2008                 [Page 10]


Internet-Draft                  GDOI-SRTP                  December 2007


   Identification data, which is an IP address or a fully-qualified
   domain name that resolves to one.  The destination port is also
   carried in the DST ID Port, also shown in Figure 2.4-1 following the
   similar definitions for the source.

   Replay window, key-derivation (KD) rate, SRTP and SRTCP lifetimes are
   the crypto context parameters for the particular SRTP session.  Also
   shown in Figure 2.4-1 is the options field, that declares values for
   boolean SRTP configuration parameters and also whether EKT is to be
   used or not.  Crypto Suite identifies the SRTP encryption and
   authentication transforms.  GDOI-SRTP uses the same encryption and
   authentication transforms for SRTP and SRTCP.  Finally, the SPI is
   the "security parameter index", which identifies the particular
   security association (SRTP crypto context) by a 8-bit number, a
   positive integer.

   The Attributes payloads are optional.  The attributes must follow the
   format defined in ISAKMP [RFC3547] section 3.3.  In the table,
   attributes that are defined as TV are marked as Basic (B); attributes
   that are defined as TLV are marked as Variable (V).  The SSRC,
   rollover counter (ROC) and current sequence number (SEQ) MAY be
   carried in the SA TEK payload that is shown in Figure 2.4-1.  When
   the SSRC, ROC and the SEQ are not carried in the SRTP SA-TEK payload,
   the EKT protocol SHOULD be used [I-D.mcgrew-srtp-ekt].

   Each of the fields of Figure 2.4-1 is defined as follows.

   o  SRC ID Type (1 octet) -- Value describing the identity information
      found in the SRC Identification Data field.  Defined values are
      specified by the IPSEC Identification Type section in the IANA
      isakmp-registry [ISAKMP-REG].

   o  SRC ID Port (2 octets) -- Value specifying a port associated with
      the SRC Identification data.  A value of zero means that the SRC
      ID Port field should be ignored.

   o  SRC ID Data Len (1 octet) -- Value specifying the length of the
      SRC Identification Data field.

   o  SRC Identification Data (variable length) -- Value as indicated by
      the SRC ID Type.  According to RFC 3547, SRC Identification Data
      consists of three bytes of zero for multiple-source multicast
      groups that use a common TEK for all senders.  The TEK in an SRTP
      Key Download payload is an SRTP master key, however, and it is NOT
      RECOMMENDED that this key be shared for the counter mode and f8
      ciphers of SRTP.  Thus, it is NOT RECOMMENDED that this field
      consist of three bytes of zero, because that would cause the TEK
      to be shared.  It SHOULD be ID_FQDN (see the "NAT Considerations"



Baugher, et al.           Expires June 5, 2008                 [Page 11]


Internet-Draft                  GDOI-SRTP                  December 2007


      section).

   o  DST ID Type (1 octet) -- Value describing the identity information
      found in the DST Identification Data field.  Defined values are
      specified by the IPSEC Identification Type section in the IANA
      isakmpd-registry [ISAKMP-REG].

   o  DST ID Port (2 octets) -- Value specifying a port associated with
      the source Id.  A value of zero means that the DST ID Port field
      should be ignored.

   o  DST ID Data Len (1 octet) -- Value specifying the length of the
      DST Identification Data field.

   o  DST Identification Data (variable length) -- Value, as indicated
      by the DST ID Type.

   o  Replay Window Size (1 octet) - The suggested size of the SRTP
      Replay Window as specified in Section 3.3.2 of the SRTP standard
      [RFC3711].

   o  KD Rate (1 octet) - SRTP Key Derivation Rate as specified in
      Section 4.3.1, second paragraph of the standard [RFC3711].  KD
      Rate is an integer that is greater than or equal to zero.  The
      SRTP "packet index" of an outgoing or incoming SRTP packet is
      computed modulo the KD Rate in cases where the KD Rate is greater
      than zero.  The reader is referred to Sections 3.3.1 and 4.3.1 of
      the SRTP specification for the definitions of "packet index" and
      "Key Derivation Rate".

   o  SRTP Lifetime (1 octet) - The SRTP key lifetime is encoded as an
      integer N to represent a lifetime of 2^N packets, where N cannot
      exceed the maximum lifetime as specified by the Crypto Suite.  A
      value of zero signals the SRTP default (N=48).  It is recommended
      that SRTP Lifetime be set to the default.

   o  SRTCP Lifetime (1 octet) - The SRTCP key lifetime is encoded as an
      integer N to represent a lifetime of 2^N packets, where N cannot
      exceed the maximum lifetime as specified by the Crypto Suite.  A
      value of zero signals the SRTP default (N=31).  It is recommended
      that SRTCP Lifetime be set to the default.

   o  Options (1 octet) - Reading from left to right (big-endian), SRTP
      is unencrypted when bit 0 is set to '1'.  SRTP is unauthenticated
      when bit 1 is set to '1'.  SRTCP is unencrypted when bit 2 is set
      to '1'.  The SSRC, ROC and SEQ are not included and MUST be
      ignored when bit 3 is set to '1'.




Baugher, et al.           Expires June 5, 2008                 [Page 12]


Internet-Draft                  GDOI-SRTP                  December 2007


   o  SSRC (2 octets) - Value of the Sender's SSRC when there is a
      single sender associated with the KEK and TEK signaled in the SA-
      TEK and Key Download payload.

   o  Crypto Suite (2 octets) -- The set of parameters that defines the
      SRTP and SRTCP encryption transform, authentication transform, key
      length, and salt length.  The values are defined in the Table
      2.4-2.  Each row in the table defines a suite of parameters.  Any
      parameter can be changed and new parameters added by creating a
      new Crypto Suite, documenting it in an Internet RFC, and
      requesting a Suite Value for it from IANA.  The lifetimes
      mentioned in the crypto-suites are superseded by the lifetimes
      passed in the fields mentioned above.

      Table 2.4-2: SRTP Crypto Suites

      Suite        Master  Master Max SRTP Max SRTCP
      Value Cipher Keylen Saltlen Lifetime Lifetime MAC/len
      ----- ------ ------ ------- -------- -------- -------
          0 AES-CM    128     112     2^48     2^31 HMAC-SHA1/80
          1 AES-CM    128     112     2^48     2^31 HMAC-SHA1/32
          2 AES-F8    128     112     2^48     2^31 HMAC-SHA1/80
          3 AES-CM    192     112     2^48     2^31 HMAC-SHA1/80
          4 AES-CM    192     112     2^48     2^31 HMAC-SHA1/32
          5 AES-CM    256     112     2^48     2^31 HMAC-SHA1/80
          6 AES-CM    256     112     2^48     2^31 HMAC-SHA1/32
          7-127 RESERVED
      Note: All keylen values are in bits

      The key values of 192 and 256 are specified in the "BIG AES"
      Internet Draft document [I-D.mcgrew-srtp-big-aes].  In the vast
      majority of SRTP applications, the BIG AES values SHOULD NOT be
      used since they do not increase security as a practical matter but
      could diminish interoperability, see Section 7 of the Big AES I-D.

   o  SPI (2 octets) - The value of the security parameter index that
      identifies this security association between the GCKS and the
      group member.

   o  SSRC (1 octet) - The value of the SRTP SSRC; this attribute MUST
      be present when bit 3 of Options is cleared ('0') but MUST be
      ignored otherwise.

   o  ROC (4 octets) - The current value of the SRTP rollover counter
      (ROC); this attribute value MUST be present when bit 3 of Options
      is cleared ('1') but MUST be ignored otherwise.





Baugher, et al.           Expires June 5, 2008                 [Page 13]


Internet-Draft                  GDOI-SRTP                  December 2007


   o  SEQ (2 octets) - The current value of the SRTP sequence number;
      this attribute MUST be present when bit 3 of Options is cleared
      ('0') but MUST be ignored otherwise.

   o  MKI Length(variable) - An SRTP Master Key Indicator (MKI) SHALL
      appear in SRTP packets when this attribute is present.  As defined
      in Section 3 of RFC 3711 [RFC3711], the maximum MKI length is 128
      (bytes) though a smaller length of one or two bytes IS
      RECOMMENDED.  The MKI Length attribute MUST be present when an MKI
      attribute is given.  It is RECOMMENDED that the MKI Length be zero
      (i.e., the MKI is not being used) unless there is a compelling
      reason to change SRTP master keys for a particular source.

2.5.  EKT SA-TEK Definitions

   EKT is an abbreviation for "encrypted key transport", which carries
   an SRTP master key, SEQ and ROC in an SRTCP packet.  As described
   above, these values are generated internally to SRTP, and a central
   GCKS typically cannot obtain these values and the SSRC when it has no
   interface to the SRTP sender.  In this case, EKT is RECOMMENDED as a
   means to correctly initialize an SRTP receiver with the SSRC, SEQ,
   ROC and SRTP master key.  In this case, GDOI-SRTP serves to
   initialize the EKT system in a GDOI member by providing EKT
   parameters and a key called the "EKT key", which is used to encrypt
   the SRTP master key in the SRTCP packet.  Thus, the security
   association between the GCKS and GDOI member establishes and
   maintains an EKT key.

   The EKT identifying information and parameters are shown in Figure
   2.5-1.

   Figure 2.5-1: EKT-TEK

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
       ! DST ID Type   !         DST ID Port           !DST ID Data Len!
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
       !                    DST Identification Data                    ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
       !  EKT Cipher   !       SPI     !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Each of the fields of Figure 2.5-1 is defined as follows.





Baugher, et al.           Expires June 5, 2008                 [Page 14]


Internet-Draft                  GDOI-SRTP                  December 2007


   o  DST ID Type (1 octet) -- Value describing the identity information
      found in the DST Identification Data field.  Defined values are
      specified by the IPSEC Identification Type section in the IANA
      isakmpd-registry [ISAKMP-REG].

   o  DST ID Port (2 octets) -- Value specifying a port associated with
      the source Id.  A value of zero means that the DST ID Port field
      should be ignored.

   o  DST ID Data Len (1 octet) -- Value specifying the length of the
      DST Identification Data field.

   o  DST Identification Data (variable length) -- Value, as indicated
      by the DST ID Type.

   o  EKT Cipher (1 octet) - Value specifying the cipher and mode used
      by EKT for the EKT key, which is carried in a GDOI Key Download
      payload.  The following table correlates each EKT Cipher Suite
      [I-D.mcgrew-srtp-ekt] with a Suite Value.  New EKT Cipher Suites
      MAY be added when documented by an Internet RFC and once IANA
      assigns a Suite Value to that Cipher Suite.

      Table 2.5-2: EKT Cipher Suites

      EKT Cipher     Suite
        Suite        Value
       ------        -----
      RESERVED         0
      AES_128          1
      AESKW_128        2
      AESKW_196        3
      AESKW_256        4
      RESERVED         5-127

   o  EKT SPI (1 octet) - The EKT security parameter index, which
      identifies the EKT security association between the GCKS and the
      GDOI member.

2.6.  SRTP Key Download

   The SRTP SA-TEK Crypto Suite of Table 2.4-2 defines both the SRTP
   master key and master salt.  These two values are concatenated, with
   the SRTP master key being followed by the SRTP master salt, in a Key
   Download (KD) payload's TEK_ALGORITHM_KEY attribute.

   When EKT is used, there is no KD payload corresponding to the SRTP
   SA-TEK.  Instead, the KD payload carries the EKT key as defined by
   the EKT SA-TEK EKT Cipher.



Baugher, et al.           Expires June 5, 2008                 [Page 15]


Internet-Draft                  GDOI-SRTP                  December 2007


3.  NAT Considerations

   Transport addresses are carried in the SA-TEK payloads and this
   contradicts recommendations for application-layer signaling through
   network address translators (NATs) [RFC2663][RFC3235].  The SA-TEK
   destination IP address and port, however, are multicast addresses
   which are not re-written by a NAT.  The source address, however,
   might be re-written on outgoing multicast packets
   [I-D.wing-behave-multicast].

   If the SA TEK SRC ID type of Figure 2.4-1 is an IP address and if
   there is an outgoing NAT that re-writes the source IP address field
   of outgoing packets, then there will likely be a discrepancy between
   the source address in the IP packet and the SRC Identification Data
   field of Figure 2.4-1.  It is therefore RECOMMENDED that SRC ID Type
   be ID_FQDN [ISAKMP-REG] whenever there is network address translation
   present on the network of the multicast source.


































Baugher, et al.           Expires June 5, 2008                 [Page 16]


Internet-Draft                  GDOI-SRTP                  December 2007


4.  Security Considerations

   The security of GDOI and its payloads is discussed in Section 6 of
   the GDOI specification [RFC3547].  The security of SRTP and its
   parameter settings is discussed in Section 9 of the SRTP
   specification[RFC3711].  There are some additional risks in GDOI and
   SRTP that are considered here.

4.1.  No Sharing Counter-Mode Encryption Keys

   One risk is the proper establishment of the SRTP SSRC, which is
   subject to SSRC collisions that might be exploited by an attacker.
   SRTP specifies that the SSRC is used in the AES counter mode and f8
   initialization vectors (IV) to prevent counter reuse.  RFC 3711
   states that key management "SHOULD" install a unique SSRC.  GDOI
   relaxes this requirement since SSRCs collide.  It is also difficult
   to support an unchanged RTP module in a "bump-in-the-stack" SRTP
   configuration.  Instead of depending on SSRC uniqueness, IT IS
   RECOMMENDED that the GDOI SA-TEK SHOULD provide a unique SRTP master
   key for each sender.

   To ensure SRTP master key uniqueness among senders to an SRTP
   session, SA-TEK SRC Identification Data (Figure 2.4.1) MUST NOT
   signal a group of senders sharing a key.  GDOI specifies a means for
   sharing a traffic encrypting key (TEK) among senders, but a GDOI TEK
   is an SRTP master key and this specification RECOMMENDS that a TEK
   SHOULD NOT be shared among SRTP sources.

4.2.  Enable Distributed Key Management

   In many cases, SRTP sources are not co-located with a GCKS.  This is
   one possible configuration in a large scale "video pump", for
   example, that is specialized to a purpose other than key management.
   If there are geographically-dispersed video-pump sources, there is
   the risk that the GCKS will be attacked and its ability to
   disseminate source-unique values to such as the ROC to the multicast
   group will be impaired.  This is one possible attack out of many
   where a central GCKS can disrupt the entire multicast group of SRTP
   receivers.  This document RECOMMENDS the use of EKT to securely
   distribute the SSRC, ROC and SEQ.  GDOI-SRTP payloads signal the EKT
   Key.

   Two protocols have more vulnerabilities than one, however, and there
   are added risks that come from using both GDOI and EKT.  A
   programming bug in GDOI (e.g. signaling zeros in SA-TEK SRC
   Identification Data), for example, might cause an attack on EKT (e.g.
   a distributed denial of service attack on a group of EKT receivers).
   In some cases, a feature that is useful for M:N groups might be risky



Baugher, et al.           Expires June 5, 2008                 [Page 17]


Internet-Draft                  GDOI-SRTP                  December 2007


   when used in 1:N groups.  For these reasons, the GDOI-SRTP SA-TEK
   SHOULD explicitly signal each source and provides a source TEK (SRTP
   Master Key) as well as a KEK (EKT Key).  In extraordinary cases such
   as SSRC collision, the SSRC and SRTP master key MAY come from EKT,
   but in normal operation only the SEQ and ROC SHOULD be obtained from
   EKT.

4.3.  Support Strong Source Authentication

   Despite the precautions described above, there is always the
   possibility of "source spoofing" when any member of the group
   authorized only to receive can impersonate an authorized sender.
   This is a limitation in symmetric-key authentication in secure
   groups.  To address this problem, SRTP can use TESLA source
   authentication messaging [RFC4383].  A future revision of this
   document will consider TESLA signaling.



































Baugher, et al.           Expires June 5, 2008                 [Page 18]


Internet-Draft                  GDOI-SRTP                  December 2007


5.  IANA Considerations

   IANA is requested to register "GDOI_PROTO_SRTP" with a new value and
   that additional values be added to the Security Association Traffic
   Encrypting Key payload definitions, "SA TEK Payload Values"
   [GDOI-REG], as follows.

   1.  Table 2.1-2: SRTP Crypto Suites.

   2.  Table 2.1-3: EKT Cipher Suites









































Baugher, et al.           Expires June 5, 2008                 [Page 19]


Internet-Draft                  GDOI-SRTP                  December 2007


6.  Acknowledgements

   The authors thank David McGrew, Brian Weis and Liu Ya for their
   helpful comments.















































Baugher, et al.           Expires June 5, 2008                 [Page 20]


Internet-Draft                  GDOI-SRTP                  December 2007


7.  References

7.1.  Normative References

   [GDOI-REG]
              "Group Domain of Interpretation (GDOI) Payloads - per
              [RFC3547], http://www.iana.org/assignments/gdoi-payloads",
              2003.

   [I-D.mcgrew-srtp-big-aes]
              McGrew, D., "The use of AES-192 and AES-256 in Secure
              RTP", draft-mcgrew-srtp-big-aes-00 (work in progress),
              April 2006.

   [I-D.mcgrew-srtp-ekt]
              McGrew, D., "Encrypted Key Transport for Secure RTP",
              draft-mcgrew-srtp-ekt-03 (work in progress), July 2007.

   [ISAKMP-REG]
              "FROM RFC 2407 and RFC 2408 Magic Numbers for ISAKMP
              Protocol,
              http://www.iana.org/assignments/isakmp-registry",
              September 2006.

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

   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

   [RFC2627]  Wallner, D., Harder, E., and R. Agee, "Key Management for
              Multicast: Issues and Architectures", RFC 2627, June 1999.

   [RFC3547]  Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
              Group Domain of Interpretation", RFC 3547, 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.

   [RFC4383]  Baugher, M. and E. Carrara, "The Use of Timed Efficient
              Stream Loss-Tolerant Authentication (TESLA) in the Secure
              Real-time Transport Protocol (SRTP)", RFC 4383,
              February 2006.



Baugher, et al.           Expires June 5, 2008                 [Page 21]


Internet-Draft                  GDOI-SRTP                  December 2007


7.2.  Informative References

   [I-D.wing-behave-multicast]
              Wing, D., "IGMP Proxy Behavior",
              draft-wing-behave-multicast-00 (work in progress),
              October 2004.

   [RFC2408]  Maughan, D., Schneider, M., and M. Schertler, "Internet
              Security Association and Key Management Protocol
              (ISAKMP)", RFC 2408, November 1998.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC3235]  Senie, D., "Network Address Translator (NAT)-Friendly
              Application Design Guidelines", RFC 3235, January 2002.


































Baugher, et al.           Expires June 5, 2008                 [Page 22]


Internet-Draft                  GDOI-SRTP                  December 2007


Authors' Addresses

   Mark Baugher
   Cisco Systems, Inc.
   800 East Tasman Drive
   San Jose, CA  95164
   US

   Phone: (503) 245-4543
   Email: mbaugher@cisco.com


   Adrian-Ken Rueegsegger
   secunet SwissIT AG
   Hauptbahnhofstrasse 12
   4501 Solothurn,
   Switzerland

   Phone: +41 32 625 80 40
   Email: rueegsegger@swiss-it.ch


   Sheela Rowles
   Cisco Systems, Inc.
   1700 West Tasman Drive
   San Jose, CA  95134-1706
   US

   Phone: (408) 527-7677
   Email: srowles@cisco.com





















Baugher, et al.           Expires June 5, 2008                 [Page 23]


Internet-Draft                  GDOI-SRTP                  December 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).





Baugher, et al.           Expires June 5, 2008                 [Page 24]


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