Group Domain of Interpretation (GDOI) GROUPKEY-PUSH Acknowledgement Message
Extracted elements (26)
A separate ack_key is derived from the base_key rather than using the KEK directly, so that the acknowledgement's authentication key is cryptographically distinct from the group encryption key. This limits the exposure of the KEK material through the unencrypted ACK messages.
The GROUPKEY-PUSH ACK allows a GCKS to determine which GMs are receiving the current group policy and which are no longer participating, enabling policy-driven actions such as retransmission or removal of unresponsive GMs. Without ACKs, the GCKS has no positive confirmation that policy was delivered.
The REKEY_ACK_LKH types use a secret pairwise key (the first LKH key shared only between the GCKS and the individual GM), which mitigates impersonation attacks possible with REKEY_ACK_KEK types where the KEK is a shared group secret.
The GROUPKEY-PUSH ACK is an ISAKMP message as defined in RFC 2408. Although RFC 2408 has been obsoleted by RFC 7296, only RFC 2408 applies in the GDOI context. Implementations must use RFC 2408 message authentication constructs, not RFC 7296.
A GCKS SHOULD be prepared to receive GROUPKEY-PUSH ACKs from each GM to which a GROUPKEY-PUSH was sent, ensuring sufficient resources (e.g., receive queue size) so that ACKs are not unnecessarily dropped.
A GCKS SHOULD log failure events including: receiving ACKs for a group in which ACKs were not requested, receiving malformed Acknowledgements, and Acknowledgements that fail HASH validation.
A GCKS SHOULD NOT consider a GM to have left the group until it has received at least one ACK from that GM, since network loss can cause a live GM to appear unresponsive.
A GM receiving a GROUPKEY-PUSH as multicast MAY introduce jitter in its ACK timing, but MUST NOT delay sending the Acknowledgement Message for more than 5 seconds. A GCKS SHOULD NOT declare an ACK as missing until it has waited at least 10 seconds. Both timers SHOULD be configurable.
A GM recognizing the KEK_ACK_REQUESTED attribute MUST honor it by returning Acknowledgements, because the GCKS may take policy-specific actions against unresponsive GMs including ceasing to deliver GROUPKEY-PUSH messages.
A GROUPKEY-PUSH ACK MUST be sent even if the GROUPKEY-PUSH message contains a Delete payload for the KEK used to protect it. The ACK is sent only after successful processing of the GROUPKEY-PUSH message per RFC 6407.
GCKS implementations SHOULD keep a record (e.g., a hash value) of recently received GROUPKEY-PUSH Acknowledgement Messages and reject duplicate messages prior to performing cryptographic operations, enabling early discard of replayed messages.
Implementation of the GROUPKEY-PUSH Acknowledgement Message is OPTIONAL. A GM that cannot respond with the requested acknowledgement type continues with the protocol exchange and participates in the group.
The HDR of the GROUPKEY-PUSH ACK MUST initialize: cookies copied from the GROUPKEY-PUSH message as SPI, Next Payload = 8 (HASH), Major Version = 1, Minor Version = 0, Exchange Type = 35 (GROUPKEY-PUSH-ACK), Flags = 0, and Message ID MUST be set to 0.
The ID payload Protocol ID and Port fields MUST be set to 0. The IP address in the ID payload MUST match the source IP address used for the GM's most recent GROUPKEY-PULL exchange. Supported ID Types are ID_IPV4_ADDR, ID_IPV6_ADDR, or ID_OID.
The L field in the ack_key derivation MUST match the length of the base_key (e.g., 512 bits for PRF-HMAC-SHA-256) and is represented as two octets in network byte order. If the base_key or derived ack_key is smaller than the prf block size it is zero-filled to the right.
When a GROUPKEY-PUSH message includes a Delete payload for the KEK protecting it, the GCKS SHOULD NOT delete the KEK until it has given GMs the opportunity to acknowledge receipt, which could be several seconds due to jitter.
Four KEK_ACK_REQUESTED types are defined: REKEY_ACK_KEK_SHA256 (value 1) uses PRF-HMAC-SHA-256 with the KEK_ALGORITHM_KEY as base_key; REKEY_ACK_LKH_SHA256 (value 2) uses PRF-HMAC-SHA-256 with the first LKH key as base_key; REKEY_ACK_KEK_SHA512 (value 3) and REKEY_ACK_LKH_SHA512 (value 4) are identical to the SHA-256 variants but use PRF-HMAC-SHA-512.
The HASH payload is computed as HASH = prf(ack_key, SEQ | ID), where ack_key is derived via KDF in feedback mode (NIST SP800-108): ack_key = prf(base_key, "GROUPKEY-PUSH ACK" | SPI | L). The label is null-terminated ASCII; SPI is the Initiator followed by Responder Cookie from the GROUPKEY-PUSH HDR.
The KEK_ACK_REQUESTED attribute (value 9) is a Basic attribute added to the SA KEK Payload Values - KEK Attributes. When included in SA KEK policy, it signals that the GCKS requests the GM to return a GROUPKEY-PUSH Acknowledgement Message.
The SEQ payload value is copied verbatim from the GROUPKEY-PUSH SEQ payload. This sequence number uniquely identifies the rekey message and serves as the primary correlation between a GROUPKEY-PUSH and its acknowledgement.
A new "GDOI DOI Exchange Types" IANA registry is created under "Group Domain of Interpretation (GDOI) Payloads" for DOI Specific Use ISAKMP exchange type values. Defines GROUPKEY-PULL (32), GROUPKEY-PUSH (33), Known Unregistered Use (34), GROUPKEY-PUSH-ACK (35), and Unassigned (36-239). Registration procedure is Specification Required.
A new "SA KEK Payload Values - KEK_ACK_REQUESTED" IANA registry is created under "Group Domain of Interpretation (GDOI) Payloads" with registration procedure Specification Required. Initial values: 0 Reserved, 1 REKEY_ACK_KEK_SHA256, 2 REKEY_ACK_LKH_SHA256, 3 REKEY_ACK_KEK_SHA512, 4 REKEY_ACK_LKH_SHA512, 5-128 Unassigned, 129-255 Private Use.
A GM transmits an ACK only after fully validating the GROUPKEY-PUSH per RFC 6407 Section 4.4 (format validation, replay protection, and digital signature verification), which mitigates the risk of the GM being used as a DDoS amplifier against the GCKS.
Confidentiality is not provided for the GROUPKEY-PUSH ACK. A passive attacker can observe the hash value, the sequence number from the acknowledged GROUPKEY-PUSH, and the GM identity. The sequence number not previously available to the attacker is revealed, but this does not enable forgery of GROUPKEY-PUSH messages.
When REKEY_ACK_KEK is used, impersonation of a victim GM by another authorized GM is possible because the KEK is a group secret. An attacker GM can falsely claim the victim received a GROUPKEY-PUSH, potentially causing the victim to miss retransmissions. REKEY_ACK_LKH mitigates this via pairwise keys.
The GROUPKEY-PUSH Acknowledgement Message consists of four payloads in order: HDR (header), HASH (authentication), SEQ (sequence number copied from the GROUPKEY-PUSH), and ID (GM identity). It is sent as a UDP unicast reply to the GCKS.