Network Working Group                                         M. Baugher
Internet-Draft                                       Cisco Systems, Inc.
Expires: April 17, 2007                                   A. Rueegsegger
                                                        October 14, 2006


       GDOI Key Establishment for the SRTP Data Security Protocol
                  draft-baugher-msec-gdoi-srtp-00.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 April 17, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The Secure Real-time Transport Protocol (SRTP) secures unicast and
   multicast media streams.  Multicast receivers of an SRTP stream
   therefore share an SRTP master key for multicast 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.



Baugher & Rueegsegger    Expires April 17, 2007                 [Page 1]

Internet-Draft                  GDOI-SRTP                   October 2006


Table of Contents

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






























Baugher & Rueegsegger    Expires April 17, 2007                 [Page 2]

Internet-Draft                  GDOI-SRTP                   October 2006


1.  Introduction

   The Group Domain of Interpretation (GDOI) is specified in 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.  GDOI uses both unicast and multicast key
   establishment, and can support messaging for member revocation
   algorithms, such as the "key hierarchy" algorithm [RFC2627].  GDOI
   preserves the ISAKMP design, which supports new data security
   protocols through documented procedures.  GDOI currently supports
   only one data security protocol, IPsec.

   This document presents GDOI payloads for another data security
   protocol, the Secure Real-time Transport Protocol (SRTP).  These
   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].  GDOI carries keys, parameters, and
   other values needed for an SRTP session's "cryptographic context",
   which is described in Section 8 of the SRTP specification [RFC3711].
   The GDOI-SRTP payloads MAY signal use of the EKT protocol as an
   option for secure dissemination of internally-generated SRTP
   parameters [I-D.mcgrew-srtp-ekt].  These options, parameters and keys
   are contained in two GDOI payloads, the "Key Download" (KD) and the
   "Security Association Traffic Encrypting Key" (SA-TEK) payloads.

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 has
   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 & Rueegsegger    Expires April 17, 2007                 [Page 3]

Internet-Draft                  GDOI-SRTP                   October 2006


2.  SRTP Definitions for GDOI Signaling

   An application can use GDOI to establish security associations for a
   data security protocol when GDOI is extended with one or more
   payloads for that data security protocol.  Payloads are carried in
   GDOI message exchanges between a GDOI Group Controller/Key Server
   (GCKS) and a GDOI member, as shown in Figure 2.0-1.

   Figure 2.0-1: GDOI and SRTP Interfaces

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

   This section specifies the SRTP payloads for GDOI key management
   exchanges.  SRTP is an application-layer security protocol that
   operates above the TCP/IP services (sockets) interface.  GDOI also
   operates above the transport service.  SRTP communicates with GDOI
   using the API shown in Figure 2.0-1.  Using the API, SRTP or another
   application requests that GDOI establish an SRTP cryptographic
   context (a "security association" in GDOI parlance), 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 with extending the GDOI protocol with a new payload.
   Using this protocol extension, the GDOI Group Controller/Key Server
   (GCKS) provides the cryptographic keys, policies and other attributes
   to SRTP (via the API to a GDOI Member).  The GCKS might obtain some
   of this information through a user console or event database, and it



Baugher & Rueegsegger    Expires April 17, 2007                 [Page 4]

Internet-Draft                  GDOI-SRTP                   October 2006


   generates some information automatically, such as keying materials.
   How the GCKS obtains or generates information for the SRTP payload
   fields is not considered further in this document.

   Figure 2.0-2: GDOI GCKS Co-located with GDOI Member

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


   Figure 2.0-1 is a logical diagram.  In a physical realization of the
   system, the GDOI GKCS can either be separate from or co-located with
   a GDOI Member.  When physically co-located with a member, the GCKS
   can be dedicated to maintaining the group keys for that member's
   "SRTP Source", and the GCKS can more easily obtain the SRTP-specific
   information for its payloads across the API.  This configuration is
   shown in Figure 2.0-2.  It is often more efficient for the GCKS to be
   physically co-located in the same computer as the SRTP source of the
   multicast stream.

2.1.  GDOI and EKT

   It is not always possible for GCKS to obtain all the needed SRTP
   information.  In order to establish an SRTP session, an SRTP system
   requires some internally-generated SRTP information along with keys.
   This information is the SSRC, the rollover counter (ROC), and the
   sequence number (SEQ).  The ROC and SEQ are used by the SRTP ciphers,
   and they are used in SRTP replay protection; the SSRC is used in
   combination with the destination transport address to identify an RTP
   session [RFC3550] and thus an SRTP session's crypto context.  The SEQ
   and ROC values are generated internally by the SRTP source.  When the
   GCKS is co-located with the GDOI Member and the SRTP source, however,
   this information can be obtained via the API shown in the above
   figures.  But when the GCKS is physically separate from the SRTP
   source, GDOI has no over-the-wire protocol for collecting such SSRC,
   ROC and SEQ information from a multicast source.



Baugher & Rueegsegger    Expires April 17, 2007                 [Page 5]

Internet-Draft                  GDOI-SRTP                   October 2006


   The EKT protocol offers a solution to the problem of securely
   providing 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 or following RTP SSRC collision repair
   [I-D.mcgrew-srtp-ekt].  EKT is RECOMMENDED in this document for
   transport of an SRTP sender's SSRC, ROC and SEQ to SRTP receivers.
   When it is possible for the GCKS to correctly initialize the SSRC,
   ROC and SEQ, however, it is RECOMMENDED that the Key Download also
   carry the SRTP master key and salt as this will allow the SRTP
   receiver to begin validating and decrypting packets without waiting
   for an EKT message to arrive in the SRTCP.  EKT is particularly
   useful when the GCKS cannot reliably initialize the SA-TEK with SSRC,
   ROC and SEQ fields.  When EKT is used, the SA-TEK at minimum signals
   EKT in the SA-TEK Options field and provides the EKT Key in a Key
   Download payload.

2.2.  SRTP SA-TEK Definitions

   Figure 2.2-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 Date Len!
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
      !                    SRC Identification Data                    ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
      ! DST ID Type   !         DST ID Port           !DST ID Data Len!
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
      !                    DST Identification Data                    ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
      !   Options     !              SSRC             ! Crypto Suite  !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
      ! Replay Window !     KD Rate   ! SRTP Lifetime ! SRTCP Lifetime!
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
      !                              ROC                              ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
      !      SEQ                      !  MKI Length   ! MKI (Optional)~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
      !  EKT Cipher   ! EKT SPI Length!          EKT SPI              !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   GDOI provides SA-TEK and Key-Download payload information to an SRTP
   implementation, 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 SRTP



Baugher & Rueegsegger    Expires April 17, 2007                 [Page 6]

Internet-Draft                  GDOI-SRTP                   October 2006


   rollover counter (ROC) and current sequence number (SEQ) MAY be
   carried in the SA TEK payload that is shown in Figure 2.2-1.  When
   the ROC and the SEQ are not carried in the SRTP SA-TEK payload, the
   EKT protocol SHOULD be used [I-D.mcgrew-srtp-ekt], in which case the
   SA-TEK carries EKT information as shown in Figure 2.2-1.  In either
   case, GDOI-SRTP uses the same encryption and authentication
   transforms for SRTP and SRTCP.

   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
   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.2-1.  The SAT Payload fields
   are 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
      isakmpd-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.  It SHOULD be ID_FQDN (see the
      "NAT Considerations" 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.



Baugher & Rueegsegger    Expires April 17, 2007                 [Page 7]

Internet-Draft                  GDOI-SRTP                   October 2006


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

   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'.  EKT is not used when bit 3 is set to '1'.  The SSRC, ROC
      and SEQ are not included and MUST be ignored when bit 4 is set to
      '1'.

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

   o  Crypto Suite (1 octet) -- 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.1-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.

      Table 2.1-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  Replay Window Size (1 octet) - The size of SRTP Replay Window as
      specified in Section 3.3.2 of the 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



Baugher & Rueegsegger    Expires April 17, 2007                 [Page 8]

Internet-Draft                  GDOI-SRTP                   October 2006


      Rate is an integer that is greater than or equal to zero.  The
      modulus of 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.

   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.

   o  ROC (4 octets) - When bit 4 of Opions is cleared to '0', this
      field contains the current value of the SRTP ROC.

   o  SEQ (2 octets) - When bit 4 of Options is cleared to '0', this
      field contains the current SRTP SEQ.

   o  MKI Length (1 octet) - An SRTP Master Key Indicator (MKI) SHALL
      appear in SRTP packets when this field is nonzero.  The MKI field
      is the length of the SRTP MKI 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.

   o  MKI (optional, variable length) - The SRTP MKI is present when the
      SRTP MKI Length is nonzero.  The value of the SRTP MKI Length
      determines the number of bytes in the width of this field.

   o  EKT Cipher (1 octet) - When bit 3 of the SRTP Options field is
      cleared to '0', EKT parameters appear in the SA TEK payload.  "EKT
      Cipher" is 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.










Baugher & Rueegsegger    Expires April 17, 2007                 [Page 9]

Internet-Draft                  GDOI-SRTP                   October 2006


      Table 2.1-3: 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 Len (1 octet) - The length of the EKT SPI.

   o  EKT SPI (variable length) - The EKT SPI.

2.3.  SRTP Key Download

   The Crypto Suites of Table 2.1-2 define two keys, the SRTP master key
   and master salt key.  These two keys are concatenated with the SRTP
   master key followed by the SRTP master salt in a Key Download (KD)
   payload's TEK_ALGORITHM_KEY attribute.

   When EKT is used, EKT key is carried as a KEK_ALGORITHM_KEY
   attribute.


























Baugher & Rueegsegger    Expires April 17, 2007                [Page 10]

Internet-Draft                  GDOI-SRTP                   October 2006


3.  NAT Considerations

   Transport addresses are carried in the SA-TEK payload and this
   contradicts recommendations for application-layer signaling through
   network address translators (NATs) [RFC2663][RFC3235].  The
   destination IP address and port, however, are multicast addresses and
   these 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.1-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.1-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 & Rueegsegger    Expires April 17, 2007                [Page 11]

Internet-Draft                  GDOI-SRTP                   October 2006


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 to 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 and 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.1.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
   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 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 & Rueegsegger    Expires April 17, 2007                [Page 12]

Internet-Draft                  GDOI-SRTP                   October 2006


   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 & Rueegsegger    Expires April 17, 2007                [Page 13]

Internet-Draft                  GDOI-SRTP                   October 2006


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 & Rueegsegger    Expires April 17, 2007                [Page 14]

Internet-Draft                  GDOI-SRTP                   October 2006


6.  Acknowledgements

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















































Baugher & Rueegsegger    Expires April 17, 2007                [Page 15]

Internet-Draft                  GDOI-SRTP                   October 2006


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-01 (work in progress), June 2006.

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

   [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 & Rueegsegger    Expires April 17, 2007                [Page 16]

Internet-Draft                  GDOI-SRTP                   October 2006


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 & Rueegsegger    Expires April 17, 2007                [Page 17]

Internet-Draft                  GDOI-SRTP                   October 2006


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
   Bocksteinstrasse 2
   4583 Muehledorf,
   Switzerland

   Phone: +41 32 661 10 88
   Email: adrian.rueegsegger@students.fhnw.ch
































Baugher & Rueegsegger    Expires April 17, 2007                [Page 18]

Internet-Draft                  GDOI-SRTP                   October 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Baugher & Rueegsegger    Expires April 17, 2007                [Page 19]