Summary

  • RFC 9965 defines public EAP Provisioning Identifiers under eap.arpa so a peer without device-specific credentials can request limited, unauthenticated access. The identifier expresses a provisioning intention; it does not identify, own or authorize the device.
  • The standard requires an accepted peer to remain untrusted inside a constrained network. Expected traffic should be allowlisted, peers isolated, and duration, bytes, services, attempts and concurrent sessions bounded.
  • A provisioning-lane closure receipt should connect the EPI request to the applied enforcement state and prove when that state expired or was removed. This is Daniel Kade’s editorial proposal, not an IETF requirement.

Success creates the most easily forgotten state

Bootstrap systems exist because ordinary authentication begins with a circular demand: a device needs credentials to enter a network, yet it may need network access to obtain those credentials. RFC 9965 resolves that narrow problem by standardising EAP Provisioning Identifiers, or EPIs. A device can present a predefined Network Access Identifier in the eap.arpa realm and ask for the kind of access associated with it.

The arrangement is useful precisely because the identifier is not exclusive. It can be known before manufacture, shipment, ownership assignment or local enrollment. portal@tls.eap.arpa asks for captive-portal access through EAP-TLS. @noob.eap.arpa identifies the EAP-NOOB path. The current IANA EAP registry records those associations so implementations can interpret the request consistently.

That is a routing of intention, not an authentication of the peer. Anyone able to speak the protocol can know a well-known identifier. Its successful parsing does not prove that the device belongs to a customer, was bought through an authorised channel, remains in inventory, has not been resold, or should receive full access. The identifier says, in effect, “I am asking for this provisioning method.” It cannot truthfully say, “I am the device that local policy intended to admit.”

RFC 9965 preserves the distinction. Implementations must treat a peer using an EPI as untrusted and untrustworthy. If the network accepts the request, it must place the peer in a limited network rather than grant unrestricted connectivity. The network may refuse without explaining its local policy. A syntactically valid request is therefore not an entitlement, and even a successful EAP exchange is not the final admission decision.

The overlooked governance problem begins once this narrow exception works. A rule is installed at an access point, switch, controller, gateway or enforcement device. The device gains enough connectivity to reach a permitted service. A credential may then be issued. At that point, the temporary exception has fulfilled its purpose. If nobody can prove that the old rule disappeared, the network has created a second, weaker route whose lifetime is undefined.

A public name must not become a durable privilege

An EPI uses the NAI format defined by RFC 7542, but the realm is not an ordinary promise of DNS discovery. RFC 9965 separates eap.arpa as an NAI realm from eap.arpa. as a domain name and says the reserved name should not be used in DNS or in protocols outside EAP. Queries should receive NXDOMAIN. IANA’s special-use registry records the reservation.

This matters operationally. A well-known string should select a locally understood bootstrap behavior, not launch an open-ended search for a remote authority. The network receiving the EPI remains responsible for deciding whether to offer provisioning, which method is valid, where the peer may go and when the exception ends. Dynamic discovery must not turn a local limited-access decision into an accidental federation.

RFC 9965 also narrows negotiation. A malformed EPI is rejected. An unknown identifier, unsupported EAP method or method that does not match the EPI receives a Nak carrying method zero. General method negotiation with provisioning credentials is prohibited. This reduces the opportunity for a peer and server to drift into a method neither side intended for that public identifier.

But syntactic discipline does not allocate trust. Registry review can establish that an identifier is well formed, distinct and associated with a specified EAP method. It cannot determine whether a particular factory sensor on a particular port is legitimate. IANA controls the shared vocabulary. The operator controls the local exposure. The institutional owner controls which devices should ultimately be enrolled. Those are three separate authorities.

Treating the EPI as a credential collapses them. It allows possession of public syntax to masquerade as possession of an accountable identity. A sound implementation instead regards the EPI as the first event in a short-lived state machine: request, local acceptance or refusal, restricted placement, server-authenticated provisioning, outcome, and closure.

“Limited” must be a positive specification

The central operational instruction in RFC 9965 is easy to paraphrase badly. A limited network is not an ordinary network with a few dangerous destinations blocked. The RFC says a secure provisioning network permits only expected traffic and blocks everything else. It warns that selective blocking fails because traffic can be carried through channels that a simple denylist forgot, including DNS tunnelling.

This shifts policy from adjectives to objects. “Guest”, “quarantine” and “onboarding” are labels; they are not evidence of restriction. The operator needs to know the filter or segment actually applied, the destinations and protocols it allowed, the enforcement points that held it, and any supporting services included for certificate validation, time or name resolution. An attractive policy name cannot prove the resulting packet path.

The RFC supplies several dimensions for bounding the exception:

  • Duration should normally be on the order of seconds to tens of seconds. A long provisioning session may signal a fault and can justify blocking the peer.
  • Data volume should be limited because provisioning ordinarily does not require a large transfer.
  • Available network services should be few and purpose-specific.
  • Attempts should be rate-limited, and a misbehaving peer may be blocked temporarily or permanently.
  • Concurrent provisioning peers should be capped; the server does not owe an unlimited queue to unauthenticated devices.
  • Peers in the limited network must be prevented from communicating with one another.

Each dimension closes a different abuse path. A timer limits residence. A byte ceiling limits bulk exfiltration or relay. A service allowlist limits lateral reach. Attempt and concurrency controls protect shared capacity. Peer isolation prevents the provisioning segment from becoming its own untrusted local network.

No single control substitutes for the others. A thirty-second session with unrestricted egress can still do harm. A precise allowlist without expiry can become a permanent alternative channel. A concurrency limit without peer isolation can still expose one device to another. The governance question is not whether the system owns a feature called “restricted access”. It is whether all relevant restrictions were present for this session at the same time.

RFC 9965 mentions RADIUS Filter-Id as one way to name the applied access policy. That is a useful operational join, not a mandatory universal architecture. Some networks will use VLANs, ACLs, security groups, role assignments or controller-native policy objects. Whatever mechanism is chosen, its realized identity and revision should be retained. A policy name without a version can silently point to a broader rule tomorrow than it did today.

Server authentication remains part of the bargain

Unauthenticated provisioning is an awkward phrase because it can obscure which party lacks authentication. The public EPI does not authenticate the peer. That does not make an anonymous server acceptable.

RFC 9965 requires every provisioning method under eap.arpa to define a way to authenticate the server. This may occur inside the EAP method or later in another protected protocol, such as HTTPS, depending on the method specification. The peer must continue treating the local network as untrusted. For portal@tls.eap.arpa, peer-unauthenticated EAP-TLS still needs server authentication, for example through a server certificate. A shared, well-known TLS-PSK would not provide that assurance.

The asymmetry is deliberate. A network may allow an unknown device to reach a tiny service surface, but the device should not accept credentials or configuration from an unknown source merely because it asked to be provisioned. Otherwise an on-path actor could transform the convenience of bootstrapping into a durable compromise.

RFC 8952 helps separate the components of a captive system. A provisioning service supplies an API URI; an API reports captivity state; a user portal can satisfy local conditions; an enforcement device controls traffic. These functions can reside together or apart. Their evidence should not be collapsed into a single “portal success” flag.

The enforcement device is particularly important. It holds the packet-level fact of restriction and later release. A portal can say that enrollment completed while the access switch still carries an old role. A controller can say that it sent a removal command while the enforcement point did not apply it. A client can cache an earlier view of its captive state that no longer matches the network. Completion therefore needs observation from the control that actually governs traffic, not only the application that issued credentials.

Credential creation and admission are two decisions

Provisioning can end in several legitimate ways. A peer may receive a new certificate. It may complete an out-of-band EAP-NOOB exchange under RFC 9140. It may fail server authentication, time out, exceed a byte budget, offer an unsupported method, or be refused because capacity is full. It may obtain a credential but fail the next ordinary authentication because local authorization has changed.

These outcomes should not share one undifferentiated status called “done”. Credential generation is evidence that a provisioning mechanism produced an artifact. It is not evidence that the network accepted that artifact for continuing access. The new credential might be malformed, revoked, mapped to the wrong local record or valid only for a different service.

The safest transition is discontinuous in authority even if it is smooth in user experience. The limited EPI session ends. The peer begins a new, ordinary authentication using its provisioned credential. Current authorization policy evaluates that authenticated identity. Only then does the enforcement point install the access appropriate to the admitted device.

If an implementation changes the role in place, the evidence still needs to show the boundary. Which credential-backed identity replaced the EPI session? Which policy decision authorized the new role? Which old allowlist was removed? What happened if the role change partially failed? Without those joins, an observer cannot distinguish full admission from an onboarding exception that simply grew broader.

This is where the prior RFC 9966 custody question remains separate. TLS-POK can prove a constrained relationship involving knowledge of a Bootstrap Key public/private pair. That proof does not answer how a limited RFC 9965 network was enforced or whether it closed. Conversely, a perfect closure record does not establish who rightfully possessed a Bootstrap Key. Proof-of-key, provisioning state and final admission are neighbouring records, not interchangeable conclusions.

The provisioning-lane closure receipt

A compact receipt can make the transient state reviewable without inventing a new protocol object. It should preserve seven joins:

  1. Request. The exact EPI, EAP method, arrival time, authenticator or NAS, access interface and a short-lived local session identifier. The record should state that the EPI is public and does not authenticate the peer.
  2. Local decision. Acceptance or refusal, the policy revision consulted, capacity state, reason class and accountable decision service. Sensitive anti-abuse details need not be disclosed to the peer or the public.
  3. Enforcement. The filter, segment, role or ACL revision actually installed; enforcement points; allowed destinations, protocols and supporting services; default-deny posture; and peer-isolation control.
  4. Budgets. Start time, hard expiry, byte ceiling, service scope, attempt counter, rate-limit state and the concurrent-session pool against which the peer was admitted.
  5. Server assurance. The method by which the provisioning server or delivered data was authenticated, the relevant certificate or trust-anchor reference, validation outcome and any narrowly permitted exception.
  6. Outcome. Success, explicit refusal, malformed request, unsupported method, authentication failure, timeout, budget breach or operator termination. If a credential was produced, retain only a protected reference and its intended lifetime, never secret material.
  7. Closure. The time and reason the limited rule was removed or expired, evidence from the enforcement point, residual-flow handling, any new authenticated session and a reconciliation proving that no orphaned provisioning state remains.

The receipt should be privacy-bounded. A public accountability view might disclose counts, durations, policy revisions, failure classes and unresolved exceptions. Device identifiers, certificate material, stable port mappings and allowlists can remain restricted. Hashes can bind the protected record to a public summary, but a hash cannot prove that the underlying policy was justified or that a controller reported honestly.

“Provisioning-lane closure receipt” is an editorial term used here. RFC 9965 does not prescribe it. The point is not to make the IETF define every operator’s workflow. It is to ensure that local automation can answer the governance question created by a public bootstrap credential: which temporary privilege existed, why did it exist, and what proves it no longer exists?

Expiry is a decision, not housekeeping

Temporary access is often implemented as operational convenience. A cleanup worker removes expired sessions. A nightly job reconciles stale roles. A technician clears an onboarding VLAN when a queue looks wrong. That framing is too weak for an exception granted to an unauthenticated peer.

Expiry is part of the access decision itself. If the authorizing component cannot state a maximum lifetime, it has not defined the privilege. If the enforcement point cannot prove removal, the decision remains open. If repeated provisioning is allowed immediately after expiry, rate limits and device-independent abuse controls must cover the sequence rather than each isolated session.

Failure should close the lane at least as firmly as success. A peer that receives malformed data should not retain access indefinitely while waiting for a retry. A portal outage should not broaden its allowlist for convenience. A credential server that is unreachable should not cause the enforcement device to fall back to general Internet access. Safe failure means the temporary state remains narrow and terminates predictably.

Capacity governance belongs here too. RFC 9965 explicitly allows the network to limit simultaneous provisioning and refuse devices at its discretion. That is not only protection for the RADIUS server. It is protection for DHCP pools, certificate services, logging systems, captive APIs and the human support process. A fleet that can occupy every provisional slot can deny onboarding to legitimate devices without ever obtaining full admission.

What can be proved

The strongest local evidence is a three-way comparison: the policy decision intended for the session, the enforcement state observed while it ran, and the closure state observed afterward. All three should share a session identifier and monotonic generation or revision. Clock source and observation latency should be recorded where seconds matter.

A receipt can prove that a named enforcement point reported applying policy revision 42 at a particular time, that counters stayed below a threshold, and that the rule later disappeared. It cannot prove an absent packet was never forwarded through some unobserved path. Sampling, telemetry gaps and controller/enforcement disagreement belong in the uncertainty field rather than being averaged into a green status.

The record should also distinguish automatic expiry from confirmed removal. A TTL reaching zero in a controller database does not necessarily prove the switch discarded its rule. Conversely, an enforcement point may remove a rule before the orchestration service records completion. Reconciliation should retain both times and surface the gap.

This follows Heng Lu’s evidence discipline: running state reveals where practical power resides, while a record of the formal rule explains where it was supposed to reside. Neither should erase the other. The temporary lane is governed only when the commissioning decision, technical enforcement and observed closure can be compared without pretending they are the same fact.

Limits

The sources establish protocol requirements, registry state and stated security considerations. They do not show how widely RFC 9965 is deployed, name an operator using it, demonstrate an attack or measure the cost of a closure receipt. Different access networks will use different enforcement mechanisms and different privacy boundaries.

The receipt proposal does not turn an article into a network credential, compliance certificate or directory object. It does not require public disclosure of devices or security policy. It offers a local evidence shape for a transition that RFC 9965 intentionally leaves to deployments: access is narrow, discretionary and temporary; full admission comes later, if at all.

Sources