doc: Add RFC documents

1 files changed, 2131 insertions, 0 deletions

diff --git a/doc/rfc/rfc4046.txt b/doc/rfc/rfc4046.txt
new file mode 100644
index 0000000..28c6a35
--- /dev/null
+++ b/doc/rfc/rfc4046.txt
@@ -0,0 +1,2131 @@
+
+
+
+
+
+
+Network Working Group                                         M. Baugher
+Request for Comments: 4046                                         Cisco
+Category: Informational                                       R. Canetti
+                                                                     IBM
+                                                              L. Dondeti
+                                                                Qualcomm
+                                                             F. Lindholm
+                                                                Ericsson
+                                                              April 2005
+
+
+      Multicast Security (MSEC) Group Key Management Architecture
+
+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
+
+   1. Introduction: Purpose of this Document ..........................2
+   2. Requirements of a Group Key Management Protocol .................4
+   3. Overall Design of Group Key Management Architecture .............6
+      3.1. Overview ...................................................6
+      3.2. Detailed Description of the GKM Architecture ...............8
+      3.3. Properties of the Design ..................................11
+      3.4. Group Key Management Block Diagram ........................11
+   4. Registration Protocol ..........................................13
+      4.1. Registration Protocol via Piggybacking or Protocol Reuse ..13
+      4.2. Properties of Alternative Registration Exchange Types .....14
+
+
+
+Baugher, et al.              Informational                      [Page 1]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+      4.3. Infrastructure for Alternative Registration
+           Exchange Types ............................................15
+      4.4. De-registration Exchange ..................................16
+   5. Rekey Protocol .................................................16
+      5.1. Goals of the Rekey Protocol ...............................17
+      5.2. Rekey Message Transport and Protection ....................17
+      5.3. Reliable Transport of Rekey Messages ......................18
+      5.4. State-of-the-art on Reliable Multicast Infrastructure .....20
+      5.5. Implosion .................................................21
+      5.6. Incorporating Group Key Management Algorithms .............22
+      5.7. Stateless, Stateful, and Self-healing Rekeying
+           Algorithms ................................................22
+      5.8. Interoperability of a GKMA ................................23
+   6. Group Security Association .....................................24
+      6.1. Group Policy ..............................................24
+      6.2. Contents of the Rekey SA ..................................25
+           6.2.1. Rekey SA Policy ....................................26
+           6.2.2. Group Identity .....................................27
+           6.2.3. KEKs ...............................................27
+           6.2.4. Authentication Key .................................27
+           6.2.5. Replay Protection ..................................27
+           6.2.6. Security Parameter Index (SPI) .....................27
+      6.3. Contents of the Data SA ...................................27
+           6.3.1. Group Identity .....................................28
+           6.3.2. Source Identity ....................................28
+           6.3.3. Traffic Protection Keys ............................28
+           6.3.4. Data Authentication Keys ...........................28
+           6.3.5. Sequence Numbers ...................................28
+           6.3.6. Security Parameter Index (SPI) .....................28
+           6.3.7. Data SA Policy .....................................28
+   7. Scalability Considerations .....................................29
+   8. Security Considerations ........................................31
+   9. Acknowledgments ................................................32
+   10. Informative References ........................................33
+
+1.  Introduction: Purpose of this Document
+
+   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.
+
+
+
+
+Baugher, et al.              Informational                      [Page 2]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   Group and multicast applications in IP networks have diverse security
+   requirements [TAXONOMY].  Their key management requirements, briefly
+   reviewed in Section 2.0, 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 [RFC3711] and IPsec [RFC2401]) 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 [RFC2094] and assumed by group
+   key management algorithms such as LKH [RFC2627], OFT [OFT], and MARKS
+   [MARKS].  There are other approaches that are not considered in this
+   architecture, such as the highly distributed Cliques group key
+   management protocol [CLIQUES] or broadcast key management schemes
+   [FN93,Wool].  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 [GKMBB] and is part of
+   the MSEC document roadmap.  The MSEC architecture [MSEC-Arch] defines
+   a complete multicast or group security architecture, of which key
+   management is a component.
+
+   The rest of this document is organized as follows.  Section 2
+   discusses the security, performance and architectural requirements
+   for a group key management protocol.  Section 3 presents the overall
+   architectural design principles.  Section 4 describes the
+   registration protocol in detail, and Section 5 does the same for
+   rekey protocol.  Section 6 considers the interface to the Group
+   Security Association (GSA).  Section 7 reviews the scalability issues
+   for group key management protocols and Section 8 discusses security
+   considerations.
+
+
+
+Baugher, et al.              Informational                      [Page 3]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+2.  Requirements of a Group Key Management Protocol
+
+   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 [TAXONOMY]).  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.
+
+
+
+
+
+Baugher, et al.              Informational                      [Page 4]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   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 [RFC3711].
+
+   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 [RFC2627].
+
+   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
+
+
+
+Baugher, et al.              Informational                      [Page 5]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   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) [TPM] 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 [FN93,JKKV94] 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.
+
+3.  Overall Design of Group Key Management Architecture
+
+   The overall group key management architecture is based upon a group
+   controller model [RFC2093,RFC2094,RFC2627,OFT,GSAKMP,RFC3547] with a
+   single group owner as the root-of-trust.  The group owner designates
+   a group controller for member registration and GSA rekeying.
+
+3.1.  Overview
+
+   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:
+
+
+
+
+
+Baugher, et al.              Informational                      [Page 6]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+      (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 [MARKS], 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 [TAXONOMY], that is, enabling each
+          group member to verify that a rekey message originates with
+          the GCKS and none other.
+
+
+
+
+Baugher, et al.              Informational                      [Page 7]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+      (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.
+
+3.2.  Detailed Description of the GKM Architecture
+
+   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
+   [RFC2627,OFT,TAXONOMY,SD1,SD2].  The data security protocol uses TPKs
+   to protect streams, files, or other data sent and received by
+
+
+
+
+Baugher, et al.              Informational                      [Page 8]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   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           |
+   | +--------------------------------------------------------------+ |
+   | |                                                              | |
+   | |                    +--------------------+                    | |
+   | |            +------>|        GCKS        |<------+            | |
+   | |            |       +--------------------+       |            | |
+   | |     REGISTRATION or          |            REGISTRATION or    | |
+   | |     DE-REGISTRATION          |            DE-REGISTRATION    | |
+   | |         PROTOCOL             |               PROTOCOL        | |
+   | |            |                 |                  |            | |
+   | |            v                REKEY               v            | |
+   | |   +-----------------+     PROTOCOL     +-----------------+   | |
+   | |   |                 |    (OPTIONAL)    |                 |   | |
+   | |   |    SENDER(S)    |<-------+-------->|   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.
+
+
+
+Baugher, et al.              Informational                      [Page 9]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+      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.
+
+
+
+
+Baugher, et al.              Informational                     [Page 10]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   Figure 1 shows two blocks that are external to the group key
+   management protocol:  The policy and authorization infrastructures
+   are discussed in Section 6.1.  The Multicast Security Architecture
+   document further clarifies the SAs and their use as part of the
+   complete architecture of a multicast security solution [MSEC-Arch].
+
+3.3.  Properties of the Design
+
+   The design of Section 3.2 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 [RFC2627,OFT,SD1,SD2] 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.
+
+3.4.  Group Key Management Block Diagram
+
+   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
+
+
+
+Baugher, et al.              Informational                     [Page 11]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   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) [RFC2367].  Various vendors also define the functions and
+   interface of credential stores, CRED in Figure 2.
+
+     +----------------------------------------------------------+
+     |                                                          |
+     | +-------------+         +------------+                   |
+     | |   CONTROL   |         |   CONTROL  |                   |
+     | +------^------+         +------|-----+  +--------+       |
+     |        |                       |  +-----| CRED   |       |
+     |        |                       |  |     +--------+       |
+     |   +----v----+             +----v--v-+   +--------+       |
+     |   |         <-----Reg----->         |<->|  SAD   |       |
+     |   |   GKM    -----Rek----->   GKM   |   +--------+       |
+     |   |         |             |         |   +--------+       |
+     |   |         ------+       |         |<->|  SPD   |       |
+     |   +---------+     |       +-^-------+   +--------+       |
+     |   +--------+      |         | |   |                      |
+     |   | CRED   |----->+         | |   +-------------------+  |
+     |   +--------+      |         | +--------------------+  |  |
+     |   +--------+      |       +-V-------+   +--------+ |  |  |
+     |   |  SAD   <----->+       |         |<->|  SAD   <-+  |  |
+     |   +--------+      |       |SECURITY |   +--------+    |  |
+     |   +--------+      |       |PROTOCOL |   +--------+    |  |
+     |   |  SPD   <----->+       |         |<->|  SPD   <----+  |
+     |   +--------+              +---------+   +--------+       |
+     |                                                          |
+     |     (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 [GSPT] but its implementation is specific to the GCKS.  For
+   large scale multicast sessions, CONTROL could perform session
+
+
+
+Baugher, et al.              Informational                     [Page 12]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   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 [RFC2327].  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.
+
+4.  Registration Protocol
+
+   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 [tGSAKMP].  GDOI [RFC3547] 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.
+
+4.1.  Registration Protocol via Piggybacking or Protocol Reuse
+
+   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
+
+
+
+Baugher, et al.              Informational                     [Page 13]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   call establishment [H.235,MIKEY], 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 [RFC2409], 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.
+
+4.2.  Properties of Alternative Registration Exchange Types
+
+   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-
+
+
+
+Baugher, et al.              Informational                     [Page 14]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   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 [MVV].
+
+   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.
+
+4.3.  Infrastructure for Alternative Registration Exchange Types
+
+   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.
+
+
+
+Baugher, et al.              Informational                     [Page 15]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+4.4.  De-registration Exchange
+
+   The session-establishment protocol (e.g., SIP, RTSP) that conveys a
+   registration exchange often has a session-disestablishment protocol
+   such as RTSP TEARDOWN [RFC2326] or SIP BYE [RFC3261].  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.
+
+5.  Rekey Protocol
+
+   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.
+
+
+
+
+Baugher, et al.              Informational                     [Page 16]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+5.1.  Goals of the Rekey Protocol
+
+   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.
+
+5.2.  Rekey Message Transport and Protection
+
+   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.
+
+
+
+Baugher, et al.              Informational                     [Page 17]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   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
+   [RFC2627,OFT] or multiple membership changes [SD1,SD2,BatchRekey] and
+   may contain group key initialization messages [OFT].
+
+5.3.  Reliable Transport of Rekey Messages
+
+   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.
+
+
+
+
+Baugher, et al.              Informational                     [Page 18]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   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)
+          [BatchRekey].
+
+   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
+
+
+
+Baugher, et al.              Informational                     [Page 19]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+         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 [GSPT].  Alternatively, a policy token may contain a
+   field specifying one or more methods supported for resynchronization
+   of a GSA.
+
+5.4.  State-of-the-art on Reliable Multicast Infrastructure
+
+   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,RFC3450].  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,
+
+
+
+Baugher, et al.              Informational                     [Page 20]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   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.
+
+5.5.  Implosion
+
+   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.
+
+
+
+
+
+Baugher, et al.              Informational                     [Page 21]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   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.
+
+5.6.  Incorporating Group Key Management Algorithms
+
+   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.
+
+5.7.  Stateless, Stateful, and Self-healing Rekeying Algorithms
+
+   We classify group key management algorithms into three categories:
+   stateful, stateless, and self-healing.
+
+   Stateful algorithms [RFC2627,OFT] 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
+
+
+
+Baugher, et al.              Informational                     [Page 22]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   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 [SD1,SD2] 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 [Self-Healing], a member can reconstruct a
+   lost rekey message as long as it receives some past and some future
+   rekey messages.
+
+5.8.  Interoperability of a GKMA
+
+   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).
+
+
+
+
+
+
+
+Baugher, et al.              Informational                     [Page 23]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   Key IDs may change in some implementations in which case one needs to
+   send:
+
+         o List of <old id, new id> pairs.
+
+6.  Group Security Association
+
+   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).
+
+6.1.  Group Policy
+
+   Group policy is described in detail in the Group Security Policy
+   Token document [GSPT].  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.
+
+
+
+
+
+
+Baugher, et al.              Informational                     [Page 24]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   The acceptable cryptographic policies for the registration protocol,
+   which may run over TLS [TLS], 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 [RFC3280], SPKI [RFC2693], 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.
+
+6.2.  Contents of the Rekey SA
+
+   The Rekey SA protects the rekey protocol.  It contains cryptographic
+   policy, Group Identity, and Security Parameter Index (SPI) [RFC2401]
+   to uniquely identify an SA, replay protection information, and key
+   protection keys.
+
+
+
+Baugher, et al.              Informational                     [Page 25]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+6.2.1.  Rekey SA Policy
+
+      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 [RFC2627,OFT,TAXONOMY,SD1,SD2].  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.
+
+
+
+
+Baugher, et al.              Informational                     [Page 26]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+6.2.2.  Group Identity
+
+   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.
+
+6.2.3.  KEKs
+
+   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.
+
+6.2.4.  Authentication Key
+
+   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 [RFC2409] rather than pushing them
+   from the GCKS.
+
+6.2.5.  Replay Protection
+
+   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.
+
+6.2.6.  Security Parameter Index (SPI)
+
+   The tuple <Group identity, SPI> uniquely identifies a Rekey SA.  The
+   SPI changes each time the KEKs change.
+
+6.3.  Contents of the Data SA
+
+   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 [RFC2401] and SRTP
+   [RFC3711].  While the contents of each of these protocols are out of
+
+
+
+Baugher, et al.              Informational                     [Page 27]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   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.
+
+6.3.1.  Group Identity
+
+   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.
+
+6.3.2.  Source Identity
+
+   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.
+
+6.3.3.  Traffic Protection Keys
+
+   Regardless of the data security protocol used, the GCKS supplies the
+   TPKs, or information to derive TPKs for traffic protection.
+
+6.3.4.  Data Authentication Keys
+
+   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 [TESLA-INFO,TESLA-SPEC]), or other parameters used for
+   authenticating streams or files.
+
+6.3.5.  Sequence Numbers
+
+   The GCKS passes sequence numbers when needed by the data security
+   protocol, for SA synchronization and replay protection.
+
+6.3.6.  Security Parameter Index (SPI)
+
+   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.
+
+6.3.7.  Data SA policy
+
+   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.
+
+
+
+
+
+Baugher, et al.              Informational                     [Page 28]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+7.  Scalability Considerations
+
+   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 [RFC3550] 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, Section 2, 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
+
+
+
+
+
+Baugher, et al.              Informational                     [Page 29]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   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.
+
+
+
+
+
+Baugher, et al.              Informational                     [Page 30]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   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 [GSAKMP] protocol
+   uses the policy token and allows designating some of the members as
+   subordinate GCKSs to address this scalability issue.
+
+8.  Security Considerations
+
+   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,RFC2408,RFC2412,RFC2409]
+   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 [RFC2522], 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
+
+
+
+Baugher, et al.              Informational                     [Page 31]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   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.
+
+9.  Acknowledgments
+
+   The GKM Building Block [GKMBB] 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.
+
+
+
+
+
+
+
+
+Baugher, et al.              Informational                     [Page 32]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+10.  Informative References
+
+   [BatchRekey]    Yang, Y. R., et al., "Reliable Group Rekeying: Design
+                   and Performance Analysis", Proc. ACM SIGCOMM, San
+                   Diego, CA, August 2001.
+
+   [CLIQUES]       Steiner, M., Tsudik, G., and M. Waidner, "CLIQUES: A
+                   New Approach to Group Key Agreement", IEEE ICDCS 97,
+                   May 1997
+
+   [FN93]          Fiat, A. and M. Naor, "Broadcast Encryption, Advances
+                   in Cryptology", CRYPTO 93 Proceedings, Lecture Notes
+                   in Computer Science, Vol. 773, pp. 480-491, 1994.
+
+   [GKMBB]         Harney, H., M. Baugher, and T. Hardjono, "GKM
+                   Building Block: Group Security Association (GSA)
+                   Definition," Work in Progress, September 2000.
+
+   [GSAKMP]        Harney, H., Colegrove, A., Harder, E., Meth, U., and
+                   R.  Fleischer, "Group Secure Association Key
+                   Management Protocol", Work in Progress, February
+                   2003.
+
+   [GSPT]          Hardjono, T., Harney, H., McDaniel, P., Colegrove,
+                   A., and P.  Dinsmore, "The MSEC Group Security Policy
+                   Token", Work in Progress, August 2003.
+
+   [H.235]         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.
+
+   [JKKV94]        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.
+
+   [MARKS]         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.
+
+   [MIKEY]         Arkko, J., Carrara, E., Lindholm, F., Naslund, M.,
+                   and K. Norrman, "MIKEY: Multimedia Internet KEYing",
+                   RFC 3830, August 2004.
+
+
+
+
+Baugher, et al.              Informational                     [Page 33]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   [MSEC-Arch]     Hardjono, T. and B. Weis, "The Multicast Group
+                   Security Architecture", RFC 3740, March 2004.
+
+   [MVV]           Menzes, A.J., van Oorschot, P.C., and S.A. Vanstone,
+                   "Handbook of Applied Cryptography", CRC Press, 1996.
+
+   [NORM]          Adamon, B., Bormann, C., Handley, M., and J. Macker,
+                   "Negative-acknowledgment (NACK)-Oriented Reliable
+                   Multicast (NORM) Protocol", RFC 3940, November 2004.
+
+   [OFT]           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.
+
+   [RFC2093]       Harney, H. and C. Muckenhirn, "Group Key Management
+                   Protocol (GKMP) Specification", RFC 2093, July 1997.
+
+   [RFC2094]       Harney, H., and C. Muckenhirn, "Group Key Management
+                   Protocol (GKMP) Architecture" RFC 2094, July 1997.
+
+   [RFC2326]       Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
+                   Streaming Protocol (RTSP)", RFC 2326, April 1998.
+
+   [RFC2327]       Handley, M. and V. Jacobson, "SDP: Session
+                   Description Protocol", RFC 2327, April 1998.
+
+   [RFC2367]       McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
+                   Management API, Version 2", RFC 2367, July 1998.
+
+   [RFC2401]       Kent, S. and R. Atkinson, "Security Architecture for
+                   the Internet Protocol", RFC 2401, November 1998.
+
+   [RFC2408]       Maughan, D., Schertler, M., Schneider, M., and J.
+                   Turner, "Internet Security Association and Key
+                   Management Protocol (ISAKMP)", RFC 2408, November
+                   1998.
+
+   [RFC2409]       Harkins, D. and D. Carrel, "The Internet Key Exchange
+                   (IKE)", RFC 2409, November 1998.
+
+   [RFC2412]       Orman, H., "The OAKLEY Key Determination Protocol",
+                   RFC 2412, November 1998.
+
+   [RFC2522]       Karn, P. and W. Simpson, "Photuris: Session-Key
+                   Management Protocol", RFC 2522, March 1999.
+
+
+
+
+
+Baugher, et al.              Informational                     [Page 34]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   [RFC2693]       Ellison, C., Frantz, B., Lampson, B., Rivest, R.,
+                   Thomas, B., and T. Ylonen, "SPKI Certificate Theory",
+                   RFC 2693, September 1999.
+
+   [RFC3261]       Rosenberg, J., Schulzrinne, H., Camarillo, G.,
+                   Johnston, A., Peterson, J., Sparks, R., Handley, M.,
+                   and E. Schooler, "SIP: Session Initiation Protocol",
+                   RFC 3261, June 2002.
+
+   [RFC3280]       Housley, R., Polk, W., Ford, W., and D. Solo,
+                   "Internet X.509 Public Key Infrastructure Certificate
+                   and Certificate Revocation List (CRL) Profile", RFC
+                   3280, April 2002.
+
+   [RFC2627]       Wallner, D., Harder, E., and R. Agee, "Key Management
+                   for Multicast: Issues and Architectures", RFC 2627,
+                   June 1999.
+
+   [RFC3450]       Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and
+                   J.  Crowcroft, "Asynchronous Layered Coding (ALC)
+                   Protocol Instantiation", RFC 3450, December 2002.
+
+   [RFC3547]       Baugher, M., Weis, B., Hardjono, T., and H. Harney,
+                   "The Group Domain of Interpretation", RFC 3547, July
+                   2003.
+
+   [RFC3550]       Schulzrinne, H., Casner, S., Frederick, R., and V.
+                   Jacobson, "RTP: A Transport Protocol for Real-Time
+                   Applications", STD 64, RFC 3550, July 2003.
+
+   [RFC3711]       Baugher, M., McGrew, D., Naslund, M., Carrara, E.,
+                   and K.  Norrman, "The Secure Real-time Transport
+                   Protocol (SRTP)", RFC 3711, March 2004.
+
+   [SD1]           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.
+
+   [SD2]           Naor, M. and B. Pinkas, "Efficient Trace and Revoke
+                   Schemes", Proceedings of Financial Cryptography 2000,
+                   Anguilla, British West Indies, February 2000.
+
+   [Self-Healing]  Staddon, J., et. al., "Self-healing Key Distribution
+                   with Revocation", Proc. 2002 IEEE Symposium on
+                   Security and Privacy, Oakland, CA, May 2002.
+
+
+
+
+
+Baugher, et al.              Informational                     [Page 35]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+   [SKEME]         H. Krawczyk, "SKEME: A Versatile Secure Key Exchange
+                   Mechanism for Internet", ISOC Secure Networks and
+                   Distributed Systems Symposium, San Diego, 1996.
+
+   [STS]           Diffie, P. van Oorschot, M., and J. Wiener,
+                   "Authentication and Authenticated Key Exchanges",
+                   Designs, Codes and Cryptography, 2, 107-125 (1992),
+                   Kluwer Academic Publishers.
+
+   [TAXONOMY]      Canetti, R., et. al., "Multicast Security: A Taxonomy
+                   and some Efficient Constructions", IEEE INFOCOM,
+                   1999.
+
+   [TESLA-INFO]    Perrig, A., Canetti, R., Song, D., Tygar, D., and B.
+                   Briscoe, "TESLA: Multicast Source Authentication
+                   Transform Introduction", Work in Progress, December
+                   2004.
+
+   [TESLA-SPEC]    Perrig, A., R. Canetti, and Whillock, "TESLA:
+                   Multicast Source Authentication Transform
+                   Specification", Work in Progress, April 2002.
+
+   [tGSAKMP]       Harney, H., et. al., "Tunneled Group Secure
+                   Association Key Management Protocol", Work in
+                   Progress, May 2003.
+
+   [TLS]           Dierks, T. and C. Allen, "The TLS Protocol Version
+                   1.0," RFC 2246, January 1999.
+
+   [TPM]           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.
+
+   [Wool]          Wool, A., "Key Management for Encrypted broadcast",
+                   5th ACM Conference on Computer and Communications
+                   Security, San Francisco, CA, Nov. 1998.
+
+
+
+
+
+
+
+
+
+
+
+Baugher, et al.              Informational                     [Page 36]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baugher, et al.              Informational                     [Page 37]
+
+RFC 4046         MSEC Group Key Management Architecture       April 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Baugher, et al.              Informational                     [Page 38]
+