RFC 6407
The Group Domain of Interpretation
Internet Engineering Task Force (IETF) B. Weis Request for Comments: 6407 S. Rowles Obsoletes: 3547 Cisco Systems Category: Standards Track T. Hardjono ISSN: 2070-1721 MIT October 2011 The Group Domain of InterpretationAbstract
This document describes the Group Domain of Interpretation (GDOI) protocol specified in RFC 3547. The GDOI provides group key management to support secure group communications according to the architecture specified in RFC 4046. The GDOI manages group security associations, which are used by IPsec and potentially other data security protocols. This document replaces RFC 3547. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6407. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 7 2. GDOI Phase 1 Protocol . . . . . . . . . . . . . . . . . . . . 8 2.1. DOI value . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. UDP port . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . . . 9 3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Group Member Operations . . . . . . . . . . . . . . . . . 12 3.4. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 13 3.5. Counter-Modes of Operation . . . . . . . . . . . . . . . . 14 4. GROUPKEY-PUSH Message . . . . . . . . . . . . . . . . . . . . 16 4.1. Use of Signature Keys . . . . . . . . . . . . . . . . . . 17 4.2. ISAKMP Header Initialization . . . . . . . . . . . . . . . 17 4.3. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 17 4.4. Group Member Operations . . . . . . . . . . . . . . . . . 18 5. Payloads and Defined Values . . . . . . . . . . . . . . . . . 19 5.1. Identification Payload . . . . . . . . . . . . . . . . . . 20 5.2. Security Association Payload . . . . . . . . . . . . . . . 20 5.3. SA KEK Payload . . . . . . . . . . . . . . . . . . . . . . 21 5.4. Group Associated Policy . . . . . . . . . . . . . . . . . 27 5.5. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 30 5.6. Key Download Payload . . . . . . . . . . . . . . . . . . . 34 5.7. Sequence Number Payload . . . . . . . . . . . . . . . . . 44 5.8. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.9. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 45 6.1. KEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.2. TEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 7. Security Considerations . . . . . . . . . . . . . . . . . . . 47 7.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . . 47 7.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . 48
7.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . . 50
7.4. Forward and Backward Access Control . . . . . . . . . . . 51
7.5. Derivation of Keying Material . . . . . . . . . . . . . . 53
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
8.1. Additions to Current Registries . . . . . . . . . . . . . 53
8.2. New Registries . . . . . . . . . . . . . . . . . . . . . . 54
8.3. Cleanup of Existing Registries . . . . . . . . . . . . . . 55
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
10.1. Normative References . . . . . . . . . . . . . . . . . . . 57
10.2. Informative References . . . . . . . . . . . . . . . . . . 58
Appendix A. GDOI Applications . . . . . . . . . . . . . . . . . . 62
Appendix B. Significant Changes from RFC 3547 . . . . . . . . . . 62
1. Introduction
Secure group and multicast applications require a method by which
each group member shares common security policy and keying material.
This document describes the Group Domain of Interpretation (GDOI),
which is an Internet Security Association and Key Management Protocol
(ISAMKP) [RFC2408] Domain of Interpretation (DOI), a group key
management system. The GDOI distributes security associations (SAs)
for IPsec Authentication Header (AH) [RFC4302] and Encapsulating
Security Payload (ESP) [RFC4303] protocols and potentially other data
security protocols used in group applications. The GDOI uses the
group key management model defined in [RFC4046], and described more
generally by "The Multicast Group Security Architecture" [RFC3740].
In this group key management model, the GDOI protocol participants
are a Group Controller/Key Server (GCKS) and a group member (GM). A
group member contacts ("registers with") a GCKS to join the group.
During the registration, mutual authentication and authorization are
achieved, after which the GCKS distributes current group policy and
keying material to the group member over an authenticated and
encrypted session. The GCKS may also initiate contact ("rekeys")
with group members to provide updates to group policy.
ISAKMP defines two "phases" of negotiation (Section 2.3 of
[RFC2408]). A Phase 1 security association provides mutual
authentication and authorization, and a security association that is
used by the protocol participants to execute a Phase 2 exchange.
This document incorporates (i.e., uses but does not redefine) the
Phase 1 security association definition from the Internet DOI
[RFC2407], [RFC2409]. Although RFCs 2407, 2408, and 2409 were
obsoleted by [RFC4306] (and subsequently [RFC5996]), they are used by
this document because the protocol definitions remain relevant for
ISAKMP protocols other than IKEv2.
The GDOI includes two new Phase 2 ISAKMP exchanges (protocols), as well as necessary new payload definitions to the ISAKMP standard (Section 2.1 of [RFC2408]). These two new protocols are: 1. The GROUPKEY-PULL registration protocol exchange. This exchange uses "pull" behavior since the member initiates the retrieval of these SAs from a GCKS. It is protected by an ISAKMP Phase 1 protocol, as described above. At the culmination of a GROUPKEY- PULL exchange, an authorized group member has received and installed a set of SAs that represent group policy, and it is ready to participate in secure group communications. 2. The GROUPKEY-PUSH rekey protocol exchange. The rekey protocol is a datagram initiated ("pushed") by the GCKS, usually delivered to group members using a IP multicast address. The rekey protocol is an ISAKMP protocol, where cryptographic policy and keying material ("Rekey SA") are included in the group policy distributed by the GCKS in the GROUPKEY-PULL exchange. At the culmination of a GROUPKEY-PUSH exchange, the key server has sent group policy to all authorized group members, allowing receiving group members to participate in secure group communications. If a group management method is included in group policy (as described in Section 7.4), at the conclusion of the GROUPKEY-PUSH exchange, some members of the group may have been de-authorized and no longer able to participate in the secure group communications.
+--------------------------------------------------------------+ | | | +--------------------+ | | +------>| GDOI GCKS |<------+ | | | +--------------------+ | | | | | | | | GROUPKEY-PULL | GROUPKEY-PULL | | PROTOCOL | PROTOCOL | | | | | | | v GROUPKEY-PUSH v | | +-----------------+ PROTOCOL +-----------------+ | | | | | | | | | | GDOI GM(s) |<-------+-------->| GDOI GM(S) | | | | | | | | | +-----------------+ +-----------------+ | | | ^ | | v | | | +-Data Security Protocol (e.g., ESP)-+ | | | +--------------------------------------------------------------+ Figure 1. Group Key Management Model Although the GROUPKEY-PUSH protocol specified by this document can be used to refresh the Rekey SA protecting the GROUPKEY-PUSH protocol, the most common use of GROUPKEY-PUSH is to establish keying material and policy for a data security protocol. GDOI defines several payload types used to distribute policy and keying material within the GROUPKEY-PULL and GROUPKEY-PUSH protocols: Security Association (SA), SA KEK, SA TEK, Group Associated Policy (GAP), Sequence Number (SEQ), and Key Download (KD). Format and usage of these payloads are defined in later sections of this memo. In summary, 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 data security protocol SAs, a Rekey SA, and/or other data shared by group members for multicast and groups security applications.1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
1.2. Terminology
The following key terms are used throughout this document. Data-Security SA The security policy distributed by a GDOI GCKS describing traffic that is expected to be protected by group members. This document described the distribution of IPsec AH and ESP Data-Security SAs. Group Controller/Key Server A device that defines group policy and distributes keys for that policy [RFC3740]. Group Member. An authorized member of a secure group, sending and/or receiving IP packets related to the group. GROUPKEY-PULL. A protocol used by a GDOI group member to request group policy and keying material. GROUPKEY-PUSH. A protocol used by a GDOI GCKS to distribute updates of group policy and keying material to authorized group members. Key Encrypting Key. The symmetric cipher key used to protect the GROUPKEY-PUSH message. Logical Key Hierarchy. A group management method defined in Section 5.4 of [RFC2627]. Rekey SA. The security policy protecting a GROUPKEY-PUSH protocol. SA Attribute Payload A payload that follows the Security Association payload and that describes group security attributes associated with the security association. SA Attribute payloads include the SAK, SAT, and GAP payloads. Security Parameter Index An arbitrary value that is used by a receiver to identify a security association such as an IPsec ESP Security Association or a Rekey SA. Traffic Encryption Key. The symmetric cipher key used to protect a data security protocol (e.g., IPsec ESP).
1.3. Acronyms and Abbreviations
The following acronyms and abbreviations are used throughout this document. AH IP Authentication Header ATD Activation Time Delay DOI Domain of Interpretation DTD Deactivation Time Delay ESP IP Encapsulating Security Payload GCKS Group Controller/Key Server GDOI Group Domain of Interpretation GAP Group Associated Policy Payload GM Group Member GSPD Group Security Policy Database IV Initialization Vector KD Key Download Payload KEK Key Encryption Key LKH Logical Key Hierarchy SA Security Association SAK SA KEK Payload SEQ Sequence Number Payload SAT SA TEK Payload SID Sender-ID SPI Security Parameter Index SSIV Sender-Specific IV TEK Traffic Encryption Key
TLV Type/Length/Value TV Type/Value2. GDOI Phase 1 Protocol
The GDOI GROUPKEY-PULL exchange is a Phase 2 protocol that MUST be protected by a Phase 1 protocol. The Phase 1 protocol can be any protocol that provides for the following protections: o Peer Authentication o Confidentiality o Message Integrity The following sections describe one such Phase 1 protocol. Other protocols which may be potential Phase 1 protocols are described in Appendix A. However, the use of the protocols listed there are not considered part of this document. This document defines how the ISAKMP Phase 1 exchanges as defined in [RFC2409] can be used a Phase 1 protocol for GDOI. The following sections define characteristics of the ISAKMP Phase 1 protocols that are unique for these exchanges when used for GDOI. Section 7.1 describes how the ISAKMP Phase 1 protocols meet the requirements of a GDOI Phase 1 protocol.2.1. DOI value
The Phase 1 SA payload has a DOI value. That value MUST be the GDOI DOI value as defined later in this document.2.2. UDP port
IANA has assigned port 848 for the use of GDOI; this allows for an implementation to use separate ISAKMP implementations to service GDOI and the Internet Key Exchange Protocol (IKE) [RFC5996]. A GCKS SHOULD listen on this port for GROUPKEY-PULL exchanges, and the GCKS MAY use this port to distribute GROUPKEY-PUSH messages. An ISAKMP Phase 1 exchange implementation supporting NAT traversal [RFC3947] MAY move to port 4500 to process the GROUPKEY-PULL exchange.
3. GROUPKEY-PULL Exchange
The goal of the GROUPKEY-PULL exchange is to establish a Rekey and/or Data-Security SAs at the member for a particular group. A Phase 1 SA protects the GROUPKEY-PULL; there MAY be multiple GROUPKEY-PULL exchanges for a given Phase 1 SA. The GROUPKEY-PULL exchange downloads the data security keys (TEKs) and/or group key encrypting key (KEK) or KEK array under the protection of the Phase 1 SA.3.1. Authorization
It is important that a group member explicitly trust entities that it expects to act as a GCKS for a particular group. When no authorization is performed, it is possible for a rogue GDOI participant to perpetrate a man-in-the-middle attack between a group member and a GCKS [MP04]. A group member MUST specifically list each authorized GCKS in its Group Peer Authorization Database (GPAD) [RFC5374]. A group member MUST ensure that the Phase 1 identity of the GCKS is an authorized GCKS. It is important that a GCKS explicitly authorize group members before providing them with group policy and keying material. A GCKS implementation SHOULD have a method of authorizing group members (e.g., by maintaining an authorization list). When the GCKS performs authorization, it MUST use the Phase 1 identity to authorize the GROUPKEY-PULL request for group policy and keying material.3.2. Messages
The GROUPKEY-PULL is a Phase 2 exchange. Phase 1 computes SKEYID_a, which is the "key" in the keyed hash used in the ISAKMP HASH payloads [RFC2408] included in GROUPKEY-PULL messages. When using the Phase 1 defined in this document, SKEYID_a is derived according to [RFC2409]. Each GROUPKEY-PULL message hashes a uniquely defined set of values (described below) and includes the result in the HASH payload. Nonces permute the HASH and provide some protection against replay attacks. Replay protection is important to protect the GCKS from attacks that a key management server will attract. The GROUPKEY-PULL uses nonces to guarantee "liveness" as well as against replay of a recent GROUPKEY-PULL message. The replay attack is only possible in the context of the current Phase 1. If a GROUPKEY-PULL message is replayed based on a previous Phase 1, the HASH calculation will fail due to a wrong SKEYID_a. The message will fail processing before the nonce is ever evaluated.
In order for either peer to get the benefit of the replay protection, it must postpone as much processing as possible until it receives the message in the protocol that proves the peer is live. For example, the GCKS MUST NOT adjust its internal state (e.g., keeping a record of the GM) until it receives a message with Nr included properly in the HASH payload. This requirement ensures that replays of GDOI messages will not cause the GCKS to change the state of the group until it has confirmation that the initiating group member is live. Group Member GCKS ------------ ---- (1) HDR*, HASH(1), Ni, ID --> (2) <-- HDR*, HASH(2), Nr, SA (3) HDR*, HASH(3) [,GAP] --> (4) <-- HDR*, HASH(4), [SEQ,] KD * Protected by the Phase 1 SA; encryption occurs after HDR Figure 2. GROUPKEY-PULL Exchange Figure 2 demonstrates the four messages that are part of a GROUPKEY- PULL exchange. HDR is an ISAKMP header payload that uses the Phase 1 cookies and a message identifier (M-ID) as in ISAKMP. Following each HDR is a set of payloads conveying requests (messages 1 and 3 originated by the group member), or group policy and/or keying material (messages 2 and 4 originated by the GCKS). Hashes are computed in the manner described within [RFC2409]. The HASH computation for each message is unique; it is shown in Figure 2 and below as HASH(n) where (n) represents the GROUPKEY-PULL message number. Each HASH calculation is a pseudo-random function ("prf") over the message ID (M-ID) from the ISAKMP header concatenated with the entire message that follows the hash including all payload headers, but excluding any padding added for encryption. The GM expects to find its nonce, Ni, in the HASH of a returned message, and the GCKS expects to see its nonce, Nr, in the HASH of a returned message. HASH(2), HASH(3), and HASH(4) also include nonce values previously passed in the protocol (i.e., Ni or Nr minus the payload header). The nonce passed in Ni is represented as Ni_b, and the nonce passed in Nr is represented as Nr_b. The HASH payloads prove that the peer has the Phase 1 secret (SKEYID_a) and the nonce for the exchange identified by message ID, M-ID. HASH(1) = prf(SKEYID_a, M-ID | Ni | ID) HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA) HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | GAP ]) HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | SEQ ] | KD)
In addition to the Nonce and HASH payloads, the GM identifies the group it wishes to join through the ISAKMP ID payload. The GCKS informs the member of the cryptographic policies of the group in the SA payload, which describes the DOI, KEK, and/or TEK keying material, authentication transforms, and other group policy. Each SPI is also determined by the GCKS and downloaded in the SA payload chain (see Section 5.2). The SA KEK attribute contains the ISAKMP cookie pair for the Rekey SA, which is not negotiated but downloaded. Each SA TEK attribute contains a SPI as defined in Section 5.5 of this document. After receiving and parsing the SA payload, the GM responds with an acknowledgement message proving its liveness. It optionally includes a GAP payload requesting resources. The GCKS informs the GM of the value of the sequence number in the SEQ payload. This sequence number provides anti-replay state associated with a KEK, and its knowledge ensures that the GM will not accept GROUPKEY-PUSH messages sent prior to the GM joining the group. The SEQ payload has no other use and is omitted from the GROUPKEY- PULL exchange when a KEK attribute is not included in the SA payload. When a SEQ payload is included in the GROUPKEY-PULL exchange, it includes the most recently used sequence number for the group. At the conclusion of a GROUPKEY-PULL exchange, the initiating group member MUST NOT accept any rekey message with both the KEK attribute SPI value and a sequence number less than or equal to the one received during the GROUPKEY-PULL exchange. When the first group member initiates a GROUPKEY-PULL exchange, the GCKS provides a Sequence Number of zero, since no GROUPKEY-PUSH messages have yet been sent. Note the sequence number increments only with GROUPKEY- PUSH messages. The GROUPKEY-PULL exchange distributes the current sequence number to the group member. The sequence number resets to a value of one with the usage of a new KEK attribute. Thus, the first packet sent for a given Rekey SA will have a Sequence Number of 1. The sequence number increments with each successive rekey. The GCKS always returns a KD payload containing keying material to the GM. If a Rekey SA is defined in the SA payload, then KD will contain the KEK; if one or more Data-Security SAs are defined in the SA payload, KD will contain the TEKs.3.2.1. ISAKMP Header Initialization
Cookies are used in the ISAKMP header to identify a particular GDOI session. The GDOI GROUPKEY-PULL exchange uses cookies according to ISAKMP [RFC2408].
Next Payload identifies an ISAKMP or GDOI payload (see Section 5). Major Version is 1 and Minor Version is 0 according to ISAKMP (Section 3.1 of [RFC2408]). The Exchange Type has value 32 for the GDOI GROUPKEY-PULL exchange. Flags, Message ID, and Length are according to ISAKMP (Section 3.1 of [RFC2408]). The Commit flag is not useful because there is no synchronization between the GROUPKEY-PULL exchange and the data traffic protected by the policy distributed by the GROUPKEY-PULL exchange.3.3. Group Member Operations
Before a GM contacts the GCKS, it needs to determine the group identifier and acceptable Phase 1 policy via an out-of-band method. Phase 1 is initiated using the GDOI DOI in the SA payload. Once Phase 1 is complete, the GM state machine moves to the GDOI protocol. To construct the first GDOI message, the GM chooses Ni, creates a nonce payload, builds an identity payload including the group identifier, and generates HASH(1). Upon receipt of the second GDOI message, the GM validates HASH(2), extracts the nonce Nr, and interprets the SA payload (including its SA Attribute payloads) . The SA payload contains policy describing the security protocol and cryptographic protocols used by the group. This policy describes the Rekey SA (if present), Data-Security SAs, and other group policy. If the policy in the SA payload is acceptable to the GM, it continues the protocol. Otherwise, the GM SHOULD tear down the Phase 1 session after notifying the GCKS with an ISAKMP Informational Exchange containing a Delete payload. When constructing the third GDOI message, it first reviews each Data- Security SA given to it. If any describe the use of a counter mode cipher, the GM determines whether it requires more than one Sender-ID (SID) (see Section 3.5). If so, it requests the required number of Sender-IDs for its exclusive use within the counter mode nonce as described in Section 5.4 of this document. The GM then completes construction of the third GDOI message by creating HASH(3). Upon receipt of the fourth GDOI message, the GM validates HASH(4). If the SEQ payload is present, the sequence number included in the SEQ payload asserts the lowest acceptable sequence number present in a future GROUPKEY-PUSH message. But if the KEK associated with this sequence number had been previously installed, due to the
asynchronous processing of GROUPKEY-PULL and GROUPKEY-PUSH messages, this sequence number may be lower than the sequence number contained in the most recently received GROUPKEY-PUSH message. In this case, the sequence number value in the SEQ payload MUST be considered stale and ignored. The GM interprets the KD key packets, where each key packet includes the keying material for SAs distributed in the SA payload. Keying material is matched by comparing the SPI in each key packet to SPI values previously sent in the SA payloads. Once TEKs and policy are matched, the GM provides them to the data security subsystem, and it is ready to send or receive packets matching the TEK policy. If this group has a KEK, the KEK policy and keys are marked as ready for use, and the GM knows to expect a sequence number not less than the one distributed in the SEQ payload. The GM is now ready to receive GROUPKEY-PUSH messages. If the KD payload included an LKH array of keys, the GM takes the last key in the array as the group KEK. The array is then stored without further processing.3.4. GCKS Operations
The GCKS passively listens for incoming requests from group members. The Phase 1 authenticates the group member and sets up the secure session with them. Upon receipt of the first GDOI message, the GCKS validates HASH(1) and extracts the Ni and group identifier in the ID payload. It verifies that its database contains the group information for the group identifier and that the GM is authorized to participate in the group. The GCKS constructs the second GDOI message, including a nonce Nr, and the policy for the group in an SA payload, followed by SA Attribute payloads (i.e, SA KEK, GAP, and/or SA TEK payloads) according to the GCKS policy. (See Section 5.2.1 for details on how the GCKS chooses which payloads to send.) Upon receipt of the third GDOI message, the GCKS validates HASH(3). If the message includes a GAP payload, it caches the requests included in that payload for the use of constructing the fourth GDOI message. The GCKS constructs the fourth GDOI message, including the SEQ payload (if the GCKS sends rekey messages), and the KD payload containing keys corresponding to policy previously sent in the SA TEK and SA KEK payloads. If a group management algorithm is defined as
part of group policy, the GCKS will first insert the group member into the group management structure (e.g., a leaf in the LKH tree), and then create an LKH array of keys and include it in the KD payload. The first key in the array is associated with the group member leaf node, followed by each LKH node above it in the tree, culminating with the root node (which is also the KEK). If one or more Data-Security SAs distributed in the SA payload included a counter mode of operation, the GCKS includes at least one SID value in the KD payload, and possibly more depending on a request received in the third GDOI message.3.5. Counter-Modes of Operation
Several new counter-based modes of operation have been specified for ESP (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES-CCM [RFC4309], AES-GMAC [RFC4543]) and AH (e.g., AES-GMAC [RFC4543]). These counter-based modes require that no two senders in the group ever send a packet with the same Initialization Vector (IV) using the same cipher key and mode. This requirement is met in GDOI when the following requirements are met: o The GCKS distributes a unique key for each Data-Security SA. o The GCKS uses the method described in [RFC6054], which assigns each sender a portion of the IV space by provisioning each sender with one or more unique SID values. When at least one Data-Security SA included in the group policy includes a counter-mode, the GCKS automatically allocates and distributes one SID to each group member acting in the role of sender on the Data-Security SA. The SID value is used exclusively by the group member to which it was allocated. The group member uses the same SID for each Data-Security SA specifying the use of a counter- based mode of operation. A GCKS MUST distribute unique keys for each Data-Security SA including a counter-based mode of operation in order to maintain a unique key and nonce usage. When a group member receives a Data-Security SA in a SA TEK payload for which it is a sender, it can choose to request one or more SID values. Requesting a value of 1 is not necessary since the GCKS will automatically allocate exactly one to the sending group member. A group member MUST request as many SIDs matching the number of encryption modules in which it will be installing the TEKs in the outbound direction. Alternatively, a group member MAY request more than one SID and use them serially. This could be useful when it is anticipated that the group member will exhaust their range of Data- Security SA nonces using a single SID too quickly (e.g., before the time-based policy in the TEK expires).
When group policy includes a counter-based mode of operation, a GCKS
SHOULD use the following method to allocate SID values, which ensures
that each SID will be allocated to just one group member.
1. A GCKS maintains a SID-counter, which records which SIDs have
been allocated. SIDs are allocated sequentially, with the first
SID allocated to be zero.
2. Each time a SID is allocated, the current value of the counter is
saved and allocated to the group member. The SID-counter is then
incremented in preparation for the next allocation.
3. When the GCKS distributes a Data-Security SA specifying a
counter-based mode of operation, and a group member is a sender,
a group member may request a count of SIDs in a GAP payload.
When the GCKS receives this request, it increments the SID-
counter once for each requested SID, and distributes each SID
value to the group member.
4. A GCKS allocates new SID values for each GROUPKEY-PULL exchange
originated by a sender, regardless of whether a group member had
previously contacted the GCKS. In this way, the GCKS does not
have a requirement of maintaining a record of which SID values it
had previously allocated to each group member. More importantly,
since the GCKS cannot reliably detect whether the group member
had sent data on the current group Data-Security SAs, it does not
know which Data-Security counter-mode nonce values a group member
has used. By distributing new SID values, the key server ensures
that each time a conforming group member installs a Data-Security
SA it will use a unique set of counter-based mode nonces.
5. When the SID-counter maintained by the GCKS reaches its final SID
value, no more SID values can be distributed. Before
distributing any new SID values, the GCKS MUST delete the Data-
Security SAs for the group, followed by creation of new Data-
Security SAs, and resetting the SID-counter to its initial value.
6. The GCKS SHOULD send a GROUPKEY-PUSH message deleting all Data-
Security SAs and the Rekey SA for the group. This will result in
the group members initiating a new GROUPKEY-PULL exchange, in
which they will receive both new SID values and new Data-Security
SAs. The new SID values can safely be used because they are only
used with the new Data-Security SAs. Note that deletion of the
Rekey SA is necessary to ensure that group members receiving a
GROUPKEY-PUSH exchange before the re-register do not
inadvertently use their old SIDs with the new Data-Security SAs.
Using the method above, at no time can two group members use the same IV values with the same Data-Security SA key.4. GROUPKEY-PUSH Message
GDOI sends control information securely using group communications. Typically, this will be using IP multicast distribution of a GROUPKEY-PUSH message, but it can also be "pushed" using unicast delivery if IP multicast is not possible. The GROUPKEY-PUSH message replaces a Rekey SA KEK or KEK array, and/or it creates a new Data- Security SA. GM GCKS -- ---- <---- HDR*, SEQ, [D,] SA, KD, SIG * Protected by the Rekey SA KEK; encryption occurs after HDR Figure 3. GROUPKEY-PUSH Message HDR is defined below. The SEQ payload is defined in Section 5 ("Payloads"). One or more D (Delete) payloads (further described in Section 5.9) optionally specify the deletion of existing group policy. The SA defines the group policy for replacement Rekey SA and/or Data-Security SAs as described in Section 5, with the KD providing keying material for those SAs. The SIG payload includes a signature of a hash of the entire GROUPKEY-PUSH message (excepting the SIG payload octets) before it has been encrypted. The HASH is taken over the string 'rekey', the GROUPKEY-PUSH HDR, followed by all payloads preceding the SIG payload. The prefixed string ensures that the signature of the Rekey datagram cannot be used for any other purpose in the GDOI protocol. The SIG payload is created using the signature of the above hash, with the receiver verifying the signature using a public key retrieved in a previous GDOI exchange. The current KEK (also previously distributed in a GROUPKEY-PULL exchange or GROUPKEY-PUSH message) encrypts all the payloads following the GROUPKEY-PUSH HDR. Note: The rationale for this order of operations is given in Section 7.3.5. If the SA defines the use of a single KEK or an LKH KEK array, KD MUST contain a corresponding KEK or KEK array for a new Rekey SA, which has a new cookie pair. When the KD payload carries a new SA KEK attribute (Section 5.3), a Rekey SA is replaced with a new SA having the same group identifier (ID specified in message 1 of Section 3.2) and incrementing the same sequence counter, which is initialized in message 4 of Section 3.2. Note the first packet for
the given Rekey SA encrypted with the new KEK attribute will have a Sequence number of 1. If the SA defines an SA TEK payload, this informs the member that a new Data-Security SA has been created, with keying material carried in KD (Section 5.6). If the SA defines a large LKH KEK array (e.g., during group initialization and batched rekeying), parts of the array MAY be sent in different unique GROUPKEY-PUSH datagrams. However, each of the GROUPKEY-PUSH datagrams MUST be a fully formed GROUPKEY-PUSH datagram. This results in each datagram containing a sequence number and the policy in the SA payload, which corresponds to the KEK array portion sent in the KD payload.4.1. Use of Signature Keys
A signing key should not be used in more than one context (e.g., used for host authentication and also for message authentication). Thus, the GCKS SHOULD NOT use the same key to sign the SIG payload in the GROUPKEY-PUSH message as was used for authentication in the GROUPKEY- PULL exchange.4.2. ISAKMP Header Initialization
Unlike ISAKMP, the cookie pair is completely determined by the GCKS. The cookie pair in the GDOI ISAKMP header identifies the Rekey SA to differentiate the secure groups managed by a GCKS. Thus, GDOI uses the cookie fields as an SPI. Next Payload identifies an ISAKMP or GDOI payload (see Section 5). Major Version is 1 and Minor Version is 0 according to ISAKMP (Section 3.1 of [RFC2408]). The Exchange Type has value 33 for the GDOI GROUPKEY-PUSH message. Flags MUST have the Encryption bit set according to Section 3.1 of [RFC2408]. All other bits MUST be set to zero. Message ID MUST be set to zero. Length is according to ISAKMP (Section 3.1 of [RFC2408]).4.3. GCKS Operations
GCKS may initiate a Rekey message for one of several reasons, e.g., the group membership has changed or keys are due to expire.
To begin the rekey datagram, the GCKS builds an ISAKMP HDR with the correct cookie pair, and a SEQ payload that includes a sequence number that is 1 greater than the previous rekey datagram. If the message is using the new KEK attribute for the first time, the SEQ is reset to 1 in this message. An SA payload is then added. This is identical in structure and meaning to an SA payload sent in a GROUPKEY-PULL exchange. If there are changes to the KEK (including due to group members being excluded, in the case of LKH), an SA_KEK attribute is added to the SA. If there are one or more new TEKs, then SA_TEK attributes are added to describe that policy. A KD payload is then added. This is identical in structure and meaning to a KD payload sent in a GROUPKEY-PULL exchange. If an SA_KEK attribute was included in the SA payload, then corresponding KEKs (or a KEK update array) are included. A KEK update array is created by first determining which group members have been excluded, generating new keys as necessary, and then distributing LKH update arrays sufficient to provide the new KEK to remaining group members (see Section 5.4.1 of [RFC2627] for details). TEKs are also sent for each SA_TEK attribute included in the SA payload. In the penultimate step, the GCKS creates the SIG payload and adds it to the datagram. Lastly, the payloads following the HDR are encrypted using the current KEK. The datagram can now be sent.4.4. Group Member Operations
A group member receiving the GROUPKEY-PUSH datagram matches the cookie pair in the ISAKMP HDR to an existing SA. The message is decrypted, and the form of the datagram is validated. This weeds out obvious ill-formed messages (which may be sent as part of a denial- of-service attack on the group). The sequence number in the SEQ payload is validated to ensure that it is greater than the previously received sequence number. The SIG payload is then validated. If the signature fails, the message is discarded. The SA and KD payloads are processed, which results in a new GDOI Rekey SA (if the SA payload included an SA_KEK attribute) and/or new Data-Security SAs being added to the system. If the KD payload includes an LKH update array, the group member compares the LKH ID in each key update packet to the LKH IDs that it holds. If it finds a
match, it decrypts the key using the key prior to it in the key array and stores the new key in the LKH key array that it holds. The final decryption yields the new group KEK. If the SA payload includes one or more Data-Security SAs including a counter-mode of operation and if the receiving group member is a sender for that SA, the group member uses its current SID value with the Data-Security SAs to create counter-mode nonces. If it is a sender and does not hold a current SID value, it MUST NOT install the Data-Security SAs. It MAY initiate a GROUPKEY-PULL exchange to the GCKS in order to obtain a SID value (along with current group policy).
(page 19 continued on part 2)
