Summary

  • RFC 9594 separates an Authorization Server's permission to approach a group-membership resource from the KDC's decision to complete a Join and return application-profile-defined keying material.
  • A token, a member record, a returned key version and a successful group operation are four different facts; audit systems that collapse them manufacture certainty precisely where distributed state can diverge.

A constrained device asks to join a group. An Authorization Server approves its scope and roles. A signed token arrives. In a dashboard built around policy decisions, the story can appear complete: identity evaluated, permission granted, control green.

RFC 9594 refuses that shortcut. The token permits the Client to approach a resource at a Key Distribution Center. The KDC must receive the token, establish the secure association required by the selected ACE transport profile, verify the later Join Request against the stored authorization and then return the keying material and configuration defined by an application profile. Only the successful Join handler adds the Client to the current-member set.

The distinction is not bureaucratic layering. It is an exact description of where authority stops and running state begins.

Authorization and admission are different transactions

RFC 9594 divides provisioning into two phases. The first follows the ACE framework among Client, Authorization Server and KDC, with the KDC acting as the ACE Resource Server. The second is the actual distribution of group keying material between Client and KDC and is not itself the ACE authorization phase.

The Authorization Server applies policy. It decides whether the Client may access one or more group-membership resources and which roles it may request. The Client transfers the resulting token to the KDC, typically through /authz-info. The Client and KDC then have to establish or continue a secure association under a transport profile such as the DTLS or OSCORE profile of ACE.

None of those events is the Join. For that, the Client posts to /ace-group/GROUPNAME. The KDC compares the request with the stored authorization, checks the requested group and roles, and performs the base-specification and application-profile validations. A successful result adds the Client to the member list and returns the material required for protected group communication.

This produces a useful negative statement: a valid token is not a membership receipt. It does not prove that the KDC received it, that the secure association survived, that a Join Request followed, that the requested roles matched, that credential proof succeeded, that the KDC created the node resource or that the Client installed the returned state.

The KDC is not merely a key vending machine

The interface describes a stateful control surface. /ace-group/GROUPNAME is the membership resource. Per-member resources appear below /nodes/NODENAME. Separate handlers expose current group keying material, peer credentials, KDC credentials, policies, individual material, leaving and eviction operations.

Names and cryptographic state are deliberately not the same thing. GROUPNAME is invariant once the resource exists. A node name is unique among current nodes and its URI form is invariant once established. But the group identifier and the key material can change as the group evolves. A durable path can therefore point to a group whose current cryptographic epoch is not the one a Client possesses.

The num parameter makes that boundary visible. It carries the version of current group keying material. It also accompanies credential retrieval, so that peer credentials are interpreted against a stated group-key version. A record saying “member of group X” without the profile identifier, key version, installation result and expiry context is not a complete operational statement.

RFC 9594's reported erratum 8239 is instructive without being inflated into an incident. The published example for retrieving credentials omitted the required num field; the erratum adds it. Another reported technical erratum clarifies malformed credential filters. These are specification-maintenance records, not evidence that a particular product failed. They do show why version context belongs beside credential evidence rather than in an operator's memory.

The base RFC leaves a real contract to application profiles

RFC 9594 supports different group-communication and protection approaches. It standardizes the KDC interface, generic CBOR structures and a set of registries, but requires application profiles to complete the security contract.

The profile defines the group key type and encoding, group and node identifiers, profile identifier, peer credential representation, proof-of-possession methods, policy values, supported KDC resources, rekey protection and client capabilities. The application/ace-groupcomm+cbor media type says how the envelope is identified. An ACE Groupcomm profile registry value names the selected specialization. Neither field invents the missing behavior.

That is minimum initial specification used honestly: standardize what must interoperate, localize what depends on a concrete group-security approach, and require the specialization to expose its choices. It becomes unsafe only when a system displays “RFC 9594 compliant” while hiding which profile, which parameter set and which checks are actually running.

Key distribution can create a temporary split reality

Membership is not static. Group keying material expires and may be renewed periodically. Membership change may also trigger renewal. Backward security can require new material when a member joins, so the new member cannot recover protected traffic from before entry. Forward security can require new material when a member leaves or is evicted, so old state cannot read future traffic.

The KDC increments NUM before distributing version NUM+1. Distribution can require multiple messages addressed to different members. RFC 9594 explicitly recognizes temporary misalignment: some members may have the new material while others still hold the old version. After the rekey completes, the KDC deletes the old material and should persist the new state.

This Article does not reopen RFC 9838's distinct KEK-then-TEK exclusion sequence. The RFC 9594 point is narrower: even under this general interface, a KDC-side increment and an administrative member list cannot prove simultaneous installation across the group. Version, delivery, verification and local activation need their own receipts.

A Dispatcher carries traffic but does not certify the group

After authorization and joining, a Client may participate through a Dispatcher. In multicast, that function can be implicit in the transport. In publish-subscribe or relay designs, it can be an explicit intermediary. RFC 9594 treats an explicit Dispatcher like an untrusted on-path entity: it can see protected messages and distribute them, but it does not have the group keying material.

Delivery position is therefore not membership authority. A broker can carry a message without being able to validate its plaintext. A relay can reach several destinations without proving that they share the same current key version. A Client can hold valid material without proving that a later application message was delivered or accepted.

RFC 10020 coverage already owns the next boundary—protected Group OSCORE message versus receiver-local action. Here the control question ends earlier: what evidence shows that authorization became membership and that membership became installed profile-specific state?

Preserve a transition ledger, never the secret

The audit record should follow the state machine without logging key material. Preserve a token identifier or hash, issuer, audience, scope, roles and expiry; the KDC token-transfer result; the transport profile and secure-association identity; the Join Request identifier; requested and granted roles; GROUPNAME; NODENAME; application-profile identifier; num; credential and proof-of-possession result; key-install success; policy version; refresh or rekey timestamps; and the last confirmed application use.

Each record should name the actor that can assert it. The AS can attest its policy decision. The KDC can attest its validation, member record and distributed version. The Client can attest receipt, verification and installation. A Dispatcher can attest forwarding observations. The application can attest acceptance and effect. No central green check should speak for all five.

This is the reality-layer discipline in docs/heng-lu-note.md. A record can describe a decision without creating the next reality. The most authoritative artifact at the start of a chain does not acquire magical custody over the end of the chain. Running code remains the proof that a permitted transition was actually implemented.

Sources