Internet Engineering Task Force Mark Baugher (Cisco) INTERNET-DRAFT Ran Canetti (IBM) Lakshminath Dondeti (Nortel) June 23, 2001 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 Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract 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. Table of Contents 1.0 Introduction: Purpose of this Document....................3 2.0 Requirements for a group key management protocol..........3 3.0 Overall Design............................................5 3.1 Overview..............................................6 3.2 Detailed description..................................7 3.3 Properties of the design..............................9 3.4 Implementation Diagram...............................10 4.0 Group Security Association...............................11 4.1 Pre-distributed group policy.........................12 4.2 Contents of the Re-key SA............................12 4.3 Contents of the Data Security SA.....................14 5.0 Scalability Considerations...............................15 6.0 Security Considerations..................................17 7.0 References and Bibliography..............................18 8.0 Authors' Addresses.......................................21 Appendix: MSEC Security Documents Roadmap....................22 Baugher, Canetti, Dondeti [Page 2] Internet Draft Group Key Management Architecture June 2001 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. 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. Extensions to IKE, however, are probably the best solution for 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. 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 specialize for different uses. This document builds on and extends the Group Key Management Building Block document of the IRTF SMuG research group [HBH01]. 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. Section 4 outlines the structure of the Group Security Association (GSA). Section 5 discusses scalability issues and Section 6 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" ensures that only members of a secure group 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 their secrecy and authenticity requirements. Multicast applications, such as video broadcast and multicast file transfer, have the following key-management requirements (see also [CP00]). Baugher, Canetti, Dondeti [Page 3] Internet Draft Group Key Management Architecture June 2001 1. The group members must receive "security associations" including encryption keys, authentication/integrity keys, metadata describing the keys (also called "policy") and attributes such as an index for referencing the security association. 2. Keys will have a predetermined lifetime and will be periodically refreshed. 3. Key material must be delivered securely to members of the group so that they are secret and authenticated to group members during the key lifetime and refreshed securely at the end of the key lifetime. 4. The key-management protocol must be secure against man-in-the- middle, connection-hijacking, and reflection/replay attacks; it must use best-known practices to thwart denial-of-service attacks. 5. It must be possible to add and remove 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 members who are removed lose access to the key material following their departure. 6. It must be possible to provide re-key for the group without requiring unicast exchange between a key distribution center (KDC) and individual members, which would overwhelm a KDC when the group is large. 7. The key management protocol must be suitable for IPsec security protocols, AH and ESP, and/or application-layer security protocols such as AMESP and SRTP. 8. The key management protocol should allow keys and algorithms to be renewed and the trust infrastructure and authentication systems to be replaced. 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, such as for Internet entertainment applications that exhibit a high degree of synchronization among receivers. For example, consider a video on demand application scenario where the top 10 movie are offered. On a Friday night, a large population of users is likely to request any one of the small set of movies (files or streams) and place great demand on the KDC for keys to the pre-encrypted data. If asymmetric cryptography is used to establish security associations as is done in TLS or IKE, the KDC will probably not be able to exceed 20- 60 key management sessions per second (on a 500 MHz Pentium-class server with RSA, DSS, or EC-DSS keys ranging from about 160 to 1024 bits in length). If the video-on-demand community of users is modeled as a group, however, then a key management implementation that supports requirement 6, above, will satisfy the requirements of the VOD application as well. There are other requirements for small group operation where there wil 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 centralized Baugher, Canetti, Dondeti [Page 4] Internet Draft Group Key Management Architecture June 2001 group controller (or KDC) that is used in this architecture may not be the best design for small, interactive groups. But for large, single- source multicast groups, it is generally undesirable to distribute key management functions among group members: Unlike small, interactive groups, large single-source multicast groups generally need a specialized KDC to support large numbers of group members. Large distributed simulations, moreover, may combine the need for large-grou operation with many senders. We take as a basic 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. This is for further study. In addition to these requirements, it is useful to emphasize two non- requirements, namely, technical protection measures (TPM) and broadcas 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 document. 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 DVD CSS [Stevenson]. 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 an Internet group key management protocol message that is one-way, 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 key distribution center for member registration and re-key. Baugher, Canetti, Dondeti [Page 5] Internet Draft Group Key Management Architecture June 2001 3.1 Overview The main goal of a group key management protocol is to 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 key distribution center (KDC) and a joining group member. In this protocol the KDC and joining member mutually authenticate each other. If the authentication succeeds and the KDC finds that the joining member is authorized, then the KDC 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 when 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 KDC to member is done in a authenticated and confidential manner over a security association. We call this SA the "Registration Protocol SA". (2) Re-key protocol. ================ This is an optional protocol where the KDC periodically sends re-key information to the group members. Re-key messages may result from group membership changes 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 multicast to group members or unicast from the KDC 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 KDC and member [MARKS]. When Re-key is used, it MUST include 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 MUST verify that Re-key data originates with the GCKS and none other. Baugher, Canetti, Dondeti [Page 6] Internet Draft Group Key Management Architecture June 2001 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 KDC. Group authentication for Re-key messages is typically used when public- key cryptography is not suitable for the particular group. The Re-key protocol SHOULD ensure that all members receive the re-key information in a timely manner. In addition, the Re-key protocol SHOULD specify mechanisms for the parties to contact the KDC and "re-synch" in case that their keys expired and an updated key has not yet been received. The Re-key protocol must avoid implosion problems and ensure the needed reliability in its delivery of keying material. 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 TEK (traffic-encrypting key). The KEK may be a single key that encrypts the TEK or it may be a vector of keys in a membership management algorithm [RFC2627, OFT, CP00] that encrypts the TEK and other KEKs. The KEK is used by the Re-key protocol. The TEK is used by the Data Security Protocol to protect streams, files, or other data sent and received by the Data Security Protocol. The Registration Protocol and/or the Re-key Protocol establish the KEK and TEK. There are a few, distinct outcomes to a successful Registration Protocol exchange. o If the KDC uses Re-key messages, then the admitted member receives the Group KEK; if it uses a membership 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 TEKs (in SAs) that are passed to the member's Data Security Protocol as IKE does for IPsec. o The KDC may pass one or more TEKS to the member even if Re-key messages are used, for efficiency reasons according to group policy. Baugher, Canetti, Dondeti [Page 7] Internet Draft Group Key Management Architecture June 2001 +------------------------------------------------------------------+ | +-----------------+ +-----------------+ | | | POLICY | | TRUST | | | | INFRASTRUCTURE | | INFRASTRUCTURE | | | +-----------------+ +-----------------+ | | ^ ^ | | | | | | v v | | +--------------------------------------------------------------+ | | | | | | | +--------------------+ | | | | +------>| KDC |<------+ | | | | | +--------------------+ | | | | | | | | | | | | REGISTRATION | REGISTRATION | | | | PROTOCOL | PROTOCOL | | | | | | | | | | | v RE-KEY v | | | | +-----------------+ PROTOCOL +-----------------+ | | | | | | | | | | | | | | SENDER(S) |<-------+-------->| RECEIVER(S) | | | | | | | | | | | | | +-----------------+ +-----------------+ | | | | | ^ | | | | v | | | | | +-------DATA SECURITY PROTOCOL-------+ | | | | | | | +--------------------------------------------------------------+ | | | +------------------------------------------------------------------+ FIGURE 1: Group Security Association Model The KDC creates the KEK and TEKs and downloads them to each member - as the KEK and TEKs are common to the entire Group. The KDC is a separate, logical entity that performs member authentication and authorization according to the Group policy that is set by the Group Owner. The KDC presents a credential to the Group member that is signed by the Group Owner so the member can check the KDC's authorization. The KDC, 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 TEKs, and refreshed TEKs to members. Alternatively, the sender may forward Re-key messages on behalf of the KDC when it uses a credential mechanism that supports delegation. Thus, the sender or other member may source keying material (a TEK 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 receipt of a TEK 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. Baugher, Canetti, Dondeti [Page 8] Internet Draft Group Key Management Architecture June 2001 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 TEKs, can be delivered by the Registration Protocol exchanges shown in Figure 1. The Registration Protocol is protected by a third, symmetric, unicast SA between the KDC 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 three SAs comprise the Group Security Association. Only one SA is optional and that is the Re-key SA. Figure 1 shows two blocks that are external to the group key management protocol: The Policy and Trust Infrastructures are discussed in Section 4.1. 3.3 Properties of the design The above design 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. The KDC, moreover, can be delegated when the trust infrastructure supports delegation to permit distributed operation of the KDC. High-capacity operation is obtained by (1) amortizing computationally- expensive asymmetric cryptography over multiple data keys used by a data security protocol, (2) supporting unicast push or multicast distribution of symmetric group and data keys, and (3) supporting membership management algorithms such as LKH [RFC2627, OFT]. The Registration protocol uses 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 TEK SA can be established without the use of asymmetric cryptography - the TEK is 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 TEKs or both KEK and TEKs. The Re-key Protocol establishes KEKs or TEKs or both. The complexity of the various options can be reduced by an instantiation of the group key management architecture that disallows or restricts the options described here. Baugher, Canetti, Dondeti [Page 9] Internet Draft Group Key Management Architecture June 2001 3.4 Implementation Diagram In the block diagram of Figure 2, group key management protocols run between a KDC and member principals to establish a Group Security Association (GSA) consisting of a Security Protocol SA, an optional Re- key SA, and a Registration Protocol SA. The KDC may use a delegated principal, such as an SRTP [SRTP] sender, which has a delegation credential signed by the KDC. The "Member" of Figure 2 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. +----------------------------------------------------------+ | | | +-------------+ +------------+ | | |AUTHORIZATION| |ANNOUNCEMENT| | | +------^------+ +------|-----+ +--------+ | | | | +-----| CERTS | | | | | | +--------+ | | +----v----+ +----v--v-+ +--------+ | | | <-----Reg-----> |<->| SAD | | | | GKM -----Rek-----> GKM | +--------+ | | | | | | +--------+ | | | ------+ | |<->| SPD | | | +---------+ | +-^-------+ +--------+ | | +--------+ | | | | | | | CERTS |----->+ | | +-------------------+ | | +--------+ | | +--------------------+ | | | +--------+ | +-V-------+ +--------+ | | | | | SAD <----->+ | |<->| SAD <-+ | | | +--------+ | |SECURITY | +--------+ | | | +--------+ | |PROTOCOL | +--------+ | | | | SPD <----->+ | |<->| SPD <----+ | | +--------+ +---------+ +--------+ | | | | (A) KDC (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, "CERTS" in Figure 2. AUTHORIZATION is subject to Group Policy [HH], but how this is done is specific to the KDC implementation. Baugher, Canetti, Dondeti [Page 10] Internet Draft Group Key Management Architecture June 2001 Beside the AUTHORIZATION block in Figure 2, there is an ANNOUNCEMENT block. The announcement function is needed to inform a potential group member that it may join a group or upcoming group sessions (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 sessions. 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, or by other means. The Data Security or announcement function directs GDOI 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 Session (TEK) key establishment to be done in a way that is scalable to the particular application. A KDC 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 a 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 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 authentication. 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 Security SA. The Re-key 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 Security SAs (having TEKs to protect files or streams). Each Data Security SA corresponds to a single group. In Case 2, group key management USES a Re-key SA to protect the Re-key Baugher, Canetti, Dondeti [Page 11] Internet Draft Group Key Management Architecture June 2001 protocol. The Registration protocol initializes the Re-key SAs (one or more) as well as zero or more Data Security SAs upon successful completion. When a Data Security SA is not initialized in the Registration protocol, this is done in the Re-key protocol. The Re-key protocol is responsible for updates to Re-key SA(s) AND updates as well as initialization of Data Security SA(s). 4.1 Pre-distributed group policy 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 KDC and member policy queries. Thus group security policy will be represented in a policy repository and accessible using a policy protocol. MSEC assumes that at least the following group-policy information is externally managed. o Group owner, authentication method, and delegation method for identifying a KDC for the group o Group KDC, authentication method, and any method used for delegating other KDCs 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. 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 Security SAs. The following sections describe the information that are sent by the KDC for the Re- key and Data Security SAs. A member needs to have the information specified in the next sections to establish Re-key and Data Security SAs. 4.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 keys. Baugher, Canetti, Dondeti [Page 12] Internet Draft Group Key Management Architecture June 2001 4.2.1 Re-key SA policy The KEY MANAGEMENT ALGORITHM represents the group key management algorithm that enforces forward and backward access control. Examples of key management algorithms include LKH, LKH+, OFT, and OFC [RFC2627, OFT, CP00]. The key management 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 Security 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 must also be specified. The AUTHENTICATION ALGORITHM should use digital signatures for KDC authentication (since all shared secrets are known to some or all members of the group), or it may use a symmetric secret in computing MACs for group authentication. The AUTHENTICATION KEY LENGTH must also be specified. The CONTROL GROUP ADDRESS is used for multicast transmission of Re-key messages. This may be sent via the ANNOUNCEMENT protocol. However, the Group Owner may decide to send this information only to authorized members. 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 needs to send the re-key server's address as part of the Re-key SA. 4.2.2 Group identity The Group identity may need to accompany 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. While it may be 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. 4.2.3 Key encrypting key(s) Corresponding to the key management algorithm, the Re-key SA contains one or more KEKs. The KDC holds the key encrypting keys of the group, while the members receive keys following the specification of the key- Baugher, Canetti, Dondeti [Page 13] Internet Draft Group Key Management Architecture June 2001 management algorithm. When there are multiple KEKs for a group (as in an LKH tree), each KEK is associated with a Key ID, which may be used to identify the key needed to decrypt it. Each KEK also has a LIFETIME associated with it, after which the KEK expires. 4.2.4 Authentication key The KDC may provide 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 KDC. The architecture does not rule out methods for deriving symmetric authentication keys at the member [RFC2409] rather than being pushed from the KDC. 4.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. 4.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 change. 4.3 Contents of the Data Security SA The KDC 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, 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 Security SA. 4.3.1 Group identity The Group identity must accompany SA information when Data Security 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). Otherwise, there is also a need for some means to identify the group in a protocol that establishes a Data Security SA either implicitly through an SPI or explicitly as an SA parameter. 4.3.2 Source identity The Group Owner may choose to reveal Source identity to authorized members only. Alternatively, it may choose the ANNOUNCEMENT protocol to list the Source(s) corresponding to the Source identities. Baugher, Canetti, Dondeti [Page 14] Internet Draft Group Key Management Architecture June 2001 4.3.3 Traffic encrypting key Irrespective of the Data Security Protocol used, the KDC supplies the TEKs (or information to TEKs) used in secure data transmission, source and group authentication. 4.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, or other parameters used for authenticating streams or files. 4.3.5 Sequence numbers The KDC could initialize sequence numbers used by the Data Security protocol, for replay protection. 4.3.6 Security Parameter Index (SPI) In the event that a Data Security protocol uses an SPI, the KDC will send that information as part of the Data Security SA contents. 4.3.7 Data Security SA policy The Data Security SA parameters are specific to the Data Security Protocol but will usually include encryption algorithm and parameters, the source authentication algorithm and parameters, the group authentication algorithm and parameters, and replay protection information. Generally, specification of source or group authentication is mutually exclusive. 5.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 participants. As described in the Requirements section above, group key management must support source-specific multicast, first and foremost. One-to- many 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 request group data with concomitant requests for secure group keys. Thus, a group key management protocol designed for single-source multicast Baugher, Canetti, Dondeti [Page 15] Internet Draft Group Key Management Architecture June 2001 applications must support large-scale operation. The architecture described in this paper supports large-scale operation through the following features. 1. No unicast exchange is needed to provide data keys to a security protocol for members who have previously-registered in the particular group; data security 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 systems. 3. The Registration and Re-key protocols should support new keys, algorithms, trust infrastructures and authentication mechanisms in the architecture. When the trust infrastructure supports delegation, as does X.509 and SPKI, the KDC function can be distributed as shown in Figure 3. +----------------------------------------+ | +-------+ | | | KDC | | | +-------+ | | | ^ | | | | | | | +---------------+ | | | ^ ^ | | | | ... | | | | +--------+ +--------+ | | | | MEMBER | | MEMBER | | | | +--------+ +--------+ | | v | | +-------------+ | | | | | | v ... v | | +-------+ +-------+ | | | KDC | | KDC | | | +-------+ +-------+ | | | ^ | | | | | | | +---------------+ | | | ^ ^ | | | | ... | | | | +--------+ +--------+ | | | | MEMBER | | MEMBER | | | | +--------+ +--------+ | | v | | ... | +----------------------------------------+ Figure 3: Hierarchically-organized Key Distribution Baugher, Canetti, Dondeti [Page 16] Internet Draft Group Key Management Architecture June 2001 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 KDCs to accommodate the load. The Figure 3 configuration may be needed when conventional clustering and load-balancing solutions of a central KDC 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 KDC. 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 demand. Specifically, the requirements for a Figure 3 configuration must be determined such as the need for additional protocols between the KDC designated by the Group Owner and KDCs that have been delegated to serve keys on behalf of the designated KDC. 6.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 attacks. 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 KDC should not be authenticated using shared symmetric secrets unless all members of the group can be trusted not to impersonate the KDC. Similarly, members who disclose group secrets undermine the security of the entire group. Group Owners and KDC administrators must be aware of these inherent limitations of group key management. Another limitation of group key management is policy complexity: Baugher, Canetti, Dondeti [Page 17] Internet Draft Group Key Management Architecture June 2001 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, KDC operators, and users need to determine minimal acceptable levels of trust, authenticity and confidentiality when joining secure groups. Unfortunately, group policy is at a very early stage of development so little guidance is available to the technical community at the present time. 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, however, is novel and novelty is a problem for security protocols: Issues with reliable delivery of messages, implosion, and the complexity of group memberships management algorithms that run on the Re-key messages need careful consideration. 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 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- articulate standard for security and risks of group key management. 7.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. Baugher, Canetti, Dondeti [Page 18] Internet Draft Group Key Management Architecture June 2001 [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. [GSAKMP] H.Harney, A.Colegrove, E.Harder, U.Meth, R.Fleischer, Group Secure Association Key Management Protocol, http://www.ietf.org/internet-drafts/draft-ietf-msec-gsakmp-sec-00.txt, March 2001, Work in Progress. [HBH] H. Harney, M. Baugher, T. Hardjono, GKM Building Block: Group Security Association (GSA) Definition, http://www.ietf.org/internet-drafts/draft-irtf-smug-gkmbb-gsadef- 00.txt, Work in Progress 2000. [HBH01] Group Security Association Management in IP Multicast, T. Hardjono, M. Baugher, H. Harney, Proceedings of 16th IFIP/SEC International Conference on Information Security, Paris, France May 2001. [HCBD] T. Hardjono, R. Canetti, M. Baugher, P. Dinsmore, Secure IP Multicast: Problem areas, Framework, and Building Blocks, http://www.ietf.org/internet-drafts/draft-irtf-smug-framework-00.txt, Work in Progress 1999. [HH] H. Harney, E. Harder, Group Secure Association Key Management Protocol, http://search.ietf.org/internet-drafts/draft-harney-sparta- gsakmp-sec-02.txt, June 2000, 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. [MARKS] B. Briscoe, MARKS: Zero Side Effect Multicast Key Management using Arbitrarily Revealed Key Sequences, Proceedings of NGC'99, rbriscoe@bt.co.uk. [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 (http://www.wipo.org/eng/meetings/1999/wct_wppt/pdf/imp99_3.pdf). Baugher, Canetti, Dondeti [Page 19] Internet Draft Group Key Management Architecture June 2001 [NAI] http://www.nai.com/media/pdf/products/tns/6_PGP_VPN_001.pdf [OFT] D. Balenson, D. McGrew, A. Sherman, Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization, http://www.ietf.org/internet-drafts/draft-balenson-groupkeymgmt-oft- 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. [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 1998. [RFC2522] P. Karn, W. Simpson, Photuris: Session-Key Management Protocol, March 1999. [RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for Multicast: Issues and Architectures, September 1998. [Schneier] B. Schneier, Applied Cryptography, Second Edition, John Wiley & Sons, 1996. Baugher, Canetti, Dondeti [Page 20] Internet Draft Group Key Management Architecture June 2001 [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, http://www.ietf.org/internet- drafts/draft-ietf-avt-srtp-00.txt, February 2001, Work in Progress. [Stevenson] F.M. Stevenson, Cryptonalysis of Content Scrambling System, http:/lemuria.org/DeCSS/crypto.gq.nu, November 8, 1999. 8.0 Authors' Addresses Mark Baugher Cisco Systems 5510 SW Orchid St. Portland, OR 97219 (503) 245-4543 Ran Canetti IBM Research 30 Saw Mill river Road Hawthorne, NY 10532 (914) 784 7076 canetti@watson.ibm.com Lakshminath R. Dondeti Nortel Networks 600 Technology Park Drive Billerica, MA 01821, USA (978) 288-6406 ldondeti@nortelnetworks.com Baugher, Canetti, Dondeti [Page 21] Internet Draft Group Key Management Architecture June 2001 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 22]