Summary

  • RFC 9965 reserves eap.arpa for Network Access Identifiers that ask an EAP server for a defined provisioning path and limited, unauthenticated connectivity.
  • The request, a selected EAP method, server authentication, limited-network enforcement, credential issuance and ordinary admission are separate records and separate decisions.

An unfamiliar device presents an identifier ending in eap.arpa. A network can read that as a request for help getting a credential. It cannot read it as the credential itself. That distinction is the quiet value of RFC 9965, The eap.arpa. Domain and Extensible Authentication Protocol Provisioning.

The RFC defines an EAP Provisioning Identifier, or EPI: an NAI whose realm is a subdomain of eap.arpa.. The realm is intentionally independent of a particular organisation. It is not supposed to be automatically proxied by existing AAA machinery or resolved through ordinary dynamic peer discovery. Yet the standard does not prohibit an organisation from deciding to route it. That is an important division of labour. The shared syntax tells a peer how to ask for a provisioning method; the receiving operator still decides whether it will handle that request, where it will send it and under what evidence.

This is why a realm string is weak evidence. It can establish that a peer emitted a particular request in an EAP identity exchange. It cannot establish who owns the peer, which organisation is responsible for it, which backend handled it, or whether any backend completed an authentication method. A log that turns @method.eap.arpa into “trusted device” has silently replaced one observable message with several unobserved decisions.

RFC 9965 is explicit about the state before those decisions. Implementations must regard EPI-using peers as untrusted and untrustworthy. Once a provisioning method is accepted, the peer belongs in a limited network, such as a captive portal; that network must not permit unrestricted network access. The standard goes further than a decorative landing page. A secure provisioning network allows expected traffic and blocks all other traffic. A design that merely blocks selected bad destinations leaves a much larger and less auditable surface.

The method boundary matters too. The EPI selects a requested provisioning method. If the EAP server accepts that request, the method it offers must match the EPI's associated method, and then the normal EAP state machine continues. RFC 3748 defines EAP as an authentication framework with multiple methods; its own terminology warns that an authenticated peer may still be denied access for policy, a session limit or other reasons. A method selection is therefore neither an EAP success nor a general authorisation.

Server authentication is another distinct layer. RFC 9965 requires each provisioning method under eap.arpa. to say how the server will be authenticated, and recommends TLS-based EAP where it provides server authentication, integrity and confidentiality for the provisioning exchange. That is a requirement on a method design, not proof that a given session validated a particular certificate. Where a method allows special provisioning behaviour, the operator still needs a record showing exactly which validation rule applied, which server was presented, and what succeeded or failed.

The useful audit trail is consequently plural: the EPI requested; the local routing decision; the selected method; server-authentication evidence; the restricted-network rule actually enforced; the credential decision; and the later access decision. None has to inherit authority from the one before it. Keeping them separate lets a network help an uncredentialed peer without pretending that a request has already become an identity or an entitlement.