<pre>Network Working Group                                         M. Baugher
Request for Comments: 4046                                         Cisco
Category: Informational                                       R. Canetti
                                                                     IBM
                                                              L. Dondeti
                                                                Qualcomm
                                                             F. Lindholm
                                                                Ericsson
                                                              April 2005


      <span class="h1">Multicast Security (MSEC) Group Key Management Architecture</span>

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines the common architecture for Multicast Security
   (MSEC) key management protocols to support a variety of application,
   transport, and network layer security protocols.  It also defines the
   group security association (GSA), and describes the key management
   protocols that help establish a GSA.  The framework and guidelines
   described in this document permit a modular and flexible design of
   group key management protocols for a variety of different settings
   that are specialized to applications needs.  MSEC key management
   protocols may be used to facilitate secure one-to-many, many-to-many,
   or one-to-one communication.

Table of Contents

   <a href="#section-1">1</a>. Introduction: Purpose of this Document ..........................<a href="#page-2">2</a>
   <a href="#section-2">2</a>. Requirements of a Group Key Management Protocol .................<a href="#page-4">4</a>
   <a href="#section-3">3</a>. Overall Design of Group Key Management Architecture .............<a href="#page-6">6</a>
      <a href="#section-3.1">3.1</a>. Overview ...................................................<a href="#page-6">6</a>
      <a href="#section-3.2">3.2</a>. Detailed Description of the GKM Architecture ...............<a href="#page-8">8</a>
      <a href="#section-3.3">3.3</a>. Properties of the Design ..................................<a href="#page-11">11</a>
      <a href="#section-3.4">3.4</a>. Group Key Management Block Diagram ........................<a href="#page-11">11</a>
   <a href="#section-4">4</a>. Registration Protocol ..........................................<a href="#page-13">13</a>
      <a href="#section-4.1">4.1</a>. Registration Protocol via Piggybacking or Protocol Reuse ..13
      <a href="#section-4.2">4.2</a>. Properties of Alternative Registration Exchange Types .....<a href="#page-14">14</a>



<span class="grey">Baugher, et al.              Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


      4.3. Infrastructure for Alternative Registration
           Exchange Types ............................................<a href="#page-15">15</a>
      <a href="#section-4.4">4.4</a>. De-registration Exchange ..................................<a href="#page-16">16</a>
   <a href="#section-5">5</a>. Rekey Protocol .................................................<a href="#page-16">16</a>
      <a href="#section-5.1">5.1</a>. Goals of the Rekey Protocol ...............................<a href="#page-17">17</a>
      <a href="#section-5.2">5.2</a>. Rekey Message Transport and Protection ....................<a href="#page-17">17</a>
      <a href="#section-5.3">5.3</a>. Reliable Transport of Rekey Messages ......................<a href="#page-18">18</a>
      <a href="#section-5.4">5.4</a>. State-of-the-art on Reliable Multicast Infrastructure .....<a href="#page-20">20</a>
      <a href="#section-5.5">5.5</a>. Implosion .................................................<a href="#page-21">21</a>
      <a href="#section-5.6">5.6</a>. Incorporating Group Key Management Algorithms .............<a href="#page-22">22</a>
      5.7. Stateless, Stateful, and Self-healing Rekeying
           Algorithms ................................................<a href="#page-22">22</a>
      <a href="#section-5.8">5.8</a>. Interoperability of a GKMA ................................<a href="#page-23">23</a>
   <a href="#section-6">6</a>. Group Security Association .....................................<a href="#page-24">24</a>
      <a href="#section-6.1">6.1</a>. Group Policy ..............................................<a href="#page-24">24</a>
      <a href="#section-6.2">6.2</a>. Contents of the Rekey SA ..................................<a href="#page-25">25</a>
           <a href="#section-6.2.1">6.2.1</a>. Rekey SA Policy ....................................<a href="#page-26">26</a>
           <a href="#section-6.2.2">6.2.2</a>. Group Identity .....................................<a href="#page-27">27</a>
           <a href="#section-6.2.3">6.2.3</a>. KEKs ...............................................<a href="#page-27">27</a>
           <a href="#section-6.2.4">6.2.4</a>. Authentication Key .................................<a href="#page-27">27</a>
           <a href="#section-6.2.5">6.2.5</a>. Replay Protection ..................................<a href="#page-27">27</a>
           <a href="#section-6.2.6">6.2.6</a>. Security Parameter Index (SPI) .....................<a href="#page-27">27</a>
      <a href="#section-6.3">6.3</a>. Contents of the Data SA ...................................<a href="#page-27">27</a>
           <a href="#section-6.3.1">6.3.1</a>. Group Identity .....................................<a href="#page-28">28</a>
           <a href="#section-6.3.2">6.3.2</a>. Source Identity ....................................<a href="#page-28">28</a>
           <a href="#section-6.3.3">6.3.3</a>. Traffic Protection Keys ............................<a href="#page-28">28</a>
           <a href="#section-6.3.4">6.3.4</a>. Data Authentication Keys ...........................<a href="#page-28">28</a>
           <a href="#section-6.3.5">6.3.5</a>. Sequence Numbers ...................................<a href="#page-28">28</a>
           <a href="#section-6.3.6">6.3.6</a>. Security Parameter Index (SPI) .....................<a href="#page-28">28</a>
           <a href="#section-6.3.7">6.3.7</a>. Data SA Policy .....................................<a href="#page-28">28</a>
   <a href="#section-7">7</a>. Scalability Considerations .....................................<a href="#page-29">29</a>
   <a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-31">31</a>
   <a href="#section-9">9</a>. Acknowledgments ................................................<a href="#page-32">32</a>
   <a href="#section-10">10</a>. Informative References ........................................<a href="#page-33">33</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction: Purpose of this Document</span>

   This document defines a common architecture for Multicast Security
   (MSEC) key management protocols to support a variety of application-,
   transport-, and network-layer security protocols.  It also defines
   the group security association (GSA) and describes the key management
   protocols that help establish a GSA.  The framework and guidelines
   described in this document permit a modular and flexible design of
   group key management protocols for a variety of different settings
   that are specialized to applications needs.  MSEC key management
   protocols may be used to facilitate secure one-to-many, many-to-many,
   or one-to-one communication.




<span class="grey">Baugher, et al.              Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   Group and multicast applications in IP networks have diverse security
   requirements [<a href="#ref-TAXONOMY" title="&quot;Multicast Security: A Taxonomy and some Efficient Constructions&quot;">TAXONOMY</a>].  Their key management requirements, briefly
   reviewed in <a href="#section-2.0">Section 2.0</a>, include support for internetwork-,
   transport- and application-layer security protocols.  Some
   applications achieve simpler operation by running key management
   messaging over a pre-established secure channel (e.g., TLS or IPsec).
   Other security protocols benefit from a key management protocol that
   can run over an already-deployed session initiation or management
   protocol (e.g., SIP or RTSP).  Finally, some benefit from a
   lightweight key management protocol that requires few round trips.
   For all these reasons, application-, transport-, and IP-layer data
   security protocols (e.g., SRTP [<a href="./rfc3711" title="&quot;The Secure Real-time Transport Protocol (SRTP)&quot;">RFC3711</a>] and IPsec [<a href="./rfc2401" title="&quot;Security Architecture for the Internet Protocol&quot;">RFC2401</a>]) benefit
   from different group key management systems.  This document defines a
   common architecture and design for all group key management (GKM)
   protocols.

   This common architecture for group key management is called the MSEC
   group key management architecture.  It is based on the group control
   or key server model developed in GKMP [<a href="./rfc2094" title="&quot;Group Key Management Protocol (GKMP) Architecture&quot;">RFC2094</a>] and assumed by group
   key management algorithms such as LKH [<a href="./rfc2627" title="&quot;Key Management for Multicast: Issues and Architectures&quot;">RFC2627</a>], OFT [<a href="#ref-OFT" title="&quot;Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization&quot;">OFT</a>], and MARKS
   [<a href="#ref-MARKS" title="&quot;MARKS: Zero Side Effect Multicast Key Management Using Arbitrarily Revealed Key Sequences&quot;">MARKS</a>].  There are other approaches that are not considered in this
   architecture, such as the highly distributed Cliques group key
   management protocol [<a href="#ref-CLIQUES" title="&quot;CLIQUES: A New Approach to Group Key Agreement&quot;">CLIQUES</a>] or broadcast key management schemes
   [<a href="#ref-FN93" title="&quot;Broadcast Encryption, Advances in Cryptology&quot;">FN93</a>,<a href="#ref-Wool" title="&quot;Key Management for Encrypted broadcast&quot;">Wool</a>].  MSEC key management may in fact be complementary to
   other group key management designs, but the integration of MSEC group
   key management with Cliques, broadcast key management, or other group
   key systems is not considered in this document.

   Key management protocols are difficult to design and validate.  The
   common architecture described in this document eases this burden by
   defining common abstractions and an overall design that can be
   specialized for different uses.

   This document builds on and extends the Group Key Management Building
   Block document of the IRTF SMuG research group [<a href="#ref-GKMBB" title="&quot;GKM Building Block: Group Security Association (GSA) Definition,&quot;">GKMBB</a>] and is part of
   the MSEC document roadmap.  The MSEC architecture [<a href="#ref-MSEC-Arch" title="&quot;The Multicast Group Security Architecture&quot;">MSEC-Arch</a>] defines
   a complete multicast or group security architecture, of which key
   management is a component.

   The rest of this document is organized as follows.  <a href="#section-2">Section 2</a>
   discusses the security, performance and architectural requirements
   for a group key management protocol.  <a href="#section-3">Section 3</a> presents the overall
   architectural design principles.  <a href="#section-4">Section 4</a> describes the
   registration protocol in detail, and <a href="#section-5">Section 5</a> does the same for
   rekey protocol.  <a href="#section-6">Section 6</a> considers the interface to the Group
   Security Association (GSA).  <a href="#section-7">Section 7</a> reviews the scalability issues
   for group key management protocols and <a href="#section-8">Section 8</a> discusses security
   considerations.



<span class="grey">Baugher, et al.              Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Requirements of a Group Key Management Protocol</span>

   A group key management (GKM) protocol supports protected
   communication between members of a secure group.  A secure group is a
   collection of principals, called members, who may be senders,
   receivers, or both receivers and senders to other members of the
   group.  Group membership may vary over time.  A group key management
   protocol helps to ensure that only members of a secure group can gain
   access to group data (by gaining access to group keys) and can
   authenticate group data.  The goal of a group key management protocol
   is to provide legitimate group members with the up-to-date
   cryptographic state they need for secrecy and authentication.

   Multicast applications, such as video broadcast and multicast file
   transfer, typically have the following key management requirements
   (see also [<a href="#ref-TAXONOMY" title="&quot;Multicast Security: A Taxonomy and some Efficient Constructions&quot;">TAXONOMY</a>]).  Note that the list is neither applicable to
   all applications nor exhaustive.

   1. Group members receive security associations that include
      encryption keys, authentication/integrity keys, cryptographic
      policy that describes the keys, and attributes such as an index
      for referencing the security association (SA) or particular
      objects contained in the SA.

   2. In addition to the policy associated with group keys, the group
      owner or the Group Controller and Key Server (GCKS) may define and
      enforce group membership, key management, data security, and other
      policies that may or may not be communicated to the entire
      membership.

   3. Keys will have a pre-determined lifetime and may be periodically
      refreshed.

   4. Key material should be delivered securely to members of the group
      so that they are secret, integrity-protected and verifiably
      obtained from an authorized source.

   5. The key management protocol should be secure against replay
      attacks and Denial of Service(DoS) attacks (see the Security
      Considerations section of this memo).

   6. The protocol should facilitate addition and removal of group
      members.  Members who are added may optionally be denied access to
      the key material used before they joined the group, and removed
      members should lose access to the key material following their
      departure.





<span class="grey">Baugher, et al.              Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   7. The protocol should support a scalable group rekey operation
      without unicast exchanges between members and a Group Controller
      and Key Server (GCKS), to avoid overwhelming a GCKS managing a
      large group.

   8. The protocol should be compatible with the infrastructure and
      performance needs of the data security application, such as the
      IPsec security protocols AH and ESP, and/or application layer
      security protocols such as SRTP [<a href="./rfc3711" title="&quot;The Secure Real-time Transport Protocol (SRTP)&quot;">RFC3711</a>].

   9. The key management protocol should offer a framework for replacing
      or renewing transforms, authorization infrastructure, and
      authentication systems.

   10. The key management protocol should be secure against collusion
       among excluded members and non-members.  Specifically, collusion
       must not result in attackers gaining any additional group secrets
       than each of them individually are privy to.  In other words,
       combining the knowledge of the colluding entities must not result
       in revealing additional group secrets.

   11. The key management protocol should provide a mechanism to
       securely recover from a compromise of some or all of the key
       material.

   12. The key management protocol may need to address real-world
       deployment issues such as NAT-traversal and interfacing with
       legacy authentication mechanisms.

   In contrast to typical unicast key and SA negotiation protocols such
   as TLS and IKE, multicast group key management protocols provide SA
   and key download capability.  This feature may be useful for point-
   to-point as well as multicast communication, so that a group key
   management protocol may be useful for unicast applications.  Group
   key management protocols may be used for protecting multicast or
   unicast communications between members of a secure group.  Secure
   sub-group communication is also plausible using the group SA.

   There are other requirements for small group operation with many all
   members as potential senders.  In this case, the group setup time may
   need to be optimized to support a small, highly interactive group
   environment [<a href="./rfc2627" title="&quot;Key Management for Multicast: Issues and Architectures&quot;">RFC2627</a>].

   The current key management architecture covers secure communication
   in large single-sender groups, such as source-specific multicast
   groups.  Scalable operation to a range of group sizes is also a
   desirable feature, and a better group key management protocol will
   support large, single-sender groups as well as groups that have many



<span class="grey">Baugher, et al.              Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   senders.  It may be that no single key management protocol can
   satisfy the scalability requirements of all group-security
   applications.

   It is useful to emphasize two non-requirements: technical protection
   measures (TPM) [<a href="#ref-TPM" title="">TPM</a>] and broadcast key management.  TPM are used for
   such things as copy protection by preventing the device user from
   getting easy access to the group keys.  There is no reason why a
   group key management protocol cannot be used in an environment where
   the keys are kept in a tamper-resistant store, using various types of
   hardware or software to implement TPM.  For simplicity, however, the
   MSEC key management architecture described in this document does not
   consider design for technical protection.

   The second non-requirement is broadcast key management when there is
   no back channel [<a href="#ref-FN93" title="&quot;Broadcast Encryption, Advances in Cryptology&quot;">FN93</a>,<a href="#ref-JKKV94" title="&quot;On Key Distribution via True Broadcasting&quot;">JKKV94</a>] or for a non-networked device such as a
   digital videodisc player.  We assume IP network operation with two-
   way communication, however asymmetric, and authenticated key-exchange
   procedures that can be used for member registration.  Broadcast
   applications may use a one-way Internet group key management protocol
   message and a one-way rekey message, as described below.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Overall Design of Group Key Management Architecture</span>

   The overall group key management architecture is based upon a group
   controller model [RFC2093,<a href="./rfc2094">RFC2094</a>,RFC2627,OFT,GSAKMP,<a href="./rfc3547">RFC3547</a>] with a
   single group owner as the root-of-trust.  The group owner designates
   a group controller for member registration and GSA rekeying.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Overview</span>

   The main goal of a group key management protocol is to securely
   provide group members with an up-to-date security association (SA),
   which contains the needed information for securing group
   communication (i.e., the group data).  We call this SA the Data SA.
   In order to obtain this goal, the group key management architecture
   defines the following protocols.

   (1) Registration Protocol

      This is a unicast protocol between the Group Controller and Key
      Server (GCKS) and a joining group member.  In this protocol, the
      GCKS and joining member mutually authenticate each other.  If the
      authentication succeeds and the GCKS finds that the joining member
      is authorized, then the GCKS supplies the joining member with the
      following information:





<span class="grey">Baugher, et al.              Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


      (a) Sufficient information to initialize the Data SA within the
          joining member.  This information is given only if the group
          security policy calls for initializing the Data SA at
          registration, instead of, or in addition to, as part of the
          rekey protocol.

      (b) Sufficient information to initialize a Rekey SA within the
          joining member (see more details about this SA below).  This
          information is given if the group security policy calls for a
          rekey protocol.

      The registration protocol must ensure that the transfer of
      information from GCKS to member is done in an authenticated and
      confidential manner over a security association.  We call this SA
      the Registration SA.  A complementary de-registration protocol
      serves to explicitly remove Registration SA state.  Members may
      choose to delete Registration SA state.

   (2) Rekey Protocol

      A GCKS may periodically update or change the Data SA, by sending
      rekey information to the group members.  Rekey messages may result
      from group membership changes, from changes in group security
      policy, from the creation of new traffic-protection keys (TPKs,
      see next section) for the particular group, or from key
      expiration.  Rekey messages are protected by the Rekey SA, which
      is initialized in the registration protocol.  They contain
      information for updating the Rekey SA and/or the Data SA and can
      be sent via multicast to group members or via unicast from the
      GCKS to a particular group member.

      Note that there are other means for managing (e.g., expiring or
      refreshing) the Data SA without interaction between the GCKS and
      the members.  For example in MARKS [<a href="#ref-MARKS" title="&quot;MARKS: Zero Side Effect Multicast Key Management Using Arbitrarily Revealed Key Sequences&quot;">MARKS</a>], the GCKS pre-
      determines TPKs for different periods in the lifetime of the
      secure group and distributes keys to members based on their
      membership periods.  Alternative schemes such as the GCKS
      disbanding the secure group and starting a new group with a new
      Data SA are also possible, although this is typically limited to
      small groups.

      Rekey messages are authenticated using one of the two following
      options:

      (1) Using source authentication [<a href="#ref-TAXONOMY" title="&quot;Multicast Security: A Taxonomy and some Efficient Constructions&quot;">TAXONOMY</a>], that is, enabling each
          group member to verify that a rekey message originates with
          the GCKS and none other.




<span class="grey">Baugher, et al.              Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


      (2) Using only group-based authentication with a symmetric key.
          Members can only be assured that the rekey messages originated
          within the group.  Therefore, this is applicable only when all
          members of the group are trusted not to impersonate the GCKS.
          Group authentication for rekey messages is typically used when
          public-key cryptography is not suitable for the particular
          group.

      The rekey protocol ensures that all members receive the rekey
      information in a timely manner.  In addition, the rekey protocol
      specifies mechanisms for the parties to contact the GCKS and re-
      synch if their keys expired and an updated key has not been
      received.  The rekey protocol for large-scale groups offers
      mechanisms to avoid implosion problems and to ensure reliability
      in its delivery of keying material.

      Although the Rekey SA is established by the registration protocol,
      it is updated using a rekey protocol.  When a member leaves the
      group, it destroys its local copy of the GSA.  Using a de-
      registration message may be an efficient way for a member to
      inform the GCKS that it has destroyed, or is about to destroy, the
      SAs.  Such a message may prompt the GCKS to cryptographically
      remove the member from the group (i.e., to prevent the member from
      having access to future group communication).  In large-scale
      multicast applications, however, de-registration can potentially
      cause implosion at the GCKS.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Detailed Description of the GKM Architecture</span>

   Figure 1 depicts the overall design of a GKM protocol.  Each group
   member, sender or receiver, uses the registration protocol to get
   authorized and authenticated access to a particular Group, its
   policies, and its keys.  The two types of group keys are the key
   encryption keys (KEKs) and the traffic encryption keys (TEKs).  For
   group authentication of rekey messages or data, key integrity or
   traffic integrity keys may be used, as well.  We use the term
   protection keys to refer to both integrity and encryption keys.  For
   example, the term traffic protection key (TPK) is used to denote the
   combination of a TEK and a traffic integrity key, or the key material
   used to generate them.

   The KEK may be a single key that protects the rekey message,
   typically containing a new Rekey SA (containing a KEK) and/or Data SA
   (containing a TPK/TEK).  A Rekey SA may also contain a vector of keys
   that are part of a group key membership algorithm
   [<a href="./rfc2627" title="&quot;Key Management for Multicast: Issues and Architectures&quot;">RFC2627</a>,<a href="#ref-OFT" title="&quot;Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization&quot;">OFT</a>,<a href="#ref-TAXONOMY" title="&quot;Multicast Security: A Taxonomy and some Efficient Constructions&quot;">TAXONOMY</a>,<a href="#ref-SD1" title="&quot;Revocation and Tracing Schemes for Stateless Receiver&quot;">SD1</a>,<a href="#ref-SD2" title="&quot;Efficient Trace and Revoke Schemes&quot;">SD2</a>].  The data security protocol uses TPKs
   to protect streams, files, or other data sent and received by




<span class="grey">Baugher, et al.              Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   the data security protocol.  Thus the registration protocol and/or
   the rekey protocol establish the KEK(s) and/or the TPKs.

   +------------------------------------------------------------------+
   | +-----------------+                          +-----------------+ |
   | |     POLICY      |                          |  AUTHORIZATION  | |
   | | INFRASTRUCTURE  |                          | INFRASTRUCTURE  | |
   | +-----------------+                          +-----------------+ |
   |         ^                                            ^           |
   |         |                                            |           |
   |         v                                            v           |
   | +--------------------------------------------------------------+ |
   | |                                                              | |
   | |                    +--------------------+                    | |
   | |            +------&gt;|        GCKS        |&lt;------+            | |
   | |            |       +--------------------+       |            | |
   | |     REGISTRATION or          |            REGISTRATION or    | |
   | |     DE-REGISTRATION          |            DE-REGISTRATION    | |
   | |         PROTOCOL             |               PROTOCOL        | |
   | |            |                 |                  |            | |
   | |            v                REKEY               v            | |
   | |   +-----------------+     PROTOCOL     +-----------------+   | |
   | |   |                 |    (OPTIONAL)    |                 |   | |
   | |   |    SENDER(S)    |&lt;-------+--------&gt;|   RECEIVER(S)   |   | |
   | |   |                 |                  |                 |   | |
   | |   +-----------------+                  +-----------------+   | |
   | |            |                                    ^            | |
   | |            v                                    |            | |
   | |            +-------DATA SECURITY PROTOCOL-------+            | |
   | |                                                              | |
   | +--------------------------------------------------------------+ |
   |                                                                  |
   +------------------------------------------------------------------+

                Figure 1: Group Security Association Model

   There are a few distinct outcomes to a successful registration
   Protocol exchange.

      o  If the GCKS uses rekey messages, then the admitted member
         receives the Rekey SA.  The Rekey SA contains the group's rekey
         policy (note that not all of the policy need to be revealed to
         members), and at least a group KEK.  In addition, the GCKS
         sends a group key integrity key for integrity protection of
         rekey messages.  If a group key management algorithm is used
         for efficient rekeying, the GCKS also sends one or more KEKs as
         specified by the key distribution policy of the group key
         management algorithm.



<span class="grey">Baugher, et al.              Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


      o  If rekey messages are not used for the Group, then the admitted
         member receives TPKs (as part of the Data Security SAs) that
         are passed to the member's Data Security Protocol (as IKE does
         for IPsec).

      o  The GCKS may pass one or more TPKs to the member even if rekey
         messages are used, for efficiency reasons and according to
         group policy.

   The GCKS creates the KEK and TPKs and downloads them to each member,
   as the KEK and TPKs are common to the entire group.  The GCKS is a
   separate logical entity that performs member authentication and
   authorization according to the group policy that is set by the group
   owner.  The GCKS may present a credential signed by the group owner
   to the group member, so that member can check the GCKS's
   authorization.  The GCKS, which may be co-located with a member or be
   physically separate, runs the rekey protocol to push rekey messages
   containing refreshed KEKs, new TPKs, and/or refreshed TPKs to
   members.  Note that some group key management algorithms refresh any
   of the KEKs (potentially), whereas others only refresh the group KEK.

   Alternatively, the sender may forward rekey messages on behalf of the
   GCKS when it uses a credential mechanism that supports delegation.
   Thus, it is possible for the sender, or other members, to source
   keying material (TPKs encrypted in the Group KEK) as it sources
   multicast or unicast data.  As mentioned above, the rekey message can
   be sent using unicast or multicast delivery.  Upon receipt of a TPK
   (as part of a Data SA) via a rekey message or a registration protocol
   exchange, the member's group key management functional block will
   provide the new or updated security association (SA) to the data
   security protocol.  This protects the data sent from sender to
   receiver.

   The Data SA protects the data sent on the arc labeled DATA SECURITY
   PROTOCOL shown in Figure 1.  A second SA, the Rekey SA, is optionally
   established by the key management protocol for rekey messages as
   shown in Figure 1 by the arc labeled REKEY PROTOCOL.  The rekey
   message is optional because all keys, KEKs and TPKs, can be delivered
   by the registration protocol exchanges shown in Figure 1, and those
   keys may not need to be updated.  The registration protocol is
   protected by a third, unicast, SA between the GCKS and each member.
   This is called the Registration SA.  There may be no need for the
   Registration SA to remain in place after the completion of the
   registration protocol exchanges.  The de-registration protocol may be
   used when explicit teardown of the SA is desirable (such as when a
   phone call or conference terminates).  The three SAs compose the GSA.
   The only optional SA is the Rekey SA.




<span class="grey">Baugher, et al.              Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   Figure 1 shows two blocks that are external to the group key
   management protocol:  The policy and authorization infrastructures
   are discussed in <a href="#section-6.1">Section 6.1</a>.  The Multicast Security Architecture
   document further clarifies the SAs and their use as part of the
   complete architecture of a multicast security solution [<a href="#ref-MSEC-Arch" title="&quot;The Multicast Group Security Architecture&quot;">MSEC-Arch</a>].

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Properties of the Design</span>

   The design of <a href="#section-3.2">Section 3.2</a> achieves scalable operation by (1) allowing
   the de-coupling of authenticated key exchange in a registration
   protocol from a rekey protocol, (2) allowing the rekey protocol to
   use unicast push or multicast distribution of group and data keys as
   an option, (3) allowing all keys to be obtained by the unicast
   registration protocol, and (4) delegating the functionality of the
   GCKS among multiple entities, i.e., to permit distributed operation
   of the GCKS.

   High-capacity operation is obtained by (1) amortizing
   computationally-expensive asymmetric cryptography over multiple data
   keys used by data security protocols, (2) supporting multicast
   distribution of symmetric group and data keys, and (3) supporting key
   revocation algorithms such as LKH [<a href="./rfc2627" title="&quot;Key Management for Multicast: Issues and Architectures&quot;">RFC2627</a>,<a href="#ref-OFT" title="&quot;Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization&quot;">OFT</a>,<a href="#ref-SD1" title="&quot;Revocation and Tracing Schemes for Stateless Receiver&quot;">SD1</a>,<a href="#ref-SD2" title="&quot;Efficient Trace and Revoke Schemes&quot;">SD2</a>] that allow
   members to be added or removed at logarithmic rather than linear
   space/time complexity.  The registration protocol may use asymmetric
   cryptography to authenticate joining members and optionally establish
   the group KEK.  Asymmetric cryptography such as Diffie-Hellman key
   agreement and/or digital signatures are amortized over the life of
   the group KEK.  A Data SA can be established without the use of
   asymmetric cryptography; the TPKs are simply encrypted in the
   symmetric KEK and sent unicast or multicast in the rekey protocol.

   The design of the registration and rekey protocols is flexible.  The
   registration protocol establishes a Rekey SA or one or more Data SAs
   or both types of SAs.  At least one of the SAs is present (otherwise,
   there is no purpose to the Registration SA).  The Rekey SA may update
   the Rekey SA, or establish or update one or more Data SAs.
   Individual protocols or configurations may use this flexibility to
   obtain efficient operation.

<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Group Key Management Block Diagram</span>

   In the block diagram of Figure 2, group key management protocols run
   between a GCKS and member principal to establish a Group Security
   Association (GSA).  The GSA consists of a Data SA, an optional Rekey
   SA, and a Registration SA.  The GCKS may use a delegated principal,
   such as the sender, which has a delegation credential signed by the
   GCKS.  The Member of Figure 2 may be a sender or receiver of
   multicast or unicast data.  There are two functional blocks in Figure



<span class="grey">Baugher, et al.              Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   2 labeled GKM, and there are two arcs between them depicting the
   group key-management registration (reg) and rekey (rek) protocols.
   The message exchanges are in the GSA establishment protocols, which
   are the registration protocol and the rekey protocol described above.

   Figure 2 shows that a complete group-key management functional
   specification includes much more than the message exchange.  Some of
   these functional blocks and the arcs between them are peculiar to an
   operating system (OS) or vendor product, such as vendor
   specifications for products that support updates to the IPsec

   Security Association Database (SAD) and Security Policy Database
   (SPD) [<a href="./rfc2367" title="&quot;PF_KEY Key Management API, Version 2&quot;">RFC2367</a>].  Various vendors also define the functions and
   interface of credential stores, CRED in Figure 2.

     +----------------------------------------------------------+
     |                                                          |
     | +-------------+         +------------+                   |
     | |   CONTROL   |         |   CONTROL  |                   |
     | +------^------+         +------|-----+  +--------+       |
     |        |                       |  +-----| CRED   |       |
     |        |                       |  |     +--------+       |
     |   +----v----+             +----v--v-+   +--------+       |
     |   |         &lt;-----Reg-----&gt;         |&lt;-&gt;|  SAD   |       |
     |   |   GKM    -----Rek-----&gt;   GKM   |   +--------+       |
     |   |         |             |         |   +--------+       |
     |   |         ------+       |         |&lt;-&gt;|  SPD   |       |
     |   +---------+     |       +-^-------+   +--------+       |
     |   +--------+      |         | |   |                      |
     |   | CRED   |-----&gt;+         | |   +-------------------+  |
     |   +--------+      |         | +--------------------+  |  |
     |   +--------+      |       +-V-------+   +--------+ |  |  |
     |   |  SAD   &lt;-----&gt;+       |         |&lt;-&gt;|  SAD   &lt;-+  |  |
     |   +--------+      |       |SECURITY |   +--------+    |  |
     |   +--------+      |       |PROTOCOL |   +--------+    |  |
     |   |  SPD   &lt;-----&gt;+       |         |&lt;-&gt;|  SPD   &lt;----+  |
     |   +--------+              +---------+   +--------+       |
     |                                                          |
     |     (A) GCKS                     (B) MEMBER              |
     +----------------------------------------------------------+

               Figure 2: Group Key Management Block in a Host

   The CONTROL function directs the GCKS to establish a group, admit a
   member, or remove a member, or it directs a member to join or leave a
   group.  CONTROL includes authorization that is subject to group
   policy [<a href="#ref-GSPT" title="&quot;The MSEC Group Security Policy Token&quot;">GSPT</a>] but its implementation is specific to the GCKS.  For
   large scale multicast sessions, CONTROL could perform session



<span class="grey">Baugher, et al.              Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   announcement functions to inform a potential group member that it may
   join a group or receive group data (e.g., a stream of file transfer
   protected by a data security protocol).  Announcements notify group
   members to establish multicast SAs in advance of secure multicast
   data transmission.  Session Description Protocol (SDP) is one form
   that the announcements might take [<a href="./rfc2327" title="&quot;SDP: Session Description Protocol&quot;">RFC2327</a>].  The announcement
   function may be implemented in a session directory tool, an
   electronic program guide (EPG), or by other means.  The Data Security
   or the announcement function directs group key management using an
   application programming interface (API), which is peculiar to the
   host OS in its specifics.  A generic API for group key management is
   for further study, but this function is necessary to allow Group
   (KEK) and Data (TPKs) key establishment to be scalable to the
   particular application.  A GCKS application program will use the API
   to initiate the procedures for establishing SAs on behalf of a
   Security Protocol in which members join secure groups and receive
   keys for streams, files, or other data.

   The goal of the exchanges is to establish a GSA through updates to
   the SAD of a key management implementation and particular Security
   Protocol.  The Data Security Protocol ("SECURITY PROTOCOL") of Figure
   2 may span internetwork and application layers or operate at the
   internetwork layer, such as AH and ESP.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Registration Protocol</span>

   The design of the registration protocol is flexible and can support
   different application scenarios.  The chosen registration protocol
   solution reflects the specific requirements of specific scenarios.
   In principle, it is possible to base a registration protocol on any
   secure-channel protocol, such as IPsec and TLS, which is the case in
   tunneled GSAKMP [<a href="#ref-tGSAKMP" title="&quot;Tunneled Group Secure Association Key Management Protocol&quot;">tGSAKMP</a>].  GDOI [<a href="./rfc3547" title="&quot;The Group Domain of Interpretation&quot;">RFC3547</a>] reuses IKE Phase 1 as the
   secure channel to download Rekey and/or Data SAs.  Other protocols,
   such as MIKEY and GSAKMP, use authenticated Diffie-Hellman exchanges
   similar to IKE Phase 1, but they are specifically tailored for key
   download to achieve efficient operation.  We discuss the design of a
   registration protocol in detail in the rest of this section.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Registration Protocol via Piggybacking or Protocol Reuse</span>

   Some registration protocols need to tunnel through a data-signaling
   protocol to take advantage of already existing security
   functionality, and/or to optimize the total session setup time.  For
   example, a telephone call has strict bounds for delay in setup time.
   It is not feasible to run security exchanges in parallel with call
   setup, since the latter often resolves the address.  Call setup must
   complete before the caller knows the callee's address.  In this case,
   it may be advantageous to tunnel the key exchange procedures inside



<span class="grey">Baugher, et al.              Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   call establishment [<a href="#ref-H.235" title="&quot;Security and Encryption for H-Series (H.323 and other H.245-based) Multimedia Terminals&quot;">H.235</a>,<a href="#ref-MIKEY" title="&quot;MIKEY: Multimedia Internet KEYing&quot;">MIKEY</a>], so that both can complete (or fail,
   see below) at the same time.

   The registration protocol has different requirements depending on the
   particular integration/tunneling approach.  These requirements are
   not necessarily security requirements, but will have an impact on the
   chosen security solution.  For example, the security association will
   certainly fail if the call setup fails in the case of IP telephony.

   Conversely, the registration protocol imposes requirements on the
   protocol that tunnels it.  In the case of IP telephony, the call
   setup usually will fail when the security association is not
   successfully established.  In the case of video-on-demand, protocols
   such as RTSP that convey key management data will fail when a needed
   security association cannot be established.

   Both GDOI and MIKEY use this approach, but in different ways.  MIKEY
   can be tunneled in SIP and RTSP.  It takes advantage of the session
   information contained in these protocols and the possibility to
   optimize the setup time for the registration procedure.  SIP requires
   that a tunneled protocol must use at most one roundtrip (i.e., two
   messages).  This is also a desirable requirement from RTSP.

   The GDOI approach takes advantage of the already defined ISAKMP phase
   1 exchange [<a href="./rfc2409" title="&quot;The Internet Key Exchange (IKE)&quot;">RFC2409</a>], and extends the phase 2 exchange for the
   registration.  The advantage here is the reuse of a successfully
   deployed protocol and the code base, where the defined phase 2
   exchange is protected by the SA created by phase 1.  GDOI also
   inherits other functionality of the ISAKMP, and thus it is readily
   suitable for running IPsec protocols over IP multicast services.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Properties of Alternative Registration Exchange Types</span>

   The required design properties of a registration protocol have
   different trade-offs.  A protocol that provides perfect forward
   secrecy and identity protection trades performance or efficiency for
   better security, while a protocol that completes in one or two
   messages may trade security functionality (e.g., identity protection)
   for efficiency.

   Replay protection generally uses either a timestamp or a sequence
   number.  The first requires synchronized clocks, while the latter
   requires retention of state.  In a timestamp-based protocol, a replay
   cache is needed to store the authenticated messages (or the hashes of
   the messages) received within the allowable clock skew.  The size of
   the replay cache depends on the number of authenticated messages
   received during the allowable clock skew.  During a DoS attack, the
   replay cache might become overloaded.  One solution is to over-



<span class="grey">Baugher, et al.              Informational                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   provision the replay cache, but this may lead to a large replay
   cache.  Another solution is to let the allowable clock skew be
   changed dynamically during runtime.  During a suspected DoS attack,
   the allowable clock skew is decreased so that the replay cache
   becomes manageable.

   A challenge-response mechanism (using Nonces) obviates the need for
   synchronized clocks for replay protection when the exchange uses
   three or more messages [<a href="#ref-MVV" title="&quot;Handbook of Applied Cryptography&quot;">MVV</a>].

   Additional security functions become possible as the number of
   allowable messages in the registration protocol increase.  ISAKMP
   offers identity protection, for example, as part of a six-message
   exchange.  With additional security features, however, comes added
   complexity:  Identity protection, for example, not only requires
   additional messages, but may result in DoS vulnerabilities since
   authentication is performed in a late stage of the exchange after
   resources already have been devoted.

   In all cases, there are tradeoffs with the number of message
   exchanged, the desired security services, and the amount of
   infrastructure that is needed to support the group key management
   service.  Whereas protocols that use two or even one-message setup
   have low latency and computation requirements, they may require more
   infrastructure such as secure time or offer less security such as the
   absence of identity protection.  What tradeoffs are acceptable and
   what are not is very much dictated by the application and application
   environment.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Infrastructure for Alternative Registration Exchange Types</span>

   The registration protocol may need external infrastructures to handle
   authentication and authorization, replay protection, protocol-run
   integrity, and possibly other security services such as secure
   synchronized clocks.  For example, authentication and authorization
   may need a PKI deployment (with either authorization-based
   certificates or a separate management) or may be handled using AAA
   infrastructure.  Replay protection using timestamps requires an
   external infrastructure or protocol for clock synchronization.

   However, external infrastructures may not always be needed; for
   example pre-shared keys are used for authentication and
   authorization.  This may be the case if the subscription base is
   relatively small.  In a conversational multimedia scenario (e.g., a
   VoIP call between two or more people), it may be the end user who
   handles the authorization by manually accepting/rejecting the
   incoming calls.  In that case, infrastructure support may not be
   required.



<span class="grey">Baugher, et al.              Informational                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  De-registration Exchange</span>

   The session-establishment protocol (e.g., SIP, RTSP) that conveys a
   registration exchange often has a session-disestablishment protocol
   such as RTSP TEARDOWN [<a href="./rfc2326" title="&quot;Real Time Streaming Protocol (RTSP)&quot;">RFC2326</a>] or SIP BYE [<a href="./rfc3261" title="&quot;SIP: Session Initiation Protocol&quot;">RFC3261</a>].  The session-
   disestablishment exchange between endpoints offers an opportunity to
   signal the end of the GSA state at the endpoints.  This exchange need
   only be a unidirectional notification by one side that the GSA is to
   be destroyed.  For authentication of this notification, we may use a
   proof-of-possession of the group key(s) by one side to the other.
   Some applications benefit from acknowledgement in a mutual, two-
   message exchange signaling disestablishment of the GSA concomitant
   with disestablishment of the session, e.g., RTSP or SIP session.  In
   this case, a two-way proof-of-possession might serve for mutual
   acknowledgement of the GSA disestablishment.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Rekey Protocol</span>

   The group rekey protocol is for transport of keys and SAs between a
   GCKS and the members of a secure communications group.  The GCKS
   sends rekey messages to update a Rekey SA, or initialize/update a
   Data SA or both.  Rekey messages are protected by a Rekey SA.  The
   GCKS may update the Rekey SA when group membership changes or when
   KEKs or TPKs expire.  Recall that KEKs correspond to a Rekey SA and
   TPKs correspond to a Data SA.

   The following are some desirable properties of the rekey protocol.

      o  The rekey protocol ensures that all members receive the rekey
         information in a timely manner.

      o  The rekey protocol specifies mechanisms allowing the parties to
         contact the GCKS and re-sync when their keys expire and no
         updates have been received.

      o  The rekey protocol avoids implosion problems and ensures
         reliability in delivering Rekey information.

   We further note that the rekey protocol is primarily responsible for
   scalability of the group key management architecture.  Hence, it is
   imperative that we provide the above listed properties in a scalable
   manner.  Note that solutions exist in the literature (both IETF
   standards and research articles) for parts of the problem.  For
   instance, the rekey protocol may use a scalable group key management
   algorithm (GKMA) to reduce the number of keys sent in a rekey
   message.  Examples of a GKMA include LKH, OFT, Subset difference
   based schemes etc.




<span class="grey">Baugher, et al.              Informational                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Goals of the Rekey Protocol</span>

   The goals of the rekey protocol are:

      o  to synchronize a GSA,

      o  to provide privacy and (symmetric or asymmetric)
         authentication, replay protection and DoS protection,

      o  efficient rekeying after changes in group membership or when
         keys (KEKs) expire,

      o  reliable delivery of rekey messages,

      o  member recovery from an out-of-sync GSA,

      o  high throughput and low latency, and

      o  support IP Multicast or multi-unicast.

   We identify several major issues in the design of a rekey protocol:

      1.  rekey message format,

      2.  reliable transport of rekey messages,

      3.  implosion,

      4.  recovery from out-of-sync GSA,

      5.  incorporating GKMAs in rekey messages, and

      6.  interoperability of GKMAs.

   Note that interoperation of rekey protocol implementations is
   insufficient for a GCKS to successfully rekey a group.  The GKMA must
   also interoperate, i.e., standard versions of the group key
   management algorithms such as LKH, OFT, or Subset Difference must be
   used.

   The rest of this section discusses these topics in detail.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Rekey Message Transport and Protection</span>

   Rekey messages contain Rekey and/or Data SAs along with KEKs and
   TPKs.  These messages need to be confidential, authenticated, and
   protected against replay and DoS attacks.  They are sent via
   multicast or multi-unicast from the GCKS to the members.



<span class="grey">Baugher, et al.              Informational                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   Rekey messages are encrypted with the Group KEK for confidentiality.
   When used in conjunction with a GKMA, portions of the rekey message
   are first encrypted with the appropriate KEKs as specified by the
   GKMA.  The GCKS authenticates rekey messages using either a MAC,
   computed using the group Authentication key, or a digital signature.
   In both cases, a sequence number is included in computation of the
   MAC or the signature to protect against replay attacks.

   When group authentication is provided with a symmetric key, rekey
   messages are vulnerable to attacks by other members of the group.
   Rekey messages are digitally signed when group members do not trust
   each other.  When asymmetric authentication is used, members
   receiving rekey messages are vulnerable to DoS attacks.  An external
   adversary may send a bogus rekey message, which a member cannot
   identify until after it performs an expensive digital signature
   operation.  To protect against such an attack, a MAC may be sent as
   part of the rekey message.  Members verify the signature only upon
   successful verification of the MAC.

   Rekey messages contain group key updates corresponding to a single
   [<a href="./rfc2627" title="&quot;Key Management for Multicast: Issues and Architectures&quot;">RFC2627</a>,<a href="#ref-OFT" title="&quot;Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization&quot;">OFT</a>] or multiple membership changes [<a href="#ref-SD1" title="&quot;Revocation and Tracing Schemes for Stateless Receiver&quot;">SD1</a>,<a href="#ref-SD2" title="&quot;Efficient Trace and Revoke Schemes&quot;">SD2</a>,<a href="#ref-BatchRekey" title="&quot;Reliable Group Rekeying: Design and Performance Analysis&quot;">BatchRekey</a>] and
   may contain group key initialization messages [<a href="#ref-OFT" title="&quot;Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization&quot;">OFT</a>].

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Reliable Transport of Rekey Messages</span>

   The GCKS must ensure that all members have the current Data Security
   and Rekey SAs.  Otherwise, authorized members may be inadvertently
   excluded from receiving group communications.  Thus, the GCKS needs
   to use a rekey algorithm that is inherently reliable or employ a
   reliable transport mechanism to send rekey messages.

   There are two dimensions to the problem.  Messages that update group
   keys may be lost in transit or may be missed by a host when it is
   offline.  LKH and OFT group key management algorithms rely on past
   history of updates being received by the host.  If the host goes
   offline, it will need to resynchronize its group-key state when it
   comes online; this may require a unicast exchange with the GCKS.  The
   Subset Difference algorithm, however, conveys all the necessary state
   in its rekey messages and does not need members to be always online
   or keeping state.  The Subset Difference algorithm does not require a
   back channel and can operate on a broadcast network.  If a rekey
   message is lost in transmission, the Subset Difference algorithm
   cannot decrypt messages encrypted with the TPK sent via the lost
   rekey message.  There are self-healing GKMAs proposed in the
   literature that allow a member to recover lost rekey messages, as
   long as rekey messages before and after the lost rekey message are
   received.




<span class="grey">Baugher, et al.              Informational                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   Rekey messages are typically short (for single membership change as
   well as for small groups), which makes it easy to design a reliable
   delivery protocol.  On the other hand, the security requirements may
   add an additional dimension to address.  There are some special cases
   in which membership changes are processed as a batch, reducing the
   frequency of rekey messages but increasing their size.  Furthermore,
   among all the KEKs sent in a rekey message, as many as half the
   members need only a single KEK.  We may take advantage of these
   properties in designing a rekey message(s) and a protocol for their
   reliable delivery.

   Three categories of solutions have been proposed:

      1.  Repeatedly transmit the rekey message.  In many cases rekey
          messages translate to only one or two IP packets.

      2.  Use an existing reliable multicast protocol/infrastructure.

      3.  Use FEC for encoding rekey packets (with NACKs as feedback)
          [<a href="#ref-BatchRekey" title="&quot;Reliable Group Rekeying: Design and Performance Analysis&quot;">BatchRekey</a>].

   Note that for small messages, category 3 is essentially the same as
   category 1.

   The group member might be out of synchrony with the GCKS if it
   receives a rekey message having a sequence number that is more than
   one greater than the last sequence number processed.  This is one
   means by which the GCKS member detects that it has missed a rekey
   message.  Alternatively, the data-security application, upon
   detecting that it is using an out-of-date key, may notify the group
   key management module.  The action taken by the GCKS member is a
   matter of group policy.  The GCKS member should log the condition and
   may contact the GCKS to rerun the re-registration protocol to obtain
   a fresh group key.  The group policy needs to take into account
   boundary conditions, such as reordered rekey messages when rekeying
   is so frequent that two messages might get reordered in an IP
   network.  The group key policy also needs to take into account the
   potential for denial of service attacks where an attacker delays or
   deletes a rekey message in order to force a subnetwork or subset of
   the members to simultaneously contact the GCKS.

   If a group member becomes out-of-synch with the GSA then it should
   re-register with the GCKS.  However, in many cases there are other,
   simpler methods for re-synching with the group:

      o  The member can open a simple unprotected connection (e.g., TCP)
         with the GCKS and obtain the current (or several recent) rekey
         messages.  Note that there is no need for authentication or



<span class="grey">Baugher, et al.              Informational                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


         encryption here, since the rekey message is already signed and
         is multicast in the clear.  One may think that this opens the
         GCKS to DoS attacks by many bogus such requests.  This,
         however, does not seem to worsen the situation; in fact,
         bombarding the GCKS with bogus resynch requests would be much
         more problematic.

      o  The GCKS can post the rekey messages on some public site (e.g.,
         a web site) and the out-of-synch member can obtain the rekey
         messages from that site.

   The GCKS may always provide all three ways of resynching (i.e., re-
   registration, simple TCP, and public posting).  This way, the member
   may choose how to resynch; it also avoids adding yet another field to
   the policy token [<a href="#ref-GSPT" title="&quot;The MSEC Group Security Policy Token&quot;">GSPT</a>].  Alternatively, a policy token may contain a
   field specifying one or more methods supported for resynchronization
   of a GSA.

<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  State-of-the-art on Reliable Multicast Infrastructure</span>

   The rekey message may be sent using reliable multicast.  There are
   several types of reliable multicast protocols with different
   properties.  However, there are no standards track reliable multicast
   protocols published at this time, although IETF consensus has been
   reached on two protocols that are intended to go into the standards
   track [NORM,<a href="./rfc3450">RFC3450</a>].  Thus, this document does not recommend a
   particular reliable multicast protocol or set of protocols for the
   purpose of reliable group rekeying.  The suitability of NAK-based,
   ACK-based or other reliable multicast methods is determined by the
   application needs and operational environment.  In the future, group
   key management protocols may choose to use particular standards-based
   approaches that meet the needs of the particular application.  A
   secure announcement facility may be needed to signal the use of a
   reliable multicast protocol, which could be specified as part of
   group policy.  The reliable multicast announcement and policy
   specification, however, can only follow the establishment of reliable
   multicast standards and are not considered further in this document.

   Today, the several MSEC group key management protocols support
   sequencing of the rekey messages through a sequence number, which is
   authenticated along with the rekey message.  A sender of rekey
   messages may re-transmit multiple copies of the message provided that
   they have the same sequence number.  Thus, re-sending the message is
   a rudimentary means of overcoming loss along the network path.  A
   member who receives the rekey message will check the sequence number
   to detect duplicate and missing rekey messages.  The member receiver
   will discard duplicate messages that it receives.  Large rekey
   messages, such as those that contain LKH or OFT tree structures,



<span class="grey">Baugher, et al.              Informational                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   might benefit from transport-layer FEC in the future, when
   standards-based methods become available.  It is unlikely that
   forward error correction (FEC) methods will benefit short rekey
   messages that fit within a single message.  In this case, FEC
   degenerates to simple retransmission of the message.

<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>.  Implosion</span>

   Implosion may occur due to one of two reasons.  First, recall that
   one of the goals of the rekey protocol is to synchronize a GSA.  When
   a rekey or Data SA expires, members may contact the GCKS for an
   update.  If all, or even many, members contact the GCKS at about the
   same time, the GCKS might not be able to handle all those messages.
   We refer to this as an out-of-sync implosion.

   The second case is in the reliable delivery of rekey messages.
   Reliable multicast protocols use feedback (NACK or ACK) to determine
   which packets must be retransmitted.  Packet losses may result in
   many members sending NACKs to the GCKS.  We refer to this as feedback
   implosion.

   The implosion problem has been studied extensively in the context of
   reliable multicasting.  The proposed feedback suppression and
   aggregation solutions might be useful in the GKM context as well.
   Members may wait a random time before sending an out-of-sync or
   feedback message.  Meanwhile, members might receive the necessary key
   updates and therefore not send a feedback message.  An alternative
   solution is to have the members contact one of several registration
   servers when they are out-of-sync.  This requires GSA synchronization
   between the multiple registration servers.

   Feedback aggregation and local recovery employed by some reliable
   multicast protocols are not easily adaptable to transport of rekey
   messages.  Aggregation raises authentication issues.  Local recovery
   is more complex because members need to establish SAs with the local
   repair server.  Any member of the group or a subordinate GCKS may
   serve as a repair server, which can be responsible for resending
   rekey messages.

   Members may use the group SA, more specifically the Rekey SA, to
   authenticate requests sent to the repair server.  However, replay
   protection requires maintaining state at members as well as repair
   servers.  Authentication of repair requests is meant to protect
   against DoS attacks.  Note also that an out-of-sync member may use an
   expired Rekey SA to authenticate repair requests, which requires
   repair servers to accept messages protected by old SAs.





<span class="grey">Baugher, et al.              Informational                     [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   Alternatively, a simple mechanism may be employed to achieve local
   repair efficiently.  Each member receives a set of local repair
   server addresses as part of group operation policy information.  When
   a member does not receive a rekey message, it can send a "Retransmit
   replay message(s) with sequence number n and higher" message to one
   of the local repair servers.  The repair server can either ignore the
   request if it is busy or retransmit the requested rekey messages as
   received from the GCKS.  The repair server, which is also another
   member may choose to serve only m requests in a given time period
   (i.e., rate limits responses) or per a given rekey message.  Rate
   limiting the requests and responses protects the repair servers as
   well as other members of the group from DoS attacks.

<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>.  Incorporating Group Key Management Algorithms</span>

   Group key management algorithms make rekeying scalable.  Large group
   rekeying without employing GKMAs is prohibitively expensive.

   Following are some considerations in selecting a GKMA:

      o  Protection against collusion.

         Members (or non-members) should not be able to collaborate to
         deduce keys for which they are not privileged (following the
         GKMA key distribution rules).

      o  Forward access control

         The GKMA should ensure that departing members cannot get access
         to future group data.

      o  Backward access control

         The GKMA should ensure that joining members cannot decrypt past
         data.

<span class="h3"><a class="selflink" id="section-5.7" href="#section-5.7">5.7</a>.  Stateless, Stateful, and Self-healing Rekeying Algorithms</span>

   We classify group key management algorithms into three categories:
   stateful, stateless, and self-healing.

   Stateful algorithms [<a href="./rfc2627" title="&quot;Key Management for Multicast: Issues and Architectures&quot;">RFC2627</a>,<a href="#ref-OFT" title="&quot;Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization&quot;">OFT</a>] use KEKs from past rekeying
   instances to encrypt (protect) KEKs corresponding to the current and
   future rekeying instances.  The main disadvantage in these schemes is
   that if a member were offline or otherwise failed to receive KEKs
   from a past rekeying instance, it may no longer be able to
   synchronize its GSA even though it can receive KEKs from all future
   rekeying instances.  The only solution is to contact the GCKS



<span class="grey">Baugher, et al.              Informational                     [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   explicitly for resynchronization.  Note that the KEKs for the first
   rekeying instance are protected by the Registration SA.  Recall that
   communication in that phase is one to one, and therefore it is easy
   to ensure reliable delivery.

   Stateless GKMAs [<a href="#ref-SD1" title="&quot;Revocation and Tracing Schemes for Stateless Receiver&quot;">SD1</a>,<a href="#ref-SD2" title="&quot;Efficient Trace and Revoke Schemes&quot;">SD2</a>] encrypt rekey messages with KEKs sent
   during the registration protocol.  Since rekey messages are
   independent of any past rekey messages (i.e., that are not protected
   by KEKs therein), a member may go offline but continue to decipher
   future communications.  However, stateless GKMAs offer no mechanisms
   to recover past rekeying messages.  Stateless rekeying may be
   relatively inefficient, particularly for immediate (not batch)
   rekeying in highly dynamic groups.

   In self-healing schemes [<a href="#ref-Self-Healing" title="&quot;Self-healing Key Distribution with Revocation&quot;">Self-Healing</a>], a member can reconstruct a
   lost rekey message as long as it receives some past and some future
   rekey messages.

<span class="h3"><a class="selflink" id="section-5.8" href="#section-5.8">5.8</a>.  Interoperability of a GKMA</span>

   Most GKMA specifications do not specify packet formats, although many
   group key management algorithms need format specification for
   interoperability.  There are several alternative ways to manage key
   trees and to number nodes within key trees.  The following
   information is needed during initialization of a Rekey SA or included
   with each GKMA packet.

      o  GKMA name (e.g., LKH, OFT, Subset Difference)

      o  GKMA version number (implementation specific).  Version may
         imply several things such as the degree of a key tree,
         proprietary enhancements, and qualify another field such as a
         key ID.

      o  Number of keys or largest ID

      o  Version-specific data

      o  Per-key information:

         -  key ID,
         -  key lifetime (creation/expiration data) ,
         -  encrypted key, and
         -  encryption key's ID (optional).







<span class="grey">Baugher, et al.              Informational                     [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   Key IDs may change in some implementations in which case one needs to
   send:

         o List of &lt;old id, new id&gt; pairs.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Group Security Association</span>

   The GKM architecture defines the interfaces between the registration,
   rekey, and data security protocols in terms of the Security
   Associations (SAs) of those protocols.  By isolating these protocols
   behind a uniform interface, the architecture allows implementations
   to use protocols best suited to their needs.  For example, a rekey
   protocol for a small group could use multiple unicast transmissions
   with symmetric authentication, while a rekey protocol for a large
   group could use IP Multicast with packet-level Forward Error
   Correction and source authentication.

   The group key management architecture provides an interface between
   the security protocols and the group SA (GSA).  The GSA consists of
   three SAs: Registration SA, Rekey SA, and Data SA.  The Rekey SA is
   optional.  There are two cases in defining the relationships between
   the three SAs.  In both cases, the Registration SA protects the
   registration protocol.

   Case 1: Group key management is done WITHOUT using a Rekey SA.  The
      registration protocol initializes and updates one or more Data SAs
      (having TPKs to protect files or streams).  Each Data SA
      corresponds to a single group, which may have more than one Data
      SA.

   Case 2: Group key management is done WITH a Rekey SA to protect the
      rekey protocol.  The registration protocol initializes the one or
      more Rekey SAs as well as zero or more Data SAs, upon successful
      completion.  When a Data SA is not initialized in the registration
      protocol, initialization is done in the rekey protocol.  The rekey
      protocol updates Rekey SA(s) AND establishes Data SA(s).

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Group Policy</span>

   Group policy is described in detail in the Group Security Policy
   Token document [<a href="#ref-GSPT" title="&quot;The MSEC Group Security Policy Token&quot;">GSPT</a>].  Group policy can be distributed through group
   announcements, key management protocols, and other out-of-band means
   (e.g., via a web page).  The group key management protocol carries
   cryptographic policies of the SAs and the keys it establishes, as
   well as additional policies for the secure operation of the group.






<span class="grey">Baugher, et al.              Informational                     [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   The acceptable cryptographic policies for the registration protocol,
   which may run over TLS [<a href="#ref-TLS" title="&quot;The TLS Protocol Version 1.0,&quot;">TLS</a>], IPsec, or IKE, are not conveyed in the
   group key management protocol since they precede any of the key
   management exchanges.  Thus, a security policy repository having some
   access protocol may need to be queried prior to establishing the
   key-management session, to determine the initial cryptographic
   policies for that establishment.  This document assumes the existence
   of such a repository and protocol for GCKS and member policy queries.
   Thus group security policy will be represented in a policy repository
   and accessible using a policy protocol.  Policy distribution may be a
   push or a pull operation.

   The group key management architecture assumes that the following
   group policy information may be externally managed, e.g., by the
   content owner, group conference administrator or group owner:

      o  the identity of the Group owner, the authentication method, and
         the delegation method for identifying a GCKS for the group;

      o  the group GCKS, authentication method, and delegation method
         for any subordinate GCKSs for the group;

      o  the group membership rules or list and authentication method.

   There are two additional policy-related requirements external to
   group key management.

      o  There is an authentication and authorization infrastructure
         such as X.509 [<a href="./rfc3280" title="&quot;Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile&quot;">RFC3280</a>], SPKI [<a href="./rfc2693" title="&quot;SPKI Certificate Theory&quot;">RFC2693</a>], or a pre-shared key
         scheme, in accordance with the group policy for a particular
         group.

      o  There is an announcement mechanism for secure groups and
         events, which operates according to group policy for a
         particular group.

   Group policy determines how the registration and rekey protocols
   initialize or update Rekey and Data SAs.  The following sections
   describe potential information sent by the GCKS for the Rekey and
   Data SAs.  A member needs the information specified in the next
   sections to establish Rekey and Data SAs.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Contents of the Rekey SA</span>

   The Rekey SA protects the rekey protocol.  It contains cryptographic
   policy, Group Identity, and Security Parameter Index (SPI) [<a href="./rfc2401" title="&quot;Security Architecture for the Internet Protocol&quot;">RFC2401</a>]
   to uniquely identify an SA, replay protection information, and key
   protection keys.



<span class="grey">Baugher, et al.              Informational                     [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>.  Rekey SA Policy</span>

      o  GROUP KEY MANAGEMENT ALGORITHM

         This represents the group key revocation algorithm that
         enforces forward and backward access control.  Examples of key
         revocation algorithms include LKH, LKH+, OFT, OFC, and Subset
         Difference [<a href="./rfc2627" title="&quot;Key Management for Multicast: Issues and Architectures&quot;">RFC2627</a>,<a href="#ref-OFT" title="&quot;Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization&quot;">OFT</a>,<a href="#ref-TAXONOMY" title="&quot;Multicast Security: A Taxonomy and some Efficient Constructions&quot;">TAXONOMY</a>,<a href="#ref-SD1" title="&quot;Revocation and Tracing Schemes for Stateless Receiver&quot;">SD1</a>,<a href="#ref-SD2" title="&quot;Efficient Trace and Revoke Schemes&quot;">SD2</a>].  If the key
         revocation algorithm is NULL, the Rekey SA contains only one
         KEK, which serves as the group KEK.  The rekey messages
         initialize or update Data SAs as usual.  However, the Rekey SA
         itself can be updated (the group KEK can be rekeyed) when
         members join or the KEK is about to expire.  Leave rekeying is
         done by re-initializing the Rekey SA through the rekey
         protocol.

      o  KEK ENCRYPTION ALGORITHM

         This specifies a standard encryption algorithm such as 3DES or
         AES, and also the KEK KEY LENGTH.

      o  AUTHENTICATION ALGORITHM

         This algorithm uses digital signatures for GCKS authentication
         (since all shared secrets are known to some or all members of
         the group), or some symmetric secret in computing MACs for
         group authentication.  Symmetric authentication provides weaker
         authentication in that any group member can impersonate a
         particular source.  The AUTHENTICATION KEY LENGTH is also to be
         specified.

      o  CONTROL GROUP ADDRESS

         This address is used for multicast transmission of rekey
         messages.  This information is sent over the control channel
         such as in an ANNOUNCEMENT protocol or call setup message.  The
         degree to which the control group address is protected is a
         matter of group policy.

      o  REKEY SERVER ADDRESS

         This address allows the registration server to be a different
         entity from the server used for rekeying, such as for future
         invocations of the registration and rekey protocols.  If the
         registration server and the rekey server are two different
         entities, the registration server sends the rekey server's
         address as part of the Rekey SA.




<span class="grey">Baugher, et al.              Informational                     [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


<span class="h4"><a class="selflink" id="section-6.2.2" href="#section-6.2.2">6.2.2</a>.  Group Identity</span>

   The group identity accompanies the SA (payload) information as an
   identifier if the specific group key management protocol allows
   multiple groups to be initialized in a single invocation of the
   registration protocol, or multiple groups to be updated in a single
   rekey message.  It is often simpler to restrict each registration
   invocation to a single group, but such a restriction is unnecessary.
   It is always necessary to identify the group when establishing a
   Rekey SA, either implicitly through an SPI or explicitly as an SA
   parameter.

<span class="h4"><a class="selflink" id="section-6.2.3" href="#section-6.2.3">6.2.3</a>.  KEKs</span>

   Corresponding to the key management algorithm, the Rekey SA contains
   one or more KEKs.  The GCKS holds the key encrypting keys of the
   group, while the members receive keys following the specification of
   the key management algorithm.  When there are multiple KEKs for a
   group (as in an LKH tree), each KEK needs to be associated with a Key
   ID, which is used to identify the key needed to decrypt it.  Each KEK
   has a LIFETIME associated with it, after which the KEK expires.

<span class="h4"><a class="selflink" id="section-6.2.4" href="#section-6.2.4">6.2.4</a>.  Authentication Key</span>

   The GCKS provides a symmetric or public key for authentication of its
   rekey messages.  Symmetric key authentication is appropriate only
   when all group members can be trusted not to impersonate the GCKS.
   The architecture does not rule out methods for deriving symmetric
   authentication keys at the member [<a href="./rfc2409" title="&quot;The Internet Key Exchange (IKE)&quot;">RFC2409</a>] rather than pushing them
   from the GCKS.

<span class="h4"><a class="selflink" id="section-6.2.5" href="#section-6.2.5">6.2.5</a>.  Replay Protection</span>

   Rekey messages need to be protected from replay/reflection attacks.
   Sequence numbers are used for this purpose, and the Rekey SA (or
   protocol) contains this information.

<span class="h4"><a class="selflink" id="section-6.2.6" href="#section-6.2.6">6.2.6</a>.  Security Parameter Index (SPI)</span>

   The tuple &lt;Group identity, SPI&gt; uniquely identifies a Rekey SA.  The
   SPI changes each time the KEKs change.

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  Contents of the Data SA</span>

   The GCKS specifies the data security protocol used for secure
   transmission of data from sender(s) to receiving members.  Examples
   of data security protocols include IPsec ESP [<a href="./rfc2401" title="&quot;Security Architecture for the Internet Protocol&quot;">RFC2401</a>] and SRTP
   [<a href="./rfc3711" title="&quot;The Secure Real-time Transport Protocol (SRTP)&quot;">RFC3711</a>].  While the contents of each of these protocols are out of



<span class="grey">Baugher, et al.              Informational                     [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   the scope of this document, we list the information sent by the
   registration protocol (or the rekey protocol) to initialize or update
   the Data SA.

<span class="h4"><a class="selflink" id="section-6.3.1" href="#section-6.3.1">6.3.1</a>.  Group Identity</span>

   The Group identity accompanies SA information when Data SAs are
   initialized or rekeyed for multiple groups in a single invocation of
   the registration protocol or in a single Rekey message.

<span class="h4"><a class="selflink" id="section-6.3.2" href="#section-6.3.2">6.3.2</a>.  Source Identity</span>

   The SA includes source identity information when the group owner
   chooses to reveal source identity to authorized members only.  A
   public channel such as the announcement protocol is only appropriate
   when there is no need to protect source or group identities.

<span class="h4"><a class="selflink" id="section-6.3.3" href="#section-6.3.3">6.3.3</a>.  Traffic Protection Keys</span>

   Regardless of the data security protocol used, the GCKS supplies the
   TPKs, or information to derive TPKs for traffic protection.

<span class="h4"><a class="selflink" id="section-6.3.4" href="#section-6.3.4">6.3.4</a>.  Data Authentication Keys</span>

   Depending on the data authentication method used by the data security
   protocol, group key management may pass one or more keys, functions
   (e.g., TESLA [<a href="#ref-TESLA-INFO" title="&quot;TESLA: Multicast Source Authentication Transform Introduction&quot;">TESLA-INFO</a>,<a href="#ref-TESLA-SPEC" title="&quot;TESLA: Multicast Source Authentication Transform Specification&quot;">TESLA-SPEC</a>]), or other parameters used for
   authenticating streams or files.

<span class="h4"><a class="selflink" id="section-6.3.5" href="#section-6.3.5">6.3.5</a>.  Sequence Numbers</span>

   The GCKS passes sequence numbers when needed by the data security
   protocol, for SA synchronization and replay protection.

<span class="h4"><a class="selflink" id="section-6.3.6" href="#section-6.3.6">6.3.6</a>.  Security Parameter Index (SPI)</span>

   The GCKS may provide an identifier as part of the Data SA contents
   for data security protocols that use an SPI or similar mechanism to
   identify an SA or keys within an SA.

<span class="h4"><a class="selflink" id="section-6.3.7" href="#section-6.3.7">6.3.7</a>.  Data SA policy</span>

   The Data SA parameters are specific to the data security protocol but
   generally include encryption algorithm and parameters, the source
   authentication algorithm and parameters, the group authentication
   algorithm and parameters, and/or replay protection information.





<span class="grey">Baugher, et al.              Informational                     [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Scalability Considerations</span>

   The area of group communications is quite diverse.  In
   teleconferencing, a multipoint control unit (MCU) may be used to
   aggregate a number of teleconferencing members into a single session;
   MCUs may be hierarchically organized as well.  A loosely coupled
   teleconferencing session [<a href="./rfc3550" title="&quot;RTP: A Transport Protocol for Real-Time Applications&quot;">RFC3550</a>] has no central controller but is
   fully distributed and end-to-end.  Teleconferencing sessions tend to
   have at most dozens of participants.  However, video broadcast that
   uses multicast communications and media-on-demand that uses unicast
   are large-scale groups numbering hundreds to millions of
   participants.

   As described in the Requirements section, <a href="#section-2">Section 2</a>, the group key
   management architecture supports multicast applications with a single
   sender.  The architecture described in this paper supports large-
   scale operation through the following features.

   1. There is no need for a unicast exchange to provide data keys to a
      security protocol for members who have previously registered in
      the particular group; data keys can be pushed in the rekey
      protocol.

   2. The registration and rekey protocols are separable to allow
      flexibility in how members receive group secrets.  A group may use
      a smart-card based system in place of the registration protocol,
      for example, to allow the rekey protocol to be used with no back
      channel for broadcast applications such as television conditional
      access systems.

   3. The registration and rekey protocols support new keys, algorithms,
      authentication mechanisms and authorization infrastructures in the
      architecture.  When the authorization infrastructure supports
      delegation, as in X.509 and SPKI, the GCKS function can be
      distributed as shown in Figure 3 below.

   The first feature in the list allows fast keying of data security
   protocols when the member already belongs to the group.  While this
   is realistic for subscriber groups and customers of service providers
   who offer content events, it may be too restrictive for applications
   that allow member enrollment at the time of the event.  The MSEC
   group key management architecture suggests hierarchically organized
   key distribution to handle potential mass simultaneous registration
   requests.  The Figure 3 configuration may be needed when conventional
   clustering and load balancing solutions of a central GCKS site cannot
   meet customer requirements.  Unlike conventional caching and content





<span class="grey">Baugher, et al.              Informational                     [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   distribution networks, however, the configuration shown in Figure 3
   has additional security ramifications for physical security of a
   GCKS.

                   +----------------------------------------+
                   |       +-------+                        |
                   |       |  GCKS |                        |
                   |       +-------+                        |
                   |         |   ^                          |
                   |         |   |                          |
                   |         |   +---------------+          |
                   |         |       ^           ^          |
                   |         |       |    ...    |          |
                   |         |   +--------+  +--------+     |
                   |         |   | MEMBER |  | MEMBER |     |
                   |         |   +--------+  +--------+     |
                   |         v                              |
                   |         +-------------+                |
                   |         |             |                |
                   |         v      ...    v                |
                   |     +-------+   +-------+              |
                   |     |  GCKS |   |  GCKS |              |
                   |     +-------+   +-------+              |
                   |         |   ^                          |
                   |         |   |                          |
                   |         |   +---------------+          |
                   |         |       ^           ^          |
                   |         |       |    ...    |          |
                   |         |   +--------+  +--------+     |
                   |         |   | MEMBER |  | MEMBER |     |
                   |         |   +--------+  +--------+     |
                   |         v                              |
                   |        ...                             |
                   +----------------------------------------+

               Figure 3: Hierarchically Organized Key Distribution

   More analysis and work is needed on the protocol instantiations of
   the group key management architecture, to determine how effectively
   and securely the architecture can support large-scale multicast
   applications.  In addition to being as secure as pairwise key
   management against man-in-the-middle, replay, and reflection attacks,
   group key management protocols have additional security needs.
   Unlike pairwise key management, group key management needs to be
   secure against attacks by group members who attempt to impersonate a
   GCKS or disrupt the operation of a GCKS, as well as by non-members.





<span class="grey">Baugher, et al.              Informational                     [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   Thus, secure groups need to converge to a common group key when
   members are attacking the group, joining and leaving the group, or
   being evicted from the group.  Group key management protocols also
   need to be robust when DoS attacks or network partition leads to
   large numbers of synchronized requests.  An instantiation of group
   key management, therefore, needs to consider how GCKS operation might
   be distributed across multiple GCKSs designated by the group owner to
   serve keys on behalf of a designated GCKS.  GSAKMP [<a href="#ref-GSAKMP" title="&quot;Group Secure Association Key Management Protocol&quot;">GSAKMP</a>] protocol
   uses the policy token and allows designating some of the members as
   subordinate GCKSs to address this scalability issue.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Security Considerations</span>

   This memo describes MSEC key management architecture.  This
   architecture will be instantiated in one or more group key management
   protocols, which must be protected against man-in-the-middle,
   connection hijacking, replay, or reflection of past messages, and
   denial of service attacks.

   Authenticated key exchange [STS,SKEME,<a href="./rfc2408">RFC2408</a>,RFC2412,<a href="./rfc2409">RFC2409</a>]
   techniques limit the effects of man-in-the-middle and connection
   hijacking attacks.  Sequence numbers and low-computation message
   authentication techniques can be effective against replay and
   reflection attacks.  Cookies [<a href="./rfc2522" title="&quot;Photuris: Session-Key Management Protocol&quot;">RFC2522</a>], when properly implemented,
   provide an efficient means to reduce the effects of denial of service
   attacks.

   This memo does not address attacks against key management or security
   protocol implementations such as so-called type attacks that aim to
   disrupt an implementation by such means as buffer overflow.  The
   focus of this memo is on securing the protocol, not on implementing
   the protocol.

   While classical techniques of authenticated key exchange can be
   applied to group key management, new problems arise with the sharing
   of secrets among a group of members:  group secrets may be disclosed
   by a member of the group, and group senders may be impersonated by
   other members of the group.  Key management messages from the GCKS
   should not be authenticated using shared symmetric secrets unless all
   members of the group can be trusted not to impersonate the GCKS or
   each other.  Similarly, members who disclose group secrets undermine
   the security of the entire group.  Group owners and GCKS
   administrators must be aware of these inherent limitations of group
   key management.

   Another limitation of group key management is policy complexity.
   While peer-to-peer security policy is an intersection of the policy
   of the individual peers, a group owner sets group security policy



<span class="grey">Baugher, et al.              Informational                     [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   externally in secure groups.  This document assumes there is no
   negotiation of cryptographic or other security parameters in group
   key management.  Group security policy, therefore, poses new risks to
   members who send and receive data from secure groups.  Security
   administrators, GCKS operators, and users need to determine minimal
   acceptable levels of security (e.g., authentication and admission
   policy of the group, key lengths, cryptographic algorithms and
   protocols used) when joining secure groups.

   Given the limitations and risks of group security, the security of
   the group key management registration protocol should be as good as
   the base protocols on which it is developed, such as IKE, IPsec, TLS,
   or SSL.  The particular instantiations of this group key management
   architecture must ensure that the high standards for authenticated
   key exchange are preserved in their protocol specifications, which
   will be Internet standards-track documents that are subject to
   review, analysis, and testing.

   The second protocol, the group key management rekey protocol, is new
   and has unknown risks.  The source-authentication risks described
   above are obviated by the use of public-key cryptography.  The use of
   multicast delivery may raise additional security issues such as
   reliability, implosion, and denial-of-service attacks based upon the
   use of multicast.  The rekey protocol specification needs to offer
   secure solutions to these problems.  Each instantiation of the rekey
   protocol, such as the GSAKMP Rekey or the GDOI Groupkey-push
   operations, need to validate the security of their rekey
   specifications.

   Novelty and complexity are the biggest risks to group key management
   protocols.  Much more analysis and experience are needed to ensure
   that the architecture described in this document can provide a well-
   articulated standard for security and risks of group key management.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Acknowledgments</span>

   The GKM Building Block [<a href="#ref-GKMBB" title="&quot;GKM Building Block: Group Security Association (GSA) Definition,&quot;">GKMBB</a>] I-D by SMuG was a precursor to this
   document; thanks to Thomas Hardjono and Hugh Harney for their
   efforts.  During the course of preparing this document, Andrea
   Colegrove, Brian Weis, George Gross, and several others in the MSEC
   WG and GSEC and SMuG research groups provided valuable comments that
   helped improve this document.  The authors appreciate their
   contributions to this document.








<span class="grey">Baugher, et al.              Informational                     [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Informative References</span>

   [<a id="ref-BatchRekey">BatchRekey</a>]    Yang, Y. R., et al., "Reliable Group Rekeying: Design
                   and Performance Analysis", Proc. ACM SIGCOMM, San
                   Diego, CA, August 2001.

   [<a id="ref-CLIQUES">CLIQUES</a>]       Steiner, M., Tsudik, G., and M. Waidner, "CLIQUES: A
                   New Approach to Group Key Agreement", IEEE ICDCS 97,
                   May 1997

   [<a id="ref-FN93">FN93</a>]          Fiat, A. and M. Naor, "Broadcast Encryption, Advances
                   in Cryptology", CRYPTO 93 Proceedings, Lecture Notes
                   in Computer Science, Vol. 773, pp. 480-491, 1994.

   [<a id="ref-GKMBB">GKMBB</a>]         Harney, H., M. Baugher, and T. Hardjono, "GKM
                   Building Block: Group Security Association (GSA)
                   Definition," Work in Progress, September 2000.

   [<a id="ref-GSAKMP">GSAKMP</a>]        Harney, H., Colegrove, A., Harder, E., Meth, U., and
                   R.  Fleischer, "Group Secure Association Key
                   Management Protocol", Work in Progress, February
                   2003.

   [<a id="ref-GSPT">GSPT</a>]          Hardjono, T., Harney, H., McDaniel, P., Colegrove,
                   A., and P.  Dinsmore, "The MSEC Group Security Policy
                   Token", Work in Progress, August 2003.

   [<a id="ref-H.235">H.235</a>]         International Telecommunications Union, "Security and
                   Encryption for H-Series (H.323 and other H.245-based)
                   Multimedia Terminals", ITU-T Recommendation H.235
                   Version 3, Work in progress, 2001.

   [<a id="ref-JKKV94">JKKV94</a>]        Just, M., Kranakis, E., Krizanc, D., and P. van
                   Oorschot, "On Key Distribution via True
                   Broadcasting", Proc. 2nd ACM Conference on Computer
                   and Communications Security, pp. 81-88, November
                   1994.

   [<a id="ref-MARKS">MARKS</a>]         Briscoe, B., "MARKS: Zero Side Effect Multicast Key
                   Management Using Arbitrarily Revealed Key Sequences",
                   Proc.  First International Workshop on Networked
                   Group Communication (NGC), Pisa, Italy, November
                   1999.

   [<a id="ref-MIKEY">MIKEY</a>]         Arkko, J., Carrara, E., Lindholm, F., Naslund, M.,
                   and K. Norrman, "MIKEY: Multimedia Internet KEYing",
                   <a href="./rfc3830">RFC 3830</a>, August 2004.




<span class="grey">Baugher, et al.              Informational                     [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   [<a id="ref-MSEC-Arch">MSEC-Arch</a>]     Hardjono, T. and B. Weis, "The Multicast Group
                   Security Architecture", <a href="./rfc3740">RFC 3740</a>, March 2004.

   [<a id="ref-MVV">MVV</a>]           Menzes, A.J., van Oorschot, P.C., and S.A. Vanstone,
                   "Handbook of Applied Cryptography", CRC Press, 1996.

   [<a id="ref-NORM">NORM</a>]          Adamon, B., Bormann, C., Handley, M., and J. Macker,
                   "Negative-acknowledgment (NACK)-Oriented Reliable
                   Multicast (NORM) Protocol", <a href="./rfc3940">RFC 3940</a>, November 2004.

   [<a id="ref-OFT">OFT</a>]           Balenson, D., McGrew, P.C., and A. Sherman, "Key
                   Management for Large Dynamic Groups: One-Way Function
                   Trees and Amortized Initialization", IRTF Work in
                   Progress, August 2000.

   [<a id="ref-RFC2093">RFC2093</a>]       Harney, H. and C. Muckenhirn, "Group Key Management
                   Protocol (GKMP) Specification", <a href="./rfc2093">RFC 2093</a>, July 1997.

   [<a id="ref-RFC2094">RFC2094</a>]       Harney, H., and C. Muckenhirn, "Group Key Management
                   Protocol (GKMP) Architecture" <a href="./rfc2094">RFC 2094</a>, July 1997.

   [<a id="ref-RFC2326">RFC2326</a>]       Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
                   Streaming Protocol (RTSP)", <a href="./rfc2326">RFC 2326</a>, April 1998.

   [<a id="ref-RFC2327">RFC2327</a>]       Handley, M. and V. Jacobson, "SDP: Session
                   Description Protocol", <a href="./rfc2327">RFC 2327</a>, April 1998.

   [<a id="ref-RFC2367">RFC2367</a>]       McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
                   Management API, Version 2", <a href="./rfc2367">RFC 2367</a>, July 1998.

   [<a id="ref-RFC2401">RFC2401</a>]       Kent, S. and R. Atkinson, "Security Architecture for
                   the Internet Protocol", <a href="./rfc2401">RFC 2401</a>, November 1998.

   [<a id="ref-RFC2408">RFC2408</a>]       Maughan, D., Schertler, M., Schneider, M., and J.
                   Turner, "Internet Security Association and Key
                   Management Protocol (ISAKMP)", <a href="./rfc2408">RFC 2408</a>, November
                   1998.

   [<a id="ref-RFC2409">RFC2409</a>]       Harkins, D. and D. Carrel, "The Internet Key Exchange
                   (IKE)", <a href="./rfc2409">RFC 2409</a>, November 1998.

   [<a id="ref-RFC2412">RFC2412</a>]       Orman, H., "The OAKLEY Key Determination Protocol",
                   <a href="./rfc2412">RFC 2412</a>, November 1998.

   [<a id="ref-RFC2522">RFC2522</a>]       Karn, P. and W. Simpson, "Photuris: Session-Key
                   Management Protocol", <a href="./rfc2522">RFC 2522</a>, March 1999.





<span class="grey">Baugher, et al.              Informational                     [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   [<a id="ref-RFC2693">RFC2693</a>]       Ellison, C., Frantz, B., Lampson, B., Rivest, R.,
                   Thomas, B., and T. Ylonen, "SPKI Certificate Theory",
                   <a href="./rfc2693">RFC 2693</a>, September 1999.

   [<a id="ref-RFC3261">RFC3261</a>]       Rosenberg, J., Schulzrinne, H., Camarillo, G.,
                   Johnston, A., Peterson, J., Sparks, R., Handley, M.,
                   and E. Schooler, "SIP: Session Initiation Protocol",
                   <a href="./rfc3261">RFC 3261</a>, June 2002.

   [<a id="ref-RFC3280">RFC3280</a>]       Housley, R., Polk, W., Ford, W., and D. Solo,
                   "Internet X.509 Public Key Infrastructure Certificate
                   and Certificate Revocation List (CRL) Profile", <a href="./rfc3280">RFC</a>
                   <a href="./rfc3280">3280</a>, April 2002.

   [<a id="ref-RFC2627">RFC2627</a>]       Wallner, D., Harder, E., and R. Agee, "Key Management
                   for Multicast: Issues and Architectures", <a href="./rfc2627">RFC 2627</a>,
                   June 1999.

   [<a id="ref-RFC3450">RFC3450</a>]       Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and
                   J.  Crowcroft, "Asynchronous Layered Coding (ALC)
                   Protocol Instantiation", <a href="./rfc3450">RFC 3450</a>, December 2002.

   [<a id="ref-RFC3547">RFC3547</a>]       Baugher, M., Weis, B., Hardjono, T., and H. Harney,
                   "The Group Domain of Interpretation", <a href="./rfc3547">RFC 3547</a>, July
                   2003.

   [<a id="ref-RFC3550">RFC3550</a>]       Schulzrinne, H., Casner, S., Frederick, R., and V.
                   Jacobson, "RTP: A Transport Protocol for Real-Time
                   Applications", STD 64, <a href="./rfc3550">RFC 3550</a>, July 2003.

   [<a id="ref-RFC3711">RFC3711</a>]       Baugher, M., McGrew, D., Naslund, M., Carrara, E.,
                   and K.  Norrman, "The Secure Real-time Transport
                   Protocol (SRTP)", <a href="./rfc3711">RFC 3711</a>, March 2004.

   [<a id="ref-SD1">SD1</a>]           Naor, D., Naor, M., and J. Lotspiech, "Revocation and
                   Tracing Schemes for Stateless Receiver", Advances in
                   Cryptology - CRYPTO, Santa Barbara, CA: Springer-
                   Verlag Inc., LNCS 2139, August 2001.

   [<a id="ref-SD2">SD2</a>]           Naor, M. and B. Pinkas, "Efficient Trace and Revoke
                   Schemes", Proceedings of Financial Cryptography 2000,
                   Anguilla, British West Indies, February 2000.

   [<a id="ref-Self-Healing">Self-Healing</a>]  Staddon, J., et. al., "Self-healing Key Distribution
                   with Revocation", Proc. 2002 IEEE Symposium on
                   Security and Privacy, Oakland, CA, May 2002.





<span class="grey">Baugher, et al.              Informational                     [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


   [<a id="ref-SKEME">SKEME</a>]         H. Krawczyk, "SKEME: A Versatile Secure Key Exchange
                   Mechanism for Internet", ISOC Secure Networks and
                   Distributed Systems Symposium, San Diego, 1996.

   [<a id="ref-STS">STS</a>]           Diffie, P. van Oorschot, M., and J. Wiener,
                   "Authentication and Authenticated Key Exchanges",
                   Designs, Codes and Cryptography, 2, 107-125 (1992),
                   Kluwer Academic Publishers.

   [<a id="ref-TAXONOMY">TAXONOMY</a>]      Canetti, R., et. al., "Multicast Security: A Taxonomy
                   and some Efficient Constructions", IEEE INFOCOM,
                   1999.

   [<a id="ref-TESLA-INFO">TESLA-INFO</a>]    Perrig, A., Canetti, R., Song, D., Tygar, D., and B.
                   Briscoe, "TESLA: Multicast Source Authentication
                   Transform Introduction", Work in Progress, December
                   2004.

   [<a id="ref-TESLA-SPEC">TESLA-SPEC</a>]    Perrig, A., R. Canetti, and Whillock, "TESLA:
                   Multicast Source Authentication Transform
                   Specification", Work in Progress, April 2002.

   [<a id="ref-tGSAKMP">tGSAKMP</a>]       Harney, H., et. al., "Tunneled Group Secure
                   Association Key Management Protocol", Work in
                   Progress, May 2003.

   [<a id="ref-TLS">TLS</a>]           Dierks, T. and C. Allen, "The TLS Protocol Version
                   1.0," <a href="./rfc2246">RFC 2246</a>, January 1999.

   [<a id="ref-TPM">TPM</a>]           Marks, D. and B. Turnbull, "Technical protection
                   measures:  The Intersection of Technology, Law, and
                   Commercial Licenses", Workshop on Implementation
                   Issues of the WIPO Copyright Treaty (WCT) and the
                   WIPO Performances and Phonograms Treaty (WPPT), World
                   Intellectual Property Organization, Geneva, December
                   6 and 7, 1999.

   [<a id="ref-Wool">Wool</a>]          Wool, A., "Key Management for Encrypted broadcast",
                   5th ACM Conference on Computer and Communications
                   Security, San Francisco, CA, Nov. 1998.











<span class="grey">Baugher, et al.              Informational                     [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


Authors' Addresses

   Mark Baugher
   Cisco Systems
   5510 SW Orchid St.
   Portland, OR  97219, USA

   Phone: +1 408-853-4418
   EMail: mbaugher@cisco.com


   Ran Canetti
   IBM Research
   30 Saw Mill River Road
   Hawthorne, NY 10532, USA

   Phone: +1 914-784-7076
   EMail: canetti@watson.ibm.com


   Lakshminath R. Dondeti
   Qualcomm
   5775 Morehouse Drive
   San Diego, CA 92121

   Phone: +1 858 845 1267
   EMail: ldondeti@qualcomm.com


   Fredrik Lindholm
   Ericsson Research
   SE-16480 Stockholm, Sweden

   Phone: +46 8 58531705
   EMail: fredrik.lindholm@ericsson.com
















<span class="grey">Baugher, et al.              Informational                     [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc4046">RFC 4046</a>         MSEC Group Key Management Architecture       April 2005</span>


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, 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 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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   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
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   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.

Acknowledgement

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







Baugher, et al.              Informational                     [Page 38]
</pre>