1. Introduction
This document presents an ISAKMP Domain of Interpretation (DOI) for group key management called the "Group Domain of Interpretation" (GDOI). In this group key management model, the GDOI protocol is run between a group member and a "group controller/key server" (GCKS), which establishes security associations [Section 4.6.2 RFC2401] among authorized group members. ISAKMP defines two "phases" of negotiation [p.16 RFC2408]. The GDOI MUST be protected by a Phase 1 security association. This document incorporates the Phase 1 security association (SA) definition from the Internet DOI [RFC2407, RFC2409]. Other possible Phase 1 security association types are noted in Appendix A. The Phase 2 exchange is defined in this document, and proposes new payloads and exchanges according to the ISAKMP standard [p. 14 RFC2408].
There are six new payloads:
- GDOI SA
- SA KEK (SAK), which follows the SA payload
- SA TEK (SAT), which follows the SA payload
- Key Download Array (KD)
- Sequence Number (SEQ)
- Proof of Possession (POP)
There are two new exchanges.
1) A Phase 2 exchange creates Re-key and Data-Security Protocol SAs.
The new Phase 2 exchange, called "GROUPKEY-PULL," downloads keys for a group's "Re-key" SA and/or "Data-security" SA. The Re-key SA includes a key encrypting key, or KEK, common to the group; a Data-security SA includes a data encryption key, or TEK, used by a data-security protocol to encrypt or decrypt data traffic [Section 2.1 RFC2407]. The SA for the KEK or TEK includes authentication keys, encryption keys, cryptographic policy, and attributes. The GROUPKEY-PULL exchange uses "pull" behavior since the member initiates the retrieval of these SAs from a GCKS.
2) A datagram subsequently establishes additional Rekey and/or Data-Security Protocol SAs.
The GROUPKEY-PUSH datagram is "pushed" from the GCKS to the members to create or update a Re-key or Data-security SA. A Re-key SA protects GROUPKEY-PUSH messages. Thus, a GROUPKEY-PULL is necessary to establish at least one Re-key SA in order to protect subsequent GROUPKEY-PUSH messages. The GCKS encrypts the GROUPKEY-PUSH message using the KEK Re-key SA. GDOI accommodates the use of arrays of KEKs for group key management algorithms using the Logical Key Hierarchy (LKH) algorithm to efficiently add and remove group members [RFC2627]. Implementation of the LKH algorithm is OPTIONAL.
Although the GROUPKEY-PUSH specified by this document can be used to refresh a Re-key SA, the most common use of GROUPKEY-PUSH is to establish a Data-security SA for a data security protocol. GDOI can accommodate future extensions to support a variety of data security protocols. This document only specifies data-security SAs for one security protocol, IPsec ESP. A separate RFC will specify support for other data security protocols such as a future secure Real-time Transport Protocol. A security protocol uses the TEK and "owns" the data-security SA in the same way that IPsec ESP uses the IKE Phase 2 keys and owns the Phase 2 SA; for GDOI, IPsec ESP uses the TEK.
Thus, GDOI is a group security association management protocol: All GDOI messages are used to create, maintain, or delete security associations for a group. As described above, these security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members for multicast and groups security applications.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
1.1. GDOI Applications
Secure multicast applications include video broadcast and multicast file transfer. In a business environment, many of these applications require network security and may use IPsec ESP to secure their data traffic. Section 5.4.1 specifies how GDOI carries the needed SA parameters for ESP. In this way, GDOI supports multicast ESP with group authentication of ESP packets using the shared, group key (authentication of unique sources of ESP packets is not possible).
GDOI can also secure group applications that do not use multicast transport such as video-on-demand. For example, the GROUPKEY-PUSH message may establish a pair-wise IPsec ESP SA for a member of a subscription group without the need for key management exchanges and costly asymmetric cryptography.
1.2. Extending GDOI
Not all secure multicast or multimedia applications can use IPsec ESP. For example, many Real Time Transport Protocol applications require security above the IP layer to preserve RTP header compression efficiency and transport independence [RFC3550]. A future RTP security protocol may benefit from using GDOI to establish group SAs.
To add a new data-security protocol, a new RFC MUST specify the data-security SA parameters that GDOI carries for that security protocol; these parameters are enumerated in Section 5.4.2 of this document.
A data-security protocol SA MUST protect group traffic. GDOI places no restriction on whether that group traffic is delivered as unicast or multicast packets. However, GDOI MUST NOT be used by a data-security protocol as a key management mechanism when the packets protected by the data-security SA are intended to remain private and never be part of group communication.