Summary

  • RFC 9838's baseline forward-access-control sequence separates a membership-changing KEK rekey from the later delivery of new TEK policy and keys under the new KEK. Removing a member from a list is therefore not the same event as completing cryptographic exclusion.
  • Multicast GSA_REKEY is unacknowledged and may be lost. Repeated bitwise-identical messages and GSA_NEXT_SPI help, but they do not turn a one-way distribution mechanism into member-by-member proof of installed state.
  • ATD and DTD deliberately separate activation of new Security Associations from deletion of old ones. An exclusion claim needs bounded timing and observed receipts across that overlap, not only a controller audit entry.

The member disappeared from the roster at 10:00. At 10:00:01, someone closed the ticket. Neither fact says when the old group key stopped working.

RFC 9838, published in November 2025, specifies Group Key Management Using IKEv2, or G-IKEv2. Its RFC Editor record identifies it as Standards Track and says it obsoletes RFC 6407. That is evidence of a completed specification. It is not evidence that a particular key server excluded a particular member.

The protocol sits within the multicast security architecture described by RFC 3740, RFC 4046 and RFC 5374. A Group Controller/Key Server, or GCKS, authenticates and authorizes a Group Member. It then distributes a Group Security Association containing policy and keying material for Data-Security SAs and, where used, a multicast Rekey SA.

This architecture has two broad phases. Registration establishes the relationship and initial state. Rekeying changes that state after membership, policy, algorithms, lifetimes or keys change. IKEv2 supplies the bilateral security machinery; IPsec, AH and ESP supply the surrounding Security Association vocabulary and packet protection. G-IKEv2 has to extend those semantics to a group whose members do not all answer the same message.

The old KEK cannot safely introduce the new TEK

RFC 9838 distinguishes forward access control from backward access control. Forward access control denies a removed member access to a new group key. Backward access control denies a newly admitted member access to an old group key. The RFC explicitly says this is unrelated to IKEv2 Perfect Forward Secrecy.

The hard part is the transition. When a rekey message changes group membership, it is still protected under key-encryption state known to the old group. If that same message carried the new Traffic-Encryption-Key policy and keys, the member being removed could read them. The specification therefore says that, when forward access control is desired, the membership-changing rekey must not include the new TEK material. A second rekey can carry it because that later message is protected by the new KEK.

If the policy itself must also be hidden from the removed member, the rule is stricter: the GCKS sends two sequential rekeys that change the group KEK. The first creates a KEK unavailable to the excluded member, though the old member can still see the policy conveyed under the current KEK. The next message changes policy and KEK again. A policy change may not ride without a new KEK.

This is not a universal claim that every conceivable group algorithm forever needs two messages. RFC 9838 permits future LKH variants or other methods to remove the multiple-message restriction if they specify how a single rekey preserves forward access control. RFC 2627 provides the logical-key-hierarchy background. The present operational point is narrower: an implementation using the specified baseline sequence cannot collapse an administrative removal, KEK transition and TEK transition into one line in a dashboard.

Multicast sends state without collecting state

G-IKEv2 can rekey through a unicast in-band exchange or a multicast GSA_REKEY. The multicast form is a one-way pseudo-exchange. It is not acknowledged. The network can discard the message, leaving one or more continuing members on old policy.

The GCKS may mitigate loss by transmitting several encrypted copies. Those copies must be bitwise identical and should be sent within a few seconds so that Security Association lifetime calculations do not diverge materially among recipients. It may also advertise future SPIs using GSA_NEXT_SPI, allowing listening members to detect a missed rekey and recover.

Those mechanisms improve delivery. They do not prove universal installation. A send log proves emission. A duplicate-send log proves more emission. A future-SPI alarm proves that one listener noticed a gap. None by itself supplies the exact installed state of every member at a particular instant.

RFC 7383 exposes the same asymmetry for fragmentation. A multicast GCKS cannot first send an unfragmented rekey and wait to learn whether fragmentation is required, and it cannot use the response-based PMTU mechanism. It must operate from a preconfigured threshold. Group size, key hierarchy and payload growth therefore turn message construction and network loss into part of the exclusion boundary.

Activation and deletion are different clocks

RFC 9838 defines Activation Time Delay, ATD, as the period senders wait after receiving new SAs before transmitting with them. Deactivation Time Delay, DTD, is the period members wait after a deletion request before removing old Data-Security SAs. The two controls acknowledge distributed reality: receivers need time to obtain the new state, while old state may remain temporarily usable.

That overlap may be necessary for availability, but it makes the word “removed” time-dependent. Useful evidence names at least five instants: authorization revoked, new KEK created, new TEK installed, new SA activated, and old SA deleted. A traffic probe can add a sixth: the last moment the excluded member could successfully participate.

Counter-based encryption adds another state ledger. RFC 6054 informs the Sender-ID method. RFC 9838 requires unique sender assignments and fresh Sender-IDs on registration because the GCKS cannot reliably know which nonce values a sender already used. If the Sender-ID counter is exhausted, the server must exclude every member and force re-registration with new Data-Security SAs. Algorithm requirements such as RFC 8221 and implicit-IV methods such as RFC 8750 do not remove that lifecycle duty.

Replay protection also refuses a convenient fiction. When many senders share one multicast SA, each advances its own sequence number, so a single meaningful replay window may be impossible. The receiver chooses locally whether to check replay. The GCKS can create separate SAs per sender when stronger replay properties justify the scale cost. “Group protected” is not a sufficient description; sender topology and receiver policy matter.

The IANA IKEv2 parameters registry records the protocol's assigned values. RFC 8174 explains the normative force of words such as MUST. Neither registry entries nor capitalized requirements reveal whether this deployment completed the required sequence. RFC 6407 remains useful as the obsoleted predecessor; it is not a receipt for the new protocol.

Heng Lu's argument for a minimum initial specification and localized future decision fits this boundary. The shared protocol should define safe semantics; the operator must decide the acceptable exclusion deadline and pay for the telemetry that proves it. Running-code primacy makes installed key state and observed traffic more authoritative than a completed ticket. Reality-first reporting keeps a Standards Track document from being marketed as a deployed guarantee.

Sources