The Group Domain of Interpretation
obsoleted by
- rfc-6407 — The Group Domain of Interpretation
Extracted elements (32)
GDOI uses a separate UDP port (848) instead of IKE's port 500 because it is a distinct protocol with its own DOI and exchange types, and conflating the two would create ambiguity in demultiplexing.
LKH (Logical Key Hierarchy) is specified as an OPTIONAL group management algorithm supporting forward and backward access control; other algorithms (OFT, Subset Difference) are acknowledged but require a future Standards Action to be added to GDOI.
The GCKS cookie pair is used as an SPI in GROUPKEY-PUSH to differentiate secure groups managed by the same GCKS, rather than negotiating cookies as in ISAKMP/IKE, because the GCKS unilaterally manages group identity.
The GROUPKEY-PUSH SIG payload covers hash("rekey" | message) and the POP payload covers hash("pop" | Ni | Nr) with distinct prefixes to prevent cross-protocol signature reuse between GROUPKEY-PUSH authentication and GROUPKEY-PULL membership authorization.
The GDOI PROTO_IPSEC_ESP TEK excludes the Group Description SA attribute from RFC 2407; a GDOI implementation MUST NOT send it and MUST ignore it if received, since multicast group description is conveyed through the GDOI ID payload instead.
A GDOI implementation MUST support the KEK_ALG_3DES algorithm attribute for key-encrypting keys.
A GDOI implementation MUST support the SIG_ALG_RSA signature algorithm attribute for GROUPKEY-PUSH message signing.
A GROUPKEY-PUSH message MUST NOT change the group policy without creating a new KEK; if full forward access control is required, two sequential GROUPKEY-PUSH messages changing the KEK MUST be sent.
GDOI MUST NOT run on port 500 (the port commonly used for IKE); IANA has assigned port 848 for GDOI.
If forward access control is desired, new SA_TEKs and associated key packets in the KD payload MUST NOT be included in a GROUPKEY-PUSH message that changes group membership; they must be delivered in a subsequent GROUPKEY-PUSH protected by the new KEK.
If the KEK_ALGORITHM_KEY mode of operation requires an Initialization Vector (IV), an explicit IV MUST be included in the KEK_ALGORITHM_KEY attribute before the actual key.
The GCKS MUST NOT update the group management state (e.g., LKH key tree) until it receives the third message of the GROUPKEY-PULL exchange with a valid HASH payload including its own nonce.
The GDOI GROUPKEY-PUSH Flags field MUST have the Encryption bit set; all other flag bits MUST be set to zero, and Message ID MUST be set to zero.
The GDOI MUST be protected by a Phase 1 security association providing peer authentication, confidentiality, and message integrity.
The Phase 1 SA payload DOI value MUST be the GDOI DOI value (2) as defined in this document.
The Responder MUST NOT compute the shared Diffie-Hellman number or install new SAs until it receives a message with the initiator's nonce Nr included properly in the HASH payload, ensuring liveliness is proven before state is committed.
The SEQ payload MUST be present in GROUPKEY-PULL if the SA payload contains an SA KEK attribute; the member MUST check that the sequence number is greater than any previously received sequence number before installing new SAs.
Six new ISAKMP payload types are defined: SA KEK (SAK, type 15), SA TEK (SAT, type 16), Key Download (KD, type 17), Sequence Number (SEQ, type 18), and Proof of Possession (POP, type 19), in addition to reuse of SA (1), ID (5), and Nonce (10).
The GROUPKEY-PULL is a four-message Phase 2 exchange between a group member (initiator) and GCKS (responder) that downloads Re-key SA KEKs and/or Data-security SA TEKs under Phase 1 protection.
The GROUPKEY-PUSH is a one-way datagram sent from the GCKS (or delegate) to group members to replace a Re-key SA KEK/KEK array and/or create new Data-security SAs; it is protected by the group Re-key SA KEK and authenticated by a SIG payload.
The Proof of Possession (POP) payload is an ISAKMP SIG payload where the signature covers POP_HASH = hash("pop" | Ni | Nr), ensuring the signature cannot be reused for any other purpose in the GDOI protocol.
The SA KEK (SAK) payload carries KEK security attributes including KEK_MANAGEMENT_ALGORITHM, KEK_ALGORITHM, KEK_KEY_LENGTH, KEK_KEY_LIFETIME, SIG_HASH_ALGORITHM, SIG_ALGORITHM, SIG_KEY_LENGTH, and KE_OAKLEY_GROUP, plus source/destination identities and a 16-octet SPI (ISAKMP cookie pair).
This document registers GDOI DOI value 2 in the ISAKMP Domain of Interpretation registry, five new ISAKMP payload type values (SAK=15, SAT=16, KD=17, SEQ=18, POP=19), and UDP port 848 for exclusive GDOI use.
GDOI assumes the network is insecure and potentially under complete attacker control, but assumes host computers are secure; the security guarantee depends entirely on group members protecting authenticators, encryption keys, and message authentication keys.
Replay protection for GROUPKEY-PUSH relies on the SEQ payload sequence number and a sliding receive window; implementations SHOULD keep a record of recently received sequence numbers and SHOULD NOT accept messages with sequence numbers below the window.
The GCKS SHOULD NOT use the same key to sign the GROUPKEY-PUSH SIG payload as was used for the GROUPKEY-PULL POP payload; if the same key must be used, a different hash function SHOULD be used.
The Phase 1 encryption strength SHOULD exceed that of the keys sent in the GROUPKEY-PULL protocol, since Phase 1 is the protection envelope for key delivery.
The Identification Payload uses a 1-octet ID Type field; for GDOI, ID_KEY_ID (value 11) specifies a 4-octet group identifier. Values 0-10 and 12-127 are reserved.
The Key Download (KD) Payload header contains a 2-octet Number of Key Packets field, followed by Key Packets each with a 1-octet KD Type (TEK=1, KEK=2, LKH=3), 1-octet RESERVED, 2-octet KD Length, 1-octet SPI Size, variable SPI, and variable Key Packet Attributes.
The LKH_DOWNLOAD_ARRAY attribute carries individual LKH keys each with 2-octet LKH ID, 1-octet Key Type, 1-octet RESERVED, 4-octet Key Creation Date, 4-octet Key Expiration Date, 4-octet Key Handle, and variable Key Data (with explicit IV prepended if required by the algorithm).
The SA TEK (SAT) payload for PROTO_IPSEC_ESP (Protocol-ID=1) includes source/destination identity fields, a 1-octet Transform ID, a 4-octet SPI for ESP, and RFC 2407 SA attributes; the Group Description attribute MUST NOT be sent.
The Sequence Number Payload (SEQ) contains a 4-octet monotonically increasing counter initialized to zero by the GCKS; the first GROUPKEY-PUSH has sequence number 1, and receivers MUST maintain a sliding window per RFC 2406 Section 3.4.3.