RFC 9820: EAP Success Still Needs a Protected Witness

Summary

RFC 9820 does not treat an EAP method result as the whole session. The authenticator must derive an OSCORE context and send a protected success message; the peer must verify it and return a separately protected 2.04 Changed before both sides have bilateral key-confirmation evidence.
A shared protected context is still not permission to use every application resource. Bootstrapping authorization, additional application policy, session lifetime, re-authentication and forced deletion remain separate decisions with separate owners.
The minimum audit unit joins ordered CoAP resource generations, EAP result, non-secret key lineage, negotiated algorithms, Recipient IDs, protected Steps 7 and 8, effective resource policy, state generation, deletion acknowledgements and independently observed traffic.

The dashboard promoted a method result into a domain fact

The incident did not begin with broken cryptography. It began with an overconfident status model.

An operations console received an EAP method result from the authentication path. It also learned that an MSK had been exported. The console changed the device state from “authenticating” to “admitted.” A downstream policy engine then treated that state as permission to open a telemetry resource. Later, investigators could establish that the EAP exchange had completed at the authenticator, but not that the peer had accepted the protected success message, derived the same context or been authorized for that telemetry stream.

The system had recorded a real event and attached too much meaning to it.

RFC 9820 defines an authentication service that carries the Extensible Authentication Protocol over the Constrained Application Protocol. A constrained IoT device acts as the EAP peer and hosts the CoAP service. A Controller acts as the EAP authenticator and normally sends CoAP requests. It may consult a backend AAA server in pass-through mode.

This role reversal matters. The device is the CoAP server for the authentication service even though it is the EAP peer. The Controller is the CoAP client even though it is the EAP authenticator. A log that says only “client authenticated” is already ambiguous about which protocol role produced the statement.

The RFC Editor information record and Datatracker record classify RFC 9820 as an IETF Standards Track document published in September 2025 by the ACE Working Group. That status establishes a reviewed specification. It does not establish that a named product implements it, that a particular device joined a domain, or that an application action was authorized.

Ordering is carried by disposable resources

CoAP-EAP does not move through one permanent endpoint while an invisible counter advances. Each authentication step addresses a new resource on the EAP peer. When the peer processes a request, it creates the resource for the next step and deletes the previous one. The Location-Path or Location-Query carried in the CoAP response points to the next acceptable state.

That design turns resource generation into part of the transcript. A message for an erased resource is not automatically the current message. A duplicated initial trigger during an ongoing authentication must be silently discarded. An old trigger arriving after no session remains can start what the authenticator thinks is a new exchange, only for the peer to answer that the expected resource does not exist.

RFC 7252 supplies CoAP's request, response and reliability semantics. RFC 4137 describes EAP peer and authenticator state machines. RFC 9820 composes them, but composition does not erase either state machine.

An operational record therefore needs more than a session label. It needs the peer and authenticator identities in their protocol roles, the current resource generation, the previous resource retired, the request and response identifiers, the EAP state transition, the transport observation and the clock. If a retry lands on a different generation, the record must say whether it was rejected, discarded or interpreted as a new authentication.

The protocol permits one ongoing authentication between a particular peer and authenticator. That constraint limits parallel ambiguity for the pair. It does not prevent the authenticator from running many peers at once, nor does it prove that two databases agree about which pair and generation are current.

Step 7 is not ornamental wrapping

The decisive boundary arrives after the EAP method succeeds.

In Step 7, the authenticator obtains the MSK exported by the EAP method, an EAP Success message and authorization information such as Session-Lifetime. Under the EAP Key Management Framework in RFC 5247, the method must provide fresh keying material with the required properties. RFC 9820 requires a method that exports an MSK and EMSK of at least 64 octets.

The presence of an MSK at the authenticator is not yet proof that the peer and authenticator have installed compatible application protection. RFC 9820 derives the OSCORE Master Secret and Master Salt from the MSK, the cipher-suite negotiation and defined context strings. Recipient IDs exchanged earlier determine the sender and recipient contexts at the two endpoints. RFC 5869 defines HKDF, while RFC 8613 defines the OSCORE context that protects CoAP messages.

The authenticator then sends EAP Success in an OSCORE-protected POST. The peer treats reception of this protected message as an alternate indication of success. Its EAP state machine returns the MSK, and the peer uses the same inputs to derive the context needed to verify the request.

This is not decorative encryption applied after the meaningful event. The protected request is a witness. If the peer cannot derive a compatible context, it cannot verify the message that tells it the authentication succeeded.

Step 8 is the second witness

After the peer has both a successful EAP result and a verified Step 7 request, it returns an OSCORE-protected 2.04 Changed. Correct verification of the protected Step 7 request and Step 8 response confirms that the two parties have the same Master Secret.

The distinction is operationally sharp:

the authenticator's EAP method result says what its authentication process concluded;
MSK export says fresh key material became available to that process;
successful context derivation says local inputs produced a candidate security context;
peer verification of Step 7 says the peer could use a compatible context for the authenticator's protected message;
authenticator verification of Step 8 says the return witness was protected under the same bilateral context.

One green indicator should not stand for all five.

The cipher-suite negotiation is part of the derivation. If an attacker changes the negotiation, the two endpoints derive different contexts and Steps 7 and 8 fail. The control is stronger because the negotiation is not merely logged beside the key derivation; it affects the derived secret. The IANA CoRE Parameters registry and IANA EAP parameters make codepoints discoverable, but registry entries do not prove what a running endpoint selected or enforced.

A defensible receipt records the offered and selected algorithm identifiers, the exact transcript fingerprint, the two Recipient IDs, the EAP session identity, the method result, derivation-generation identifiers that reveal no secret, Step 7 verification, Step 8 verification and the implementation versions that executed those transitions. It must never log the MSK merely to make the audit look complete.

Shared protection does not grant every resource

After Step 8, communication with the last authentication resource must be protected by OSCORE. RFC 9820 says the same context may protect other resources between the endpoints if application policy permits it.

The conditional phrase is the authorization boundary.

Authentication asks whether the presented process and method support an identity or credential conclusion. Key confirmation asks whether both endpoints hold compatible derived protection. Application authorization asks whether this peer, under current conditions, may read or change this resource. Those questions can share inputs without sharing jurisdiction.

RFC 9820 makes authorization part of bootstrapping: may the peer join, and under what conditions? With AAA, authorization data can come from the organization responsible for the peer and travel through RADIUS or Diameter. In standalone mode it lives at the authenticator. After bootstrapping, additional authorization can be required. RFC 9200 is one ACE mechanism for OAuth-based authorization in constrained environments.

A Controller that possesses the MSK does not thereby own the organization's policy. A backend AAA server that supplies attributes does not prove the authenticator enforced them. A valid OSCORE request does not prove that the target resource was in the permitted set. The application receiving the request remains an authority over its own action and outcome.

During authentication, RFC 9820 permits the IP connectivity needed to carry CoAP-EAP, but says unprotected traffic must be limited to that authentication exchange. After success, other traffic can be authorized when protected. A firewall rule that opens a broad subnet because “EAP succeeded” defeats the boundary the protocol describes.

Re-authentication creates two presents

Key material has a lifetime. RFC 9820 uses an eight-hour default when Session-Lifetime is not sent, following RFC 5247's recommendation, and requires renewal before expiry. The number is a protocol default, not evidence that every operator should use eight hours.

During re-authentication, the current CoAP-EAP state and a new state are active at the same time. The current state is deleted and replaced when the new authentication finishes successfully. If re-authentication fails, the old state can remain usable until it expires or a later attempt renews it.

That overlap is continuity, not instantaneous replacement. A dashboard that overwrites generation 41 with generation 42 at the moment re-authentication starts invents a transition that has not occurred. An application request may still be valid under the older context while the new exchange progresses. Conversely, a new method result does not prove that every policy cache and resource server has moved to the new generation.

The evidence needs a state graph: old generation, new candidate, start time, successful method result, protected confirmation, activation, resource-policy evaluation, last old-context use, retirement and expiry. When two generations accept traffic concurrently, the record should say whether overlap was intended and which irreversible operations were permitted in each.

Running-Code Primacy is especially useful here. The configuration may say “renewed,” but the running endpoints decide which context actually protects a message. The map must follow those transitions rather than award truth to the control plane by rank.

Deletion can converge locally before it converges globally

Forced removal has another two-sided exchange. The authenticator sends an OSCORE-protected DELETE to the last CoAP-EAP state resource. The peer returns a protected 2.02 Deleted. If the response does not arrive by EXCHANGE_LIFETIME, the authenticator removes its local state.

Local deletion after a timeout is a rational cleanup rule. It is not proof that the peer received the DELETE, erased its context or stopped attempting domain traffic.

The distinction matters during partition. The authenticator may close the session and report the device expelled. The peer may retain a context because it never received the request. A resource server may have cached authorization beyond either state. A network control may still forward protected packets that no current authenticator state can validate. “Removed” must therefore name the actor and layer.

The receipt chain is: deletion decision and principal, policy reason, state generation, protected DELETE transmitted, peer receipt, local deletion result, protected acknowledgement, authenticator verification, timeout if any, local authenticator cleanup, downstream policy invalidation, rejected post-removal attempts and independently observed traffic cessation. Not every deployment will retain every packet, but it must preserve enough joins to state which conclusion is known and which is inferred.

Discovery and trust remain outside the green box

RFC 9820 leaves discovery of the authenticator or intermediary outside scope. A device can learn that an endpoint offers CoAP-EAP without thereby proving that the endpoint is the intended authority. RFC 6677 provides EAP channel-binding machinery, including a lower-layer identifier that can help expose mismatches through the applicable method and AAA path. It does not make every discovery mechanism trustworthy by itself.

RFC 9820 explains that the peer can trust an authenticator holding the MSK because the peer's AAA server trusted that authenticator. That is a bounded transitive statement inside the key-management architecture. Operations still need to identify the AAA authority, configuration and channel-binding result involved in the particular session. A generic “trusted controller” label loses the principal.

Initial triggers create resource risk too. An attacker can forge many Step 0 messages appearing to come from different peers, causing the authenticator to begin work. The RFC recommends rate limiting and minimizing state until the EAP-Response/Identity arrives. A rate-limit counter proves load was constrained; it does not prove which peer was legitimate.

The minimum experiment must create disagreement

A successful demonstration should not stop after two endpoints complete the happy path. It should force the layers to disagree.

Use at least one peer, one authenticator, a pass-through AAA path, two application resources with different policies and an independent packet observer. Preserve identifiers and hashes, never secret key material. Run these cases:

valid method result, protected Steps 7 and 8, and one authorized resource;
valid method result with a modified cipher-suite transcript, causing context mismatch;
authenticator method success followed by loss of Step 7;
peer verification of Step 7 followed by loss of Step 8;
confirmed context followed by denial at a second resource;
stale resource-generation replay;
duplicated initial trigger during an active exchange;
re-authentication success with measured old/new overlap;
re-authentication failure while the old state remains valid;
forced deletion with acknowledged peer cleanup;
forced deletion whose acknowledgement is lost;
cached resource authorization surviving authenticator cleanup;
forged Step 0 flood under the configured rate limit;
discovery or channel-binding context pointing to the wrong authority.

For every case, compare four independent surfaces: EAP state, CoAP resource state, OSCORE verification and application authorization/outcome. The trial fails if it records only a final success or failure label.

What the sources do not establish

RFC 9820 does not name a deployed product, network or operator. It does not report conformance results, interoperability events, battery savings, message-loss rates, admission counts or attacks. Its example scenarios are explanatory, not deployment telemetry.

The Datatracker history records the document's progression. The references and referenced-by surface record documentary relationships, not adoption. The errata search is an editorial status surface, not a security score.

RFC 3748 defines EAP's broader framework; RFC 9820 defines a lower-layer/application composition for constrained environments. Neither lets a reviewer infer the identity, authority or state of a particular device from the existence of the standard.

The EAP Method Succeeded. The Protected Session Still Needed a Second Witness: RFC 9820

Why it matters

Summary

The dashboard promoted a method result into a domain fact

Ordering is carried by disposable resources

Step 7 is not ornamental wrapping

Step 8 is the second witness

Shared protection does not grant every resource

Re-authentication creates two presents

Deletion can converge locally before it converges globally

Discovery and trust remain outside the green box

The minimum experiment must create disagreement

What the sources do not establish

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing