Group Key Management Using the Internet Key Exchange Protocol Version 2 (IKEv2)
obsoletes
- rfc-6407 — The Group Domain of Interpretation
Extracted elements (29)
All key management complexity is confined to the GCKS; GM behavior is identical regardless of whether a simple key delivery or a hierarchy such as LKH is used. Keys are always transmitted as wrapped ciphertext with Key ID and KWK ID fields, so GMs can use a uniform decryption procedure without knowledge of the specific key management algorithm employed.
G-IKEv2 replaces GDOI (RFC 6407) because GDOI is based on IKEv1, which has been deprecated. Building on IKEv2 provides simplicity, increased robustness, cryptographic improvements, and compatibility with the growing ecosystem of IKEv2 extensions, including post-quantum security and modern EAP methods.
The SAg payload is optional but RECOMMENDED so that the GCKS can select group policy compatible with all members. Unlike the IKEv2 SA payload, SAg proposals are not negotiated; the GM merely advertises constraints. The AEAD/non-AEAD mixing restriction from RFC 7296 Section 3.3 does not apply to SAg, allowing a GM to freely list all supported transforms.
G-IKEv2 is compatible with most existing IKEv2 extensions, including IKE_INTERMEDIATE exchanges (RFC 9242) for use during registration, IKE fragmentation (RFC 7383) for large GSA_REKEY messages, TCP encapsulation (RFC 9329) for the unicast registration SA, and post-quantum preshared key mixing (RFC 8784). It is NOT RECOMMENDED to create unicast Child SAs over the registration IKE SA, as authentication requirements may differ.
G-IKEv2 MAY use UDP port 848, the same port used by GDOI (RFC 6407), because they serve similar functions. The IKE Major Version field (2 for G-IKEv2 vs. 1 for GDOI) distinguishes the two protocols. The GM and GCKS behavior MUST NOT depend on which port was used to create the initial IKE SA.
A GM intending to act as a group sender MUST include a GROUP_SENDER Notify payload in its GSA_AUTH or GSA_REGISTRATION request. This signals sender intent and enables the GM to request Sender-ID values when the group policy includes a counter-mode cipher.
Encryption transforms that rely on Sequence Numbers for IV construction (implicit IV transforms, per RFC 8750) MUST NOT be used for any G-IKEv2 SA — unicast or multicast — unless sequence number uniqueness is guaranteed. Such transforms require anti-replay service, which is not reliably achievable in multicast groups with multiple senders.
For forward access control, a new TEK policy and associated keys MUST NOT be included in the rekey message that changes group membership (changes the KEK). A subsequent rekey message protected under the new KEK must deliver new TEK policies, ensuring excluded members cannot access new data-plane keys.
GMs MUST install the Rekey SA only in the inbound direction. If a GM is not a sender for a Data-Security SA, it MUST install that SA only in the inbound direction; if it is a sender and does not receive its own data, it MUST install the SA only in the outbound direction.
If the IKE SA is closed and no GIKE_UPDATE policy was received during registration, the GM MUST consider itself excluded from the group and must re-register. By convention, the GCKS closes the IKE SA; the GM SHOULD NOT close it unilaterally.
The AUTH payload MUST be included in GSA_REKEY messages when the authentication method uses public key signatures, and MUST NOT be included when implicit authentication (ICV-based) is used. Using implicit authentication for GSA_REKEY is NOT RECOMMENDED because it does not provide source origin authentication.
The GCKS MUST include the Sequence Numbers transform in the GSA payload for every Data-Security SA. A new Transform ID '32-bit Unspecified Numbers' signals that sequence number uniqueness is not guaranteed, allowing GMs to decide locally whether to enable anti-replay service.
The GSA_INITIAL_MESSAGE_ID attribute value MUST be checked by a GM against previously received Message IDs for that group; if less than the previously received number, it MUST be ignored as stale. The first GSA_REKEY message MUST have a Message ID greater than or equal to this attribute, and subsequent messages MUST have strictly increasing IDs, providing replay protection.
The IKEv2 windowing mechanism (Section 2.3 of RFC 7296) MUST NOT be used for GSA_REKEY messages, since they are sent to multiple GMs without expecting responses. Retransmitted GSA_REKEY copies MUST be bitwise identical and sent within a short time interval to avoid skewing SA lifetime calculations.
When the GCKS Sender-ID counter reaches its final value, the GCKS MUST exclude all GMs from the group before distributing any new Sender-ID values, forcing re-registration so that new Sender-IDs are paired with new Data-Security SAs with fresh keys, preventing nonce reuse.
G-IKEv2 defines four new IKEv2 exchange types: GSA_AUTH (initial registration combining authentication and key distribution), GSA_REGISTRATION (subsequent registration over an existing IKE SA), GSA_REKEY (one-way multicast pseudo-exchange for group rekeying), and GSA_INBAND_REKEY (unicast rekey over the existing registration IKE SA). Four new payloads are introduced: IDg, SAg, GSA, and KD.
The Group Identification (IDg) payload uses the IKEv2 Identification Payload format to indicate which group the GM wishes to join. ID type ID_KEY_ID MUST be supported; ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, and ID_IPV6_ADDR SHOULD be supported; ID_DER_ASN1_DN and ID_DER_ASN1_GN are not expected to be used. The Payload Type is 50.
The Group Security Association (GSA) payload (Payload Type 51) carries group policy from the GCKS to GMs. It contains zero or one GSA KEK policy (Rekey SA), zero or more GSA TEK policies (Data-Security SAs), and zero or one Group-Wide (GW) policy. At least one TEK or KEK policy MUST be present. The substructure type is determined by the first octet: zero for GW policy, non-zero (security protocol ID) for SA policies.
The GSA_AUTH exchange authenticates the IKE_SA_INIT and registers the GM with the GCKS. The GM sends IDi, optional CERT/CERTREQ/IDr, AUTH, IDg (group to join), optional SAg (supported transforms), and optional GROUP_SENDER notify. The GCKS responds with IDr, optional CERT, AUTH, GSA (group policy), and KD (keying material), or returns INVALID_GROUP_ID, AUTHORIZATION_FAILED, or REGISTRATION_FAILED on error.
The GSA_INBAND_REKEY exchange is a normal IKEv2 request-response exchange initiated by the GCKS over the unicast IKE SA from registration. It carries GSA, KD, and optional N payloads; the GM responds with an empty SK payload. This provides reliable, individually-addressed policy updates for small groups without a separate multicast Rekey SA.
The GSA_REKEY pseudo-exchange is a single one-way IKEv2 message sent by the GCKS to GMs, typically via IP multicast. The 'IKE SA Initiator's SPI' and 'IKE SA Responder's SPI' fields in the IKE header are treated as a single 16-octet field containing the Rekey SA SPI. The message contains GSA, KD, optional Delete, and optional AUTH payloads.
The Key Download (KD) payload delivers keying material from the GCKS to GMs. It contains key bags: Group Key Bags carry keys common to all GMs, and Member Key Bags carry per-GM keys (e.g., individual LKH node keys). All keys are transmitted in encrypted (wrapped) form using a Key Wrap Key (KWK), with a 32-bit Key ID and 32-bit KWK ID in each wrapped key structure.
The Sender-ID mechanism assigns each group sender a unique portion of the IV space for counter-based cipher modes (AES-CTR, AES-GCM, AES-CCM, ChaCha20-Poly1305, AES-GMAC). The GCKS maintains a sequential counter and allocates one or more Sender-ID values per registering sender via a GROUP_SENDER Notify payload. Sender-IDs occupy the most-significant bits of the IV as configured by the GWP_SENDER_ID_BITS attribute.
RFC 9838 creates new IANA registries for G-IKEv2 (Section 9.1) and modifies existing IKEv2 registries (Section 9.2). New assignments include exchange types for GSA_AUTH, GSA_REGISTRATION, GSA_REKEY, and GSA_INBAND_REKEY; payload types 50 (IDg) and 51 (GSA); new Transform Types GCAUTH (Group Controller Authentication Method) and KWA (Key Wrap Algorithm); a Security Protocol Identifier GIKE_UPDATE (value 6); and new Notify message types including INVALID_GROUP_ID, AUTHORIZATION_FAILED, REGISTRATION_FAILED, and GROUP_SENDER.
Complete forward access control requires two sequential GSA_REKEY messages: the first changes the KEK (excluded members can still decrypt this message but not future ones), and the second delivers changed group policy under the new KEK, making policy changes invisible to excluded members. A single rekey cannot atomically achieve both.
Replay protection for multicast Data-Security SAs is not always achievable. When multiple group senders share an SA, each independently increments the ESP/AH sequence number, making replay detection impossible for receivers. The GCKS should create separate SAs per sender when replay protection is required and can limit the sender count via policy.
The GSA_REKEY authentication using digital signatures covers both the IKE header and the plaintext inner payloads before encryption, preventing modification of group policy in transit. The GCKS distributes an explicit AUTH_KEY to GMs during registration for verifying subsequent rekey messages; the key is rotated in future rekey messages before expiry.
GSA_REKEY authentication signs two chunks: Chunk A (adjusted IKE header concatenated with the Encrypted Payload header, with Length fields reduced to exclude IV, padding, and ICV) and Chunk P (inner plaintext payloads of the Encrypted Payload). The AUTH payload's Authentication Data field is zeroed during signing, but ASN.1 Length and AlgorithmIdentifier fields must be correctly filled. DataToAuthenticate = A | P.
The Group SA Policy Substructure encodes: Protocol (1 octet: 6=GIKE_UPDATE, 2=AH, 3=ESP), SPI Size (1 octet: 16 for GIKE_UPDATE, 4 for AH/ESP), Length (2 octets, unsigned), SPI (variable), Source Traffic Selector (variable), Destination Traffic Selector (variable), Group SA Transforms (variable), and Group SA Attributes (variable). For GIKE_UPDATE, the 16-octet SPI maps to the two 8-octet IKE header SPI fields in GSA_REKEY messages.