The Group Domain of Interpretation
obsoleted by
- rfc-9838 — Group Key Management Using the Internet Key Exchange Protocol Version 2 (IKEv2)
obsoletes
- rfc-3547 — The Group Domain of Interpretation
Extracted elements (27)
IANA assigned port 848 exclusively for GDOI, separate from IKE's port 500, so that an implementation may use completely separate ISAKMP stacks to service GDOI and IKE. NAT traversal support MAY move GROUPKEY-PULL processing to port 4500.
In the GROUPKEY-PUSH message, the SIG payload is computed over the plaintext payloads before encryption (sign-then-encrypt). This ordering is intentional (rationale in Section 7.3.5): the 'rekey' string prefix ensures the signature is context-bound and cannot be repurposed for other GDOI messages, while allowing receivers to verify authenticity independently of decryption.
The GCKS allocates fresh SID values on every GROUPKEY-PULL re-registration rather than tracking previously issued SIDs per member. This avoids persistent GCKS state about each member's IV usage history; since the GCKS cannot reliably know which counter-mode nonces a member has consumed, fresh allocation with new Data-Security SAs guarantees IV uniqueness.
Although RFCs 2407, 2408, and 2409 were obsoleted by RFC 4306 (IKEv2) and subsequently RFC 5996, GDOI continues to reference them because the ISAKMP Phase 1 protocol definitions remain valid for non-IKEv2 ISAKMP protocols. GDOI is not based on IKEv2.
A GCKS MUST distribute unique keys for each Data-Security SA that uses a counter-based mode of operation (AES-CTR, AES-GCM, AES-CCM, AES-GMAC) in order to maintain unique key and nonce usage across all group senders.
A group member MUST specifically list each authorized GCKS in its Group Peer Authorization Database (GPAD) and MUST ensure that the Phase 1 identity of the GCKS matches an authorized GCKS, preventing rogue-GCKS man-in-the-middle attacks.
At the conclusion of a GROUPKEY-PULL exchange, the initiating group member MUST NOT accept any rekey message whose KEK attribute SPI matches and whose sequence number is less than or equal to the one received during the GROUPKEY-PULL exchange.
If a group member acting as sender does not hold a current SID value upon receiving a counter-mode Data-Security SA via GROUPKEY-PUSH, it MUST NOT install that SA; it MAY initiate a GROUPKEY-PULL exchange to obtain a SID value.
SA TEK policy used by multiple senders MUST be installed in both sending and receiving directions (Symmetric); SA TEK for a single sender SHOULD be installed as Receiver-Only by receivers and Sender-Only by the sender.
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, ensuring that replayed GROUPKEY-PULL messages cannot alter group state without confirmed GM liveness.
The GDOI GROUPKEY-PULL exchange is a Phase 2 protocol that MUST be protected by a Phase 1 protocol providing peer authentication, confidentiality, and message integrity.
The GROUPKEY-PUSH ISAKMP header Flags field MUST have the Encryption bit set and all other bits MUST be zero; Message ID MUST be set to zero. Exchange Type value 33 identifies the GROUPKEY-PUSH message.
The KEK_ALGORITHM and SIG_ALGORITHM attributes MUST be included in every SA KEK payload; all others are OPTIONAL. The KEK_MANAGEMENT_ALGORITHM attribute MUST NOT be included in a GROUPKEY-PULL message and MUST be ignored if present.
When the GCKS SID-counter reaches its final value, the GCKS MUST delete the existing Data-Security SAs, create new ones, and reset the SID-counter before distributing any new SID values, preventing IV reuse across the counter-mode nonce space.
The GCKS allocates Sender-ID (SID) values sequentially from a SID-counter to group members acting as senders on counter-mode Data-Security SAs. One SID is allocated automatically per GROUPKEY-PULL; additional SIDs may be requested via SENDER_ID_REQUEST in a GAP payload. New SIDs are allocated on every re-registration.
The GROUPKEY-PULL is a four-message Phase 2 exchange: (1) GM→GCKS: HDR*, HASH(1), Ni, ID; (2) GCKS→GM: HDR*, HASH(2), Nr, SA; (3) GM→GCKS: HDR*, HASH(3) [,GAP]; (4) GCKS→GM: HDR*, HASH(4), [SEQ,] KD. Each HASH is prf(SKEYID_a, M-ID | nonces | payloads), providing replay protection and liveness proof.
The GROUPKEY-PUSH is a single-message rekey datagram initiated by the GCKS (typically via IP multicast): HDR*, SEQ, [D,] SA, KD, SIG. Payloads after the HDR are encrypted with the current KEK; the SIG payload authenticates the unencrypted content before encryption.
The Sequence Number (SEQ) payload carries a monotonically increasing counter associated with the KEK, providing anti-replay state for GROUPKEY-PUSH messages. The counter resets to 1 when a new KEK attribute is introduced; the first GROUPKEY-PULL distributes the current sequence number (zero if no rekeys have occurred).
GDOI defines new ISAKMP payload type values: SA KEK (SAK)=15, SA TEK (SAT)=16, Key Download (KD)=17, Sequence Number (SEQ)=18, Group Associated Policy (GAP)=22. The GDOI DOI value is 2. Exchange Type 32 is GROUPKEY-PULL; Exchange Type 33 is GROUPKEY-PUSH. UDP port 848 is assigned for GDOI.
RFC 6407 creates or updates IANA registries for: KEK Management Algorithm (LKH=1), KEK Algorithm (DES=1, 3DES=2, AES=3), SIG Hash Algorithm (MD5=1, SHA1=2, SHA256=3, SHA384=4, SHA512=5), SIG Algorithm (RSA=1, DSS=2, ECDSS=3, ECDSA-256=4, ECDSA-384=5, ECDSA-521=6), GAP Attributes (ACTIVATION_TIME_DELAY=1, DEACTIVATION_TIME_DELAY=2, SENDER_ID_REQUEST=3), SA TEK Protocol-IDs (ESP=1, AH=2), and KD Types.
The GCKS SHOULD NOT use the same signing key for the GROUPKEY-PUSH SIG payload as was used for Phase 1 authentication in the GROUPKEY-PULL exchange. Reusing a key across multiple protocol contexts weakens security through cross-context signature ambiguity.
Upon receiving a GROUPKEY-PUSH datagram, a group member MUST validate the SEQ payload sequence number against the previously received value and MUST verify the SIG payload signature; messages failing either check MUST be discarded. SIG verification uses the public key distributed during GROUPKEY-PULL.
Without explicit GCKS authorization using a GPAD, a rogue GDOI participant can execute a man-in-the-middle attack between a group member and a GCKS. Both sides must verify identity: the GM checks the GCKS against its GPAD; the GCKS authorizes the GM by Phase 1 identity before providing group keying material.
The GROUPKEY-PUSH SIG payload covers a hash computed over the literal string 'rekey', the GROUPKEY-PUSH ISAKMP HDR, and all payloads preceding the SIG payload, taken over the unencrypted content. The prefixed string ensures this signature cannot be replayed in any other GDOI protocol context.
The Key Download (KD) payload contains: Next Payload (1 octet), RESERVED (1 octet), Payload Length (2 octets), Number of Key Packets (2 octets), RESERVED2 (2 octets), and variable Key Packets. Each Key Packet has: KD Type (1 octet), RESERVED (1 octet), KD Length (2 octets), SPI Size (1 octet), SPI (variable), and Key Packet Attributes (variable). KD Types: TEK=1, KEK=2, LKH=3, SID=4.
The SA KEK payload contains: Next Payload (1 octet), RESERVED (1 octet), Payload Length (2 octets), Protocol (1 octet), SRC ID Type/Port/Data-Len/Data fields, DST ID Type/Port/Data-Len/Data fields, SPI (16 octets — the ISAKMP cookie pair for the Rekey SA), RESERVED2 (4 octets), and variable-length KEK Attributes in ISAKMP TV/TLV format.
The SA TEK ESP/AH protocol-specific payload contains: Protocol (1 octet), SRC ID Type (1 octet), SRC ID Port (2 octets), SRC ID Data Len (1 octet), SRC Identification Data (variable), DST ID Type (1 octet), DST ID Prot (1 octet), DST ID Port (2 octets), DST ID Data Len (1 octet), DST Identification Data (variable), Transform ID (1 octet), SPI (4 octets), and RFC 2407 SA Attributes.