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

Versions: 00 01 02 03 04 05 06 07 08 RFC 4046

        Internet Draft                                  Mark Baugher (Cisco)
        IETF MSEC WG                                       Ran Canetti (IBM)
        Expires: September 2003                 Lakshminath Dondeti (Nortel)
                                                 Fredrik Lindholm (Ericsson)
                                                             March 03, 2003
                          Group Key Management Architecture
     Status of this Memo
        This document is an Internet-Draft and is in full conformance
        with all provisions of Section 10 of RFC2026.
        Internet-Drafts are working documents of the Internet Engineering
        Task Force (IETF), its areas, and its working groups.  Note that
        other groups may also distribute working documents as Internet-
        Internet-Drafts are draft documents valid for a maximum of six
        months and may be updated, replaced, or obsoleted by other documents
        at any time.  It is inappropriate to use Internet-Drafts as
        reference material or to cite them other than as "work in progress."
        The list of current Internet-Drafts can be accessed at
        The list of Internet-Draft Shadow Directories can be accessed at
        This document presents a group key-management architecture for MSEC.
        The purpose of this document is to define the common architecture for
        MSEC group key-management protocols that support a variety of
        application, transport, and internetwork security protocols.  To
        address these diverse uses, MSEC may need to standardize two or more
        group key management protocols that have common requirements,
        abstractions, overall design, and messages. The framework and
        guidelines in this document allow for a modular and flexible design
        of group key management protocols for a variety different settings
        that are specialized to application needs.
        Comments on this document should be sent to msec@securemulticast.org.
       Baugher, Canetti, Dondeti, Lindholm                       February 2002
     Table of Contents
        Status of this Memo...............................................1
        1.0 Introduction: Purpose of this Document........................3
        2.0 Requirements for a group key management protocol..............3
        3.0 Overall Design................................................6
         3.1 Overview.....................................................6
         3.2 Detailed description.........................................8
         3.3 Properties of the design....................................10
         3.4 Implementation Diagram......................................10
        4.0 Registration Protocol........................................12
         4.1 Registration Protocol Message Exchange......................12
         4.2 Properties of Alternative Registration Exchange Types.......13
         4.3 Infrastructure for Alternative Registration Exchange Types..14
         4.2 De-Registration Exchange....................................15
        5.0 Rekey protocol...............................................15
         5.1 Goals of the Rekey protocol.................................16
         5.2 Rekey messages..............................................17
         5.3 Reliable transport of rekey messages........................17
         5.4 Implosion...................................................18
         5.5  Issues in incorporating group key management algorithms....19
          5.5.1 Stateless vs. stateful rekeying..........................19
         5.6 Interoperability of a GKMA..................................19
        6.0 Group Security Association...................................20
         6.1 Group policy................................................21
         6.2 Contents of the Re-key SA...................................22
          6.2.1 Re-key SA policy.........................................22
          6.2.2 Group identity...........................................22
          6.2.3 Key encrypting key(s)....................................23
          6.2.4 Authentication key.......................................23
          6.2.5 Replay protection information............................23
          6.2.6 Security Parameter Index (SPI)...........................23
         6.3 Contents of the Data SA.....................................23
          6.3.1 Group identity...........................................24
          6.3.2 Source identity..........................................24
          6.3.3 Traffic encrypting key...................................24
          6.3.4 Authentication key.......................................24
          6.3.5 Sequence numbers.........................................24
          6.3.6 Security Parameter Index (SPI)...........................24
          6.3.7 Data SA policy...........................................24
        7.0 Scalability Considerations...................................24
        8.0 Security Considerations......................................27
        9.0 References and Bibliography..................................28
        10.0 Authors' Addresses..........................................31
        Appendix: MSEC Security Documents Roadmap........................32
        Internet Draft    Group Key Management Architecture          [PAGE 2]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
     1.0 Introduction: Purpose of this Document
        Group and multicast applications have diverse requirements in IP
        networks [CP00].  Their key-management requirements, which are
        briefly reviewed below (see "Requirements"), include support for
        internetwork, transport, and application-layer protocols.  In
        particular, while Internet-standard ISAKMP and IKE protocols purport
        to manage keys for any and all services in a host, some applications
        may achieve simpler operation by running key-management messaging
        over TLS or IPsec security services.  Other security protocols may
        benefit from a key management protocol that can run over SIP or RTSP
        [MIKEY].  For these reasons, application, transport, and
        internetwork-layer security protocols such as SRTP, IPsec, and AMESP
        may benefit from using different group key management systems. Some
        security protocols will benefit from a key management protocol that
        can run over IPsec or TLS [GSAKMP].  Other security protocols may run
        over SIP or RTSP [KMMS]. Extensions to IKE may be the best solution
        for running IPsec protocols over IP multicast services [GDOI].  The
        purpose of this document is to define a common architecture and
        design for these different group key-management protocols for
        internet, transport, and application services.
        Indeed, key-management protocols are difficult to design and
        validate.  The common architecture described in this document eases
        this burden by defining common abstractions and 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 [HBH01] and is part of
        the MSEC document roadmap. To correctly place the current document in
        the context of the MSEC literature we include a copy of the MSEC
        draft tree in the appendix.
        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) using the standard keywords of RFC 2119. Section 7
        reviews the scalability issues for group key management protocols and
        Section 8 discusses Security Considerations.
     2.0 Requirements for a group key management protocol
        A group key management protocol supports multicast applications that
        need 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. (Note that group membership
        may vary over time.) A "group key management protocol" helps to
        ensure that only members of a secure group gain access to group data
        Internet Draft    Group Key Management Architecture          [PAGE 3]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        (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
        their secrecy and authenticity requirements.
        Multicast applications, such as video broadcast and multicast file
        transfer, have the following key-management requirements (see also
        1. The group members receive "security associations" including
           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. Keys will have a predetermined lifetime and will be periodically
        3. Key material are delivered securely to members of the
           group so that they are secret, integrity-protected, and can
           be verified as coming from an authorized source.
        4. The key-management protocol is also secure against replay attacks
           and Denial of Service (DoS) attacks (see the Security
           Considerations section of this memo).
        5. The protocol adds and removes group members so that members who
           are added may optionally be denied access to the key material used
           before they joined the group, and that removed members lose access
           to the key material following their departure.
        6. The protocol supports a scalable group re-key operation without
           unicast exchange between members and a group controller/key
           server, which might overwhelm a GCKS when the group is large.
        7. The protocol is compatible with the infrastructure and performance
           needs of the data-security application, such as IPsec security
           protocols, AH and ESP, and/or application-layer security
           protocols, AMESP and SRTP. (Note: needs for further clarification)
        8. The key management protocol offers a framework for replacing or
           renewing transforms, authorization infrastructure and
           authentication systems.
        9. The key management protocol must be secure against collusions
           among excluded members and non-members.  Specifically, collusions
           must not result in gaining any additional group secrets than the
           colluding entities themselves are privy to.
        Internet Draft    Group Key Management Architecture          [PAGE 4]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        10. The key management protocol must provide a mechanism to securely
            recover from a compromise of some or all of the key material.
        Although it is not a requirement for a multicast security protocol,
        the group key management protocol may also be useful to unicast
        applications that share many of the requirements of multicast
        applications.  In other words group key management protocols may be
        used for protecting multicast communications, or communications in
        groups where members communicate among themselves mainly via unicast.
        There are other requirements for small group operation where there
        will be many senders or in which all members may potentially be
        senders.  In this case, the group setup time may need to be optimized
        to support a small, highly interactive group environment [RFC2627].
        A single group controller (or GCKS) may not be the best design for
        small, interactive groups.  However, large single-source multicast
        groups generally may benefit from the use of a specialized GCKS.
        Large distributed simulations, moreover, may combine the need for
        large-group operation with many senders.
        We also take as a requirement the support of large single-sender
        groups, such as source-specific (single-source) multicast groups.
        Thus, group key management should support high-capacity operation to
        large groups that have one or very few senders.  Nonetheless,
        scalable operation to a range of group sizes is a desirable feature,
        and a better group key management protocol will support large,
        single-sender groups as well as groups that have many senders. It may
        be that no single key management protocol can satisfy the scalability
        requirements of all group-security applications.   The group key
        management architecture allows two or more key management protocols,
        where each protocol is suitable to a different scenario such large
        single-source groups or small interactive groups.
        In addition to these requirements, it is useful to emphasize two non-
        requirements, namely, technical protection measures (TPM) and
        broadcast key management.  TPM are used for such things as copy
        protection by preventing the user of a device to get easy access to
        the group keys. Although we should expect that a device under the
        control of an attacker would lose its secrets to that attacker, some
        TPM advocates see tamper-resistant technologies as a means to keep
        honest people honest [MT] and want TPM for that purpose.  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.  The
        group key management architecture described in this document,
        however, is for key management protocols and not a design for
        technical protection measures, which are outside the scope of this
        Internet Draft    Group Key Management Architecture          [PAGE 5]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        The second non-requirement is broadcast key management where there is
        no back channel [FN93, JKKV94] or the device is not on a network,
        such as a digital videodisk player.  We assume IP network operation
        where there is two-way communication, however asymmetric, and that
        authenticated key-exchange procedures can be used for member
        registration.  It is possible that broadcast applications can make
        use of a one-way Internet group key management protocol message, and
        a one-way Re-key message is described below.
     3.0 Overall Design
        This section describes the overall structure of a group key
        management protocol, and provides a reference implementation diagram
        for group key management.  This design is based upon a Ÿgroup
        controller÷ model [RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with
        a single group owner as the root-of-trust.  The group owner
        designates a group controller for member registration and re-key.
     3.1 Overview
        The main goal of a group key management protocol is to securely
        provide the 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
        Security Protocol SA", or "Data SA" for short. In order to obtain
        this goal, the Group Key Management Architecture consists of the
        following protocols.
          (1) Registration protocol.
          This is a two-way unicast protocol between the group controller/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:
            (a) Sufficient information to initialize a "Re-key Protocol SA"
        within the joining member (see more details about this SA  below).
        This information is given only in case that the group security policy
        calls for using a Re-key protocol.
            (b) Sufficient information to initialize the Data Security
        Protocol SA within the joining member. This information is given only
        in the case that the group security policy calls for initializing the
        Data Security Protocol SA at Registration, instead of or in addition
        to at Re-key.
          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
        Internet Draft    Group Key Management Architecture          [PAGE 6]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        "Registration Protocol SA". A complementary "De-registration
        protocol" serves to explicitly remove Registration Protocol SA state.
          (2) Re-key protocol.
          This is an optional protocol where a GCKS periodically sends re-
        key information to the group members. Re-key messages may result from
        group membership changes, the creation of new traffic-protection keys
        (TPKs, see next section) for the particular Group, or from key
        expiration. Re-key messages are protected by the Re-key protocol SA,
        which is initialized in the Registration protocol. The Re-key message
        includes information for updating both the Re-key protocol SA and/or
        the Data Security Protocol SA.  The Re-key messages can be sent via
        multicast to group members or unicast from the GCKS to a particular
        group member.
        The Re-key protocol is optional as there are other means for managing
        (e.g. expiring or refreshing) the keys locally without interaction
        between the GCKS and member [MARKS].  The Re-key SA that is
        established includes authentication data for the re-key.  There are
        two cases.
         o The first and primary option is to use source authentication.
           That is, each group member verifies that Re-key data originates
           with the GCKS and none other.
         o The second option is to use only group-based authentication using
           a symmetric key, such as a message authentication code.  Members
           can only be assured that the Re-key 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 Re-key messages is typically used when public-
           key cryptography is not suitable for the particular group.
        The Re-key protocol ensures that all members receive the re-key
        information in a timely manner. In addition, the Re-key protocol
        specifies mechanisms for the parties to contact the GCKS and "re-
        synch" in case that their keys expired and an updated key has not yet
        been received.  The Re-key protocol for large-scale groups offers
        mechanisms to avoid implosion problems and ensure the needed
        reliability in its delivery of keying material.
        The Re-key message is protected by a Re-key SA, which is established
        by the Registration Protocol.  It is a recommended practice that a
        member who leaves the group destroys the Re-key SA, one or more Data
        SAs, and the Registration SA to which these SAs belong. Use of a De-
        Registration message is often an efficient mechanisms for a member to
        inform the GCKS that it has destroyed it SAs, or is about to destroy
        them.  Such a message may prompt the GCKS to cryptographically
        Internet Draft    Group Key Management Architecture          [PAGE 7]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        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 has the potential to
        cause implosion at the GCKS.
     3.2 Detailed description
        Figure 1 depicts the overall design [HBH01].  Each group member,
        sender or receiver, uses the Registration Protocol to get authorized,
        authenticated access to a particular Group, its policies, and its
        keys. The two types of group keys are the KEK (key-encrypting key)
        and the Traffic Protection Keys or TPKs (TPKs refer to both Traffic
        Encryption Keys or TPKs, and Traffic integrity protection keys).
        The KEK may be a single key that encrypts the TPKs or it may be a
        vector of keys in a group key membership algorithm [RFC2627, OFT,
        CP00, LNN01, SD] that encrypts the TPKs and other KEKs.  The KEK
        is used by the Re-key protocol.  The TPKs are used by the Data
        Security Protocol to protect streams, files, or other data sent
        and received by the Data Security Protocol.  Thus the Registration
        Protocol and/or the Re-key Protocol establish the KEK and TPKs.
         There are a few, distinct outcomes to a successful Registration
        Protocol exchange.
             o If the GCKS uses Re-key messages, then the admitted member
               receives the Group KEK; if it uses a group key management
               algorithm, then the member receives a set of KEKs according
               to the particular algorithm.
             o If Re-key messages are not used for the Group, then the
               admitted member will receive TPKs (in 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 Re-
               key messages are used, for efficiency reasons 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 to the Group member that is
        signed by the Group Owner so the member can check the GCKS's
        authorization.  The GCKS, which may be co-located with a member or be
        a separate physical entity, runs the Re-key Protocol to push Re-key
        messages of refreshed KEKs, new TPKs, and refreshed TPKs to members.
        Alternatively, the sender may forward Re-key messages on behalf of
        the GCKS when it uses a credential mechanism that supports
        delegation. Thus, it is possible for the sender or other member to
        source keying material (TPKs encrypted in the Group KEK) as it
        sources multicast or unicast data.  As mentioned above, the Re-key
        message can be sent using unicast or multicast delivery.  Upon
        Internet Draft    Group Key Management Architecture          [PAGE 8]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        receipt of TPKs from a Re-key Message or a Registration protocol
        exchange, the member's group key management will provide a security
        association (SA) to a Data Security Protocol for the data sent from
        sender to receiver.
        | +-----------------+                          +-----------------+ |
        | |     POLICY      |                          |  AUTHORIZATION  | |
        | | INFRASTRUCTURE  |                          | INFRASTRUCTURE  | |
        | +-----------------+                          +-----------------+ |
        |         ^                                            ^           |
        |         |                                            |           |
        |         v                                            v           |
        | +--------------------------------------------------------------+ |
        | |                                                              | |
        | |                    +--------------------+                    | |
        | |            +------>|        GCKS        |<------+            | |
        | |            |       +--------------------+       |            | |
        | |     REGISTRATION or          |            REGISTRATION or    | |
        | |     DE-REGISTRATION           |           DE-REGISTRATION    | |
        | |         PROTOCOL             |               PROTOCOL        | |
        | |            |                 |                  |            | |
        | |            v               RE-KEY               v            | |
        | |   +-----------------+     PROTOCOL     +-----------------+   | |
        | |   |                 |    (OPTIONAL)    |                 |   | |
        | |   |    SENDER(S)    |<-------+-------->|   RECEIVER(S)   |   | |
        | |   |                 |                  |                 |   | |
        | |   +-----------------+                  +-----------------+   | |
        | |            |                                    ^            | |
        | |            v                                    |            | |
        | |            +-------DATA SECURITY PROTOCOL-------+            | |
        | |                                                              | |
        | +--------------------------------------------------------------+ |
        |                                                                  |
                     FIGURE 1: Group Security Association Model
        The "Security Protocol SA" protects the data sent on the arc labeled
        "DATA SECURITY PROTOCOL" in Figure 1.  A second SA, the "Re-key
        SA," is optionally established by the key-management protocol for Re-
        key messages, and the arc labeled "RE-KEY PROTOCOL" in Figure 1
        depicts this.  The Re-key message is optional because all keys, KEK
        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, symmetric, unicast SA
        between the GCKS and each member; this is called the "Registration
        Protocol SA."  There may be no need for the Registration Protocol SA
        to remain in place after the completion of the Registration Protocol
        exchanges.  The De-registration protocol is also optional and is used
        when explicit teardown or the SA is desirable (such as when a phone
        Internet Draft    Group Key Management Architecture          [PAGE 9]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        call or conference terminates).  The three SAs comprise the Group
        Security Association.  Only one SA is optional and that is the Re-key
        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.
     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 "Re-key Protocol," (2) allowing the Re-key Protocol
        to use unicast push or multicast distribution of group and data keys
        as an option, and (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., 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 unicast push or
        multicast distribution of symmetric group and data keys, and (3)
        supporting key revocation algorithms such as LKH [RFC2627, OFT,
        LNN01] 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 Security 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
        Re-key protocol.
        The design of the Registration and Re-key Protocols is flexible. The
        Registration protocol establishes one KEK or multiple TPKs or both
        KEK and TPKs.  The TPKs (or data keys) are associated with a data
        security protocol SA; there may in fact be multiple keys pushed with
        or derived from the TPKs.  The Re-key Protocol establishes KEKs or
        TPKs or both.
     3.4 Implementation 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 Security Protocol SA, an
        optional Re-key SA, and a Registration Protocol SA.  The GCKS MAY use
        a delegated principal, such as an SRTP [SRTP] sender, which has a
        delegation credential signed by the GCKS.  The "Member" of Figure 2
        Internet Draft    Group Key Management Architecture         [PAGE 10]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        may be a sender or receiver of multicast or unicast data [HCBD].
        There are two functional blocks in Figure 2 labeled "GKM," and there
        are two arcs between them depicting the group key-management
        Registration ("reg") and Re-key ("rek") protocols.  The message
        exchanges are the GSA establishment protocols, which are the
        Registration Protocol and the Re-key Protocol described above.
           |                                                          |
           | +-------------+         +------------+                   |
           | |   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 diagram for a host computer
        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.
        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, which is subject to Group
        Policy [HH], but how this is done is specific to the GCKS
        implementation.  CONTROL may be a telephony signaling protocol such
        Internet Draft    Group Key Management Architecture         [PAGE 11]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        as SIP with the GCKS function operating on a caller's phone.  For
        large-scale multicast sessions, CONTROL could perform session
        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 key (TPKs) establishment to be done in a way that is
        scalable to the particular application.  A GCKS application program
        will use the API to initiate the procedures to establish 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 "Security Protocol" of Figure 2 may span internetwork
        and application layers [AMESP] or operate at the internetwork layer,
        such as AH and ESP.
     4.0 Registration Protocol
        The design of the Registration is flexible. The Registration protocol
        establishes one Rekey SA or multiple Data Security SAs or both.
        The TPKs (or "data key") are associated with a Data Security SA;
        there may in fact be multiple keys pushed with or derived from
        the TPKs. A particular group key management protocol MAY restrict
        these many options according to its particular requirements.
        Each registration protocol supports different 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 GSAKMP [GSAKMP]. However, registration
        protocols that address other scenarios, such as GDOI [GDOI] and
        MIKEY [MIKEY], use other methods to secure SA establishment. Some of
        the different solutions that arise from specific scenarios are
        discussed in the sections below. This document also refers in more
        detail to the specific registration protocols GDOI and MIKEY, and
        shows how these fit within the general architecture.
        Internet Draft    Group Key Management Architecture         [PAGE 12]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
     4.1 Registration Protocol Message Exchange
        Some registration protocols need "tunnel" through a data-signaling
        protocol. The reason may e.g. be 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; we donËt like to wait a second longer than
        we have to. 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 address of the
        callee. A better solution is to tunnel the key exchange procedures
        inside call establishment [H.235, MIKEY] so 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 desirable requirement from RTSP as well.
        The GDOI approach takes advantage of the already defined ISAKMP
        phase 1 exchange [RFC2409], and extends the phase 2 exchange for the
        registration. This is a good example of reusing security
        functionality, where the defined phase 2 exchange is protected by
        the SA created by phase 1. The GDOI will also inherent other
        functionality of the ISAKMP. This may e.g. make the solution very
        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 has
        different tradeoffs. A protocol that provides perfect forward
        secrecy and identity protection trades security for performance or
        efficiency, while a protocol that completes in one or two messages
        may trade security functionality (e.g. identity protection) for
        Internet Draft    Group Key Management Architecture         [PAGE 13]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        In a one- or two-message protocol, replay protection generally uses
        either a timestamp or a sequence number. The first requires
        synchronized clocks, while the latter requires that it is possible
        to keep state. In a timestamp-based protocol, a replay cache is
        needed to store the messages (or the hashes of the messages)
        received within the allowable "clock skew". The size of the replay
        cache depends on the number of messages received during the
        allowable clock skew. During a DoS attack, the replay cache might
        become overloaded. One solution is to over provision the replay
        cache. However, 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 then decreased so that the replay cache becomes manageable.
        A challenge-response mechanism (using Nonce) obviates the need for
        synchronized clocks for replay protection when the exchange uses
        three or more messages [MVV]. This does not guarantee the replay
        protection of individual messages (unless the protocols record all
        Nonce), but on the exchange itself. "Cookies", such as stateless
        cookies are means to protect against the replay of individual
        messages [Photuris].
        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 protocols need external infrastructures to be able
        to handle authentication, replay protection, protocol-run integrity,
        authorization and potentially other security services such as
        secure, synchronized clocks. These may be solved by e.g. deploying a
        PKI (with either authorization-based certificates or a separate
        Internet Draft    Group Key Management Architecture         [PAGE 14]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        management for this). Other existing solutions may be employed such
        as AAA infrastructure. Depending on the registration protocol and
        its application, other external infrastructures may also be needed
        e.g. timestamp-based protocols may need an infrastructure to
        synchronize the clocks.
        However, external infrastructures may not always be needed. This
        could be the case when e.g. pre-shared keys are used and the
        subscription base is very small. In a conversational multimedia
        scenario (e.g. a VoIP call between two or more people), it may very
        well be the end user who handles the authorization by manually
        accepting/rejecting the incoming calls.
        In general, protocols that use fewer messages require more
        infrastructure (such as synchronized clocks) or fewer security
        features such as PFS or identity protection.
     4.2 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 [RFC2543]. 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 uni-directional notification by one side that the GSA
        is to be destroyed.  Authentication of this notification can 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.0 Rekey protocol
        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
        Security 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 Security SA.
        The following are some desirable properties of the Rekey protocol:
          o Rekey protocol ensures that all members receive the rekey
            information in a timely manner.
        Internet Draft    Group Key Management Architecture         [PAGE 15]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
          o Rekey protocol specifies mechanisms for the parties
            involved, to contact the GCKS and re-sync when their keys expire
            and no updates have been received.
          o Rekey protocol avoids implosion problems and ensures the
            needed 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.
     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)
             o efficient rekeying after changes in group membership, or when
               keys (KEKs) expire,
             o (optional) reliable delivery of rekey messages
             o high throughput and low latency, and
             o to use IP Multicast or multi-unicast.
        We identify five major issues in the design of a rekey protocol:
          1. rekey message format
          2. reliable transport of rekey messages
          3. implosion
          4. incorporating GKMAs in rekey messages
          5. interoperability of GKMAs
        Internet Draft    Group Key Management Architecture         [PAGE 16]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        Note that for a GCKS to successfully rekey a group, it is not
        sufficient that Rekey protocol implementations interoperate.  We also
        need to ensure that the GKMA also interoperates.
        In the rest of this section we discuss these issues in detail.
     5.2 Rekey messages
        Rekey messages are at the core of the rekey protocol.  They contain
        Rekey and/or Data Security SAs along with KEKs and TPKs.  These
        messages need to be confidential, authenticated, and protected
        against replay attacks.
        Rekey messages contain group key updates corresponding to a
        single[LKH,OFT] or multiple membership changes[Subset, BatchRekey]
        and often contain group key initialization messages [OFT].
     5.3 Reliable transport of rekey messages
        The GCKS needs to 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 some 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 is
        offline, then it will need to resynchronize its group-key state,
        which probably requires a unicast exchange with the GCKS.  The
        Subset Difference algorithm, however, conveys all needed state in
        its re-key message and does not need members to be always on nor
        always connected.  Subset difference does not require a backchannel
        and can operate on a broadcast network.  Subset difference, however,
        does need to have its key management message received by the member.
        Thus Subset difference, LKH and OFT are not inherently reliable.
        Reliable multicasting is a hard problem, but there are several
        solutions in the literature.  We discuss reliable transport of rekey
        messages in this section.
        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.  Also there are some
        special cases where membership changes are processed as a batch,
        which reduces the frequency of rekey messages, but increases their
        size.  Furthermore, among all the KEKs sent in a rekey message,
        Internet Draft    Group Key Management Architecture         [PAGE 17]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        as many as half the members need only a single KEK.  We need to 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:  Recall that 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.
     5.4 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 security 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 cannot 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
        The implosion problem has been studied extensively in the context of
        reliable multicasting.  Some of the proposed solutions viz., feedback
        suppression and aggregation, might be useful in this context as well.
        The GCKS might send each receiver a random number to be used as time
        to wait before sending a NACK or out-of-sync message.  Meanwhile,
        members might receive the key updates they need and therefore will
        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 results in
        repetition of the registration process for those members.
        Furthermore, there is the need to setup multiple registration servers
        and synchronize them.
        Internet Draft    Group Key Management Architecture         [PAGE 18]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        Feedback aggregation and local recovery employed by some reliable
        multicast protocols are not easily adaptable to transport of rekey
        messages.  There are authentication issues to address in aggregation.
        Local recovery is more complex in that members need to establish SAs
        with the local repair server.
     5.5  Issues in incorporating group key management algorithms
        Group key management algorithms make re-keying scalable. Large group
        re-keying without employing GKMAs is prohibitively expensive.
        First we list some requirements to consider in selecting a GKMA:
          o Collusion:  Members (or non members) should not be able to
            collaborate to deduce keys that they are not privileged
           (following the GKMA key distribution rules) to.
          o Forward access control: Ensure that departing members cannot get
            access to future group data.
          o Backward access control:  Ensure that joining members cannot
            decrypt past data.
     5.5.1 Stateless vs. stateful rekeying
        We classify group key management algorithms into two categories,
        viz., stateful and stateless algorithms.
        Stateful algorithms use KEKs from the ith rekeying instance to
        encrypt (protect) KEKS corresponding to the i+1st rekeying instance.
        The main disadvantage in these schemes is that if a member was
        offline or otherwise fails to receive KEKs from a rekeying instance
        i, it can no longer synchronize its GSA even though it can receive
        KEKs from all future rekeying instances starting at i+1.  The only
        solution is to contact the GCKS 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 encrypt rekey messages with KEKs sent during the
        registration protocol.  Since rekey messages are independent of any
        past rekey messages (i.e. not protected by KEKs therein), a member
        may go offline, but continue to be able to decipher future
        communications.  The catch however is that members can never decrypt
        any messages sent while they were offline, even though there are
        eligible to (i.e. paid for that content as well).  Stateless rekeying
        may be relatively inefficient, particularly for immediate (in
        contrast to batch) rekeying in highly dynamic groups.
        Internet Draft    Group Key Management Architecture         [PAGE 19]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
     5.6 Interoperability of a GKMA
        Most GKMA specifications do not specify packet formats although any
        group key management algorithms needs to for the purposes of
        interoperability.  In particular there are several alternative ways
        to managing key trees and numbering nodes within key trees.  The
        following information is generally 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
             - encryption key's ID (optional)
        Key IDs may change in some implementations in which case we need to
          o  List of <old id, new id>
     6.0 Group Security Association
        The GKM Architecture defines the interfaces between the Registration,
        Re-key, and Data Security protocols in terms of the Security
        Associations (SAs) of those protocols.  By isolating these protocols
        behind a uniform interface, our architecture allows implementations
        to use protocols best suited to their needs.  For example, a Re-key
        protocol for a small group could use multiple unicast transmissions
        with symmetric authentication, while that for a large group could use
        IP Multicast with packet-level Forward Error Correction and source
        The Group Key Management Architecture provides an interface between
        the security protocols and the group SA (GSA), which consists of
        three SAs, viz., Registration SA, Re-key SA and Data SA.  The Re-key
        Internet Draft    Group Key Management Architecture         [PAGE 20]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        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.
        In Case 1, Group key management is done WITHOUT using a Re-key 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 “ and a group may have more than one
        data SA.
        In Case 2, group key management USES a Re-key SA to protect the Re-
        key protocol. The Registration protocol initializes the Re-key SAs
        (one or more) as well as zero or more Data SAs upon successful
        completion.  When a Data SA is not initialized in the Registration
        protocol, this is done in the Re-key protocol.  The Re-key protocol
        updates Re-key SA(s) AND establishes Data SA(s).
     6.1 Group policy
        Group-policy is currently being defined [GSPT].  It can be
        distributed through announcement, key management protocols, and other
        means.  The group key management carries cryptographic policies of
        the SA keys it establishes as well as additional policies for the
        group as well.
        The acceptable cryptographic policies for the Registration Protocol,
        which may run over 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 key-management session
        establishment to determine what the initial cryptographic policies
        are 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.
        This memo assumes that at least the following group-policy
        information is externally managed.
          o Group owner, authentication method, and delegation method for
            identifying a GCKS for the group
          o Group GCKS, authentication method, and any method used for
            delegating other GCKSs for the group
          o Group membership rules or list and authentication method
        There are also two additional policy-related requirements external to
        group key management.
          o There is an authorization and authentication infrastructure such
            as X.509, SPKI, or pre-shared key scheme in accordance with the
            group policy for a particular group.
        Internet Draft    Group Key Management Architecture         [PAGE 21]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
          o There is an announcement mechanism for secure groups and events
            that operates according to group policy for a particular group.
        Group policy determines how the Registration and Re-key protocols
        initialize or update Re-key and Data SAs.  The following sections
        describe the information that is sent by the GCKS for the Re-key and
        Data SAs.  A member needs to have the information specified in the
        next sections to establish Re-key and Data SAs.
     6.2 Contents of the Re-key SA
        The Re-key SA protects the Re-key protocol.  It contains
        cryptographic policy, Security Parameter Index (SPI) [RFC2401] to
        uniquely identify an SA, replay protection information, and secret
     6.2.1 Re-key SA policy
        The MEMBERSHIP MANAGEMENT ALGORITHM 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, CP00, LNN01].  The key
        revocation algorithm could also be NULL.  In that case, the Re-key SA
        contains only one KEK, which serves as the group KEK.  The Re-key
        messages initialize or update Data SAs as usual.  But, the Re-key SA
        itself can be updated (group KEK can be re-keyed) when members join
        or the KEK is about to expire.  Leave re-keying is done by re-
        initializing the Re-key SA through the Re-key Protocol.
        The KEK ENCRYPTION ALGORITHM uses a standard encryption algorithm
        such as 3DES or AES.  The KEK KEY LENGTH is also specified.
        The AUTHENTICATION 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 be specified.
        The CONTROL GROUP ADDRESS is used for multicast transmission of Re-
        key 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
        The REKEY SERVER ADDRESS allows the registration server to be a
        different entity from the server used for re-key, such as for future
        invocations of the Registration and Re-key protocols.  If the
        registration server and the re-key server are two different entities,
        the registration server sends the re-key server's address as part of
        the Re-key SA.
     6.2.2 Group identity
        Internet Draft    Group Key Management Architecture         [PAGE 22]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        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
        Re-key message.  It is often much simpler to restrict each
        Registration invocation to a single group, this Group Key Management
        Architecture mandates no such restriction.  There is always a need to
        identify the group when establishing a Re-key SA either implicitly
        through an SPI or explicitly as an SA parameter.
     6.2.3 Key encrypting key(s)
        Corresponding to the key management algorithm, the Re-key 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
        Re-key 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 being pushed
        from the GCKS.
     6.2.5 Replay protection information
        Re-key messages need to be protected from replay/reflection attacks.
        Sequence numbers are used for this purpose and the Re-key SA (or
        protocol) contains this information.
     6.2.6 Security Parameter Index (SPI)
        The triple (Group identity, SPI, an identifier for "Re-key SA")
        uniquely identifies an SA.  The SPI changes each time the KEKs
     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
        Internet Draft    Group Key Management Architecture         [PAGE 23]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        of Data Security protocols include IPsec ESP, SRTP, MESP, and AMESP.
        While the content of each of these protocols is out of the scope of
        this document, we list the information sent by the Registration
        protocol (or the Re-key Protocol) to initialize or update the Data
     6.3.1 Group identity
        The Group identity accompanies SA information when Data SAs are
        initialized or re-keyed for multiple groups in a single invocation of
        the Registration protocol or in a single Re-key message (see 4.2.2).
     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 announcement protocol is only appropriate when
        there is no need to protect source or group identities.
     6.3.3 Traffic protection keys
        Irrespective of the Data Security Protocol used, the GCKS supplies
        the TPKs (or information to derive TPKs) used in secure data
        transmission, source and group authentication.
     6.3.4 Authentication key
        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), or other parameters used for authenticating streams or
     6.3.5 Sequence numbers
        The GCKS passes sequence numbers when needed by the Data Security
        protocol, for replay protection.
     6.3.6 Security Parameter Index (SPI)
        The GCKS sends provides 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.
        Internet Draft    Group Key Management Architecture         [PAGE 24]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        Generally, specification of source or group authentication is
        mutually exclusive.
     7.0 Scalability Considerations
        Group communications is quite diverse.  In commercial
        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 [RFC 1889] has no central controller but is
        fully distributed and end-to-end.  Teleconferencing sessions tend to
        have at most dozens of participants whereas video broadcast, which
        uses multicast communications, and media on demand, which uses
        unicast, are large-scale groups numbering hundreds to millions of
        As described in the Requirements section above, the group key
        management architecture supports source-specific multicast.  One-to-
        many (single-sender) applications are well suited to source-specific
        multicast, which tend to have large numbers of participants and
        problems with synchronization among the participants.  ŸFlash crowds÷
        are one manifestation of the problem with synchronized participants
        who make concurrent request for group data with concomitant requests
        for secure group keys.  Thus, a group key management protocol
        designed for single-source multicast applications must support large-
        scale operation.  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 Re-key protocol.
        2. The Registration and Re-key protocols are separable to allow
        flexibility in how members get group secrets.  A group can use a
        smart-card based system in place of the Registration protocol, for
        example, to allow the Re-key protocol to be used with no back channel
        for broadcast applications such as television conditional access
        3. The Registration and Re-key protocols support new keys,
        algorithms, authorization infrastructures and authentication
        mechanisms in the architecture.  When the authorization
        infrastructure supports delegation, as does X.509 and SPKI, the GCKS
        function can be distributed as shown in Figure 3.
        Internet Draft    Group Key Management Architecture         [PAGE 25]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
                     |       +-------+                        |
                     |       |  GCKS |                        |
                     |       +-------+                        |
                     |         |   ^                          |
                     |         |   |                          |
                     |         |   +---------------+          |
                     |         |       ^           ^          |
                     |         |       |    ...    |          |
                     |         |   +--------+  +--------+     |
                     |         |   | MEMBER |  | MEMBER |     |
                     |         |   +--------+  +--------+     |
                     |         v                              |
                     |         +-------------+                |
                     |         |             |                |
                     |         v      ...    v                |
                     |     +-------+   +-------+              |
                     |     |  GCKS |   |  GCKS |              |
                     |     +-------+   +-------+              |
                     |         |   ^                          |
                     |         |   |                          |
                     |         |   +---------------+          |
                     |         |       ^           ^          |
                     |         |       |    ...    |          |
                     |         |   +--------+  +--------+     |
                     |         |   | MEMBER |  | MEMBER |     |
                     |         |   +--------+  +--------+     |
                     |         v                              |
                     |        ...                             |
                 Figure 3: Hierarchically-organized Key Distribution
        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 recourse
        for handling member registration in the context of a Ÿflash crowd÷ is
        Figure 3, which will require the use of many GCKSs to accommodate the
        load.  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-
        distribution networks, however, the configuration shown in Figure 3
        has additional security ramifications for physical security of a
        More analysis and work needs to be done on the protocol
        instantiations of the Group Key Management architecture to determine
        how effectively and securely the architecture can operate in large-
        scale environments such as source-specific multicast and video on
        Internet Draft    Group Key Management Architecture         [PAGE 26]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        demand.  Specifically, the requirements for a Figure 3 configuration
        must be determined such as the need for additional protocols between
        the GCKS designated by the Group Owner and GCKSs that have been
        delegated to serve keys on behalf of the designated GCKS.
     8.0 Security Considerations
        This memo describes an architecture for group key management.  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
        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 an implementation
        of 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.
        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:
        Whereas peer-to-peer security policy is an intersection of the policy
        of the individual peers, a Group Owner sets group security policy
        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 trust, authenticity and confidentiality when
        joining secure groups.
        Internet Draft    Group Key Management Architecture         [PAGE 27]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        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 Re-key protocol, is new
        and has unknown risks associated with it.  The source-authentication
        risks describe 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 Re-key protocol
        specification (see Appendix A for the drafts roadmap) needs to offer
        secure solutions to these problems.  Each instantiation of the Re-key
        protocol, such as the GSAKMP Re-key or the GDOI Groupkey-push
        operations, need to validate the security of their Re-key
        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-
        articulate standard for security and risks of group key management.
     9.0 References and Bibliography
        [AMESP] R. Canetti, P. Rohatgi, Pau-Chen Cheng, Multicast Data
        Security Transformations: Requirements, Considerations, and Prominent
        Choices, http://search.ietf.org/internet-drafts/draft-irtf-smug-data-
        transforms.txt, Work In Progress, 2000.
        [CP00] R. Canetti, B. Pinkas, A taxonomy of multicast security
        issues, http://www.ietf.org/internet-drafts/draft-irtf-smug-
        taxonomy-01.txt, Work in Progress, August 2000.
        [FN93]A. Fiat, M. Naor, Broadcast Encryption, Advances in Cryptology
        - CRYPTO Ë93 Proceedings, Lecture Notes in Computer Science, Vol.
        773, 1994, pp. 480“491.
        [FS00] N. Ferguson and B. Schneier, A Cryptographic Evaluation of
        IPsec, CounterPane, http://www.counterpane.com/ipsec.html.
        [GDOI] M. Baugher, T. Hardjono, H. Harney, B. Weis, The Group Domain
        of Interpretation, http://www.ietf.org/internet-drafts/draft-ietf-
        msec-gdoi-00.txt, February 2001, Work in Progress.
        Internet Draft    Group Key Management Architecture         [PAGE 28]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        [GSAKMP] H.Harney, A.Colegrove, E.Harder, U.Meth, R.Fleischer, Group
        Secure Association Key Management Protocol,
        00.txt, March 2001, Work in Progress.
        [H.235] ITU, Security and encryption for H-Series (H.323 and other
        H.245-based) multimedia terminals, ITU-T Recommendation H.235 Version
        3, 2001, Work in progress.
        [JKKV94] M. Just, E. Kranakis, D. Krizanc, P. van Oorschot, On Key
        Distribution via True Broadcasting, On Key Distribution via True
        Broadcasting. In Proceedings of 2nd ACM Conference on Computer and
        Communications Security, November 1994, pp. 81--88.
        [MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K.
        Norrman, "MIKEY: Multimedia Internet KEYing", Internet Draft, IETF,
        Work in progress.
        [MARKS] B. Briscoe, MARKS: Zero Side Effect Multicast Key Management
        using Arbitrarily Revealed Key Sequences, Proceedings of NGC'99,
        [MT] D.S. Marks, B.H. 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
        [MVV] A.J.Menzes, P.C.van Oorschot, S.A. Vanstone, Handbook of
        Applied Cryptography, CRC Press, 1996.
        [OFT] D. Balenson, D. McGrew, A. Sherman, Key Management for Large
        Dynamic Groups: One-Way Function Trees and Amortized Initialization,
        00.txt, February 1999, Work in Progress.
        [RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP:
        A Transport Protocol for Real-Time Applications, January 1996.
        [RFC2093] Harney, H., and Muckenhirn, C., "Group Key Management
        Protocol (GKMP) Specification," RFC 2093, July 1997.
        [RFC2094] Harney, H., and Muckenhirn, C., "Group Key Management
        Protocol (GKMP) Architecture," RFC 2094, July 1997.
        [RFC2326] ftp://ftp.isi.edu/in-notes/rfc2326.txt
        Internet Draft    Group Key Management Architecture         [PAGE 29]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
        [RFC2327] M. Handley, V. Jacobson, SDP: Session Description
        Protocol, April 1998.
        [RFC2367] D. McDonald, C. Metz, B. Phan, PF_KEY Key Management API,
        Version 2, July 1998.
        [RFC2401] S. Kent, R. Atkinson, Security Architecture for the
        Internet Protocol, November 1998
        [RFC2406] S. Kent, R. Atkinson, IP Encapsulating Security Payload
        (ESP), November 1998.
        [RFC2407] D. Piper, The Internet IP Domain of Interpretation for
        ISAKMP, November 1998.
        [RFC2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, Internet
        Security Association and Key Management Protocol, November 1998.
        [RFC2409] D. Harkins, D. Carrel, The Internet Key Exchange (IKE),
        November, 1998.
        [RFC2412] H. Orman, The OAKLEY Key Determination Protocol, November
        [RFC2522] P. Karn, W. Simpson, Photuris: Session-Key Management
        Protocol, March 1999.
        [RFC2543] ftp://ftp.isi.edu/in-notes/rfc2543.txt
        [RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for
        Multicast: Issues and Architectures, September 1998.
        [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. J. Wiener, Authentication and
        Authenticated Key Exchanges, Designs, Codes and Cryptography, 2,
        107-125 (1992), Kluwer Academic Publishers.
        [SRTP] R.Blom, E.Carrara, D.McGrew, M.Nasland, K.Norrman, D. Oran,
        The Secure Real Time Transport Protocol,
        February 2001, Work in Progress.
        Internet Draft    Group Key Management Architecture         [PAGE 30]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
     10.0 Authors' Addresses
        Mark Baugher
        Cisco Systems
        5510 SW Orchid St.
        Portland, OR  97219, USA
        +1 408-853-4418
        Ran Canetti
        IBM Research
        30 Saw Mill River Road
        Hawthorne, NY 10532, USA
        +1 914-784-7076
        Lakshminath R. Dondeti
        Nortel Networks
        600 Technology Park Drive
        Billerica, MA 01821, USA
        +1 978-288-6406
        Fredrik Lindholm
        Ericsson Research
        SE-16480 Stockholm, Sweden
        +46 8 58531705
        Internet Draft    Group Key Management Architecture         [PAGE 31]

       Baugher, Canetti, Dondeti, Lindholm                       February 2002
     Appendix: MSEC Security Documents Roadmap
                                 |     MSEC     |
                                 | Requirements |
                                 |     MSEC     |
                                 | Architecture |
                    :                    :                      :
            +--------------+     +--------------+      +--------------+
            |    Policy    |     |     GKM      |      | Data Security|
            | Architecture |     | Architecture |      | Architecture |
            +--------------+     +--------------+      +--------------+
                           :                    :                     :
                           :                    :                     :
                           .     +------------+ :      +------------+ :
                           .     |  GDOI      | :      |TESLA/MESP  | :
                                 | Resolution |-:      |            |-:
                                 |            | :      |            | :
                                 +------------+ :      +------------+ :
                                                :                     :
                                                :                     :
                                 +------------+ :      +------------+ :
                                 | GSAKMP-    | :      |            | :
                                 | Resolution |-:      |    TBD     |-:
                                 |            | :      |            | :
                                 +------------+ :      +------------+ :
                                                :                     :
                                                :                     :
                                 +------------+ :      +------------+ :
                                 |            | :      |            | :
                                 |   RE-KEY   |-:      |    TBD     |-:
                                 |            | :      |            | :
                                 +------------+ :      +------------+ :
                                                :                     :
                                                .                     .
                                                .                     .
        FIGURE A: Graphic rendition of the inter-relations between the I-D's
        of MSEC. Note that some of these drafts are still in the process of
        being written.
        Internet Draft    Group Key Management Architecture         [PAGE 32]

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