The eap.arpa. Domain and Extensible Authentication Protocol (EAP) Provisioning
updates
Extracted elements (27)
Each registry entry implicitly defines a 'v.' sub-realm (e.g., 'v.tls.eap.arpa') allowing vendors and SDOs to self-allocate identifiers under their own DNS domain without a registry request (e.g., 'example.com.v.tls.eap.arpa'). This avoids proliferating registry entries for experimental and vendor-specific uses.
Provisioning is performed inside EAP (rather than via a captive portal) because the EAP/AAA administrator may not have control over the network and it is not always possible to define a captive portal. All provisioning must be doable via EAP, not via IP-based protocols.
The eap.arpa realm was chosen because it is not routable within a AAA proxy system: the eap.arpa. domain does not exist in DNS (preventing dynamic discovery per RFC 7585), and administrators cannot register it within the DNS to satisfy RFC 7542 Section 2.5 requirements. This ensures EPIs stay local.
The username 'anonymous' is NOT RECOMMENDED in EAP Provisioning Identifiers even though RFC 7542 permits it, because 'anonymous' is already widely used in NAIs and would cause confusion between provisioning and regular anonymous authentication.
Where passwords are required by an EAP method (e.g., EAP-MSCHAPv2, EAP-pwd, EAP-TTLS inner methods), the password SHOULD be the same as the provisioning identifier, since there are few reasons to define a separate method-specific password for a well-known public identity.
EAP-NOOB server implementations are RECOMMENDED to accept both 'noob@eap-noob.arpa' (deprecated) and '@noob.eap.arpa' (new) as synonyms. EAP-NOOB peers should prefer '@noob.eap.arpa' first and fall back to 'noob@eap-noob.arpa' if it does not succeed.
NAIs defined in this registry are intended for use in RADIUS User-Name attributes (RFC 2865 Section 5.1), which recommends support for at least 63 octets. NAIs between 63–253 octets may work; lengths of 254 octets or more will not work with RADIUS.
This specification is fully compatible with all known EAP implementations. When presented with a peer wishing to use an EPI, existing non-compliant implementations will return EAP Failure and will not otherwise misbehave, making the mechanism fail-safe.
All provisioning methods specified within the eap.arpa. domain MUST define a way to authenticate the server, either at the EAP layer (e.g., TLS-based EAP) or after network access has been granted (e.g., via HTTPS). The peer MUST treat the local network as untrusted regardless.
An EAP server implementing this specification MUST examine the EAP Identity to detect realms under eap.arpa. If the EPI is malformed, the server MUST reply with EAP Failure. If the EPI is unrecognized, the server MUST reply with EAP Nak of type zero (0).
EAP peers and servers MUST assume that all data sent over an EAP session using these provisioning methods is visible to attackers and can be modified by them. These methods MUST only be used to bootstrap initial network access.
EAP peers MUST track which provisioning methods have been tried and MUST NOT repeat the same method to the same EAP server upon receiving an EAP Nak. Peers MUST rate limit provisioning attempts and SHOULD retry no more than once every few minutes with jitter and exponential backoff.
Implementations MUST NOT permit EAP method negotiation with provisioning credentials. When an EPI is used, any EAP Nak sent by a server MUST contain only EAP method zero (0), and any EAP methods given in a Nak received by a peer using an EPI MUST be ignored.
Implementations MUST prevent peers in the limited provisioning network from communicating with each other; provisioned devices should only communicate with provisioning servers.
Implementations MUST treat peers using an EPI as untrusted and untrustworthy; once authenticated, such a peer MUST be placed into a limited network such as a captive portal. The limited network MUST NOT permit unrestricted network access.
RADIUS servers supporting RFC 7585 dynamic discovery SHOULD perform domain filtering, and names in the eap.arpa. domain MUST NOT be looked up in DNS, to avoid spurious DNS queries for a domain that does not exist.
The EAP Method Type registered in the 'EAP Provisioning Identifiers' registry MUST provide a Master Session Key (MSK) and Extended MSK (EMSK) as defined in RFC 3748, ensuring usability within 802.1X authentication frameworks.
The EPI used by a peer MUST be taken from an entry in the 'EAP Provisioning Identifiers' registry, and the EAP method used with that NAI MUST match the corresponding EAP method from that same registry entry.
When a provisioning method is selected, the EAP peer MUST NOT have a configuration interface that allows the EAP user identifier to be configured directly by the user; instead, the peer selects the EPI matching the chosen provisioning method.
EAP Identity (the EPI) is publicly visible to observers of EAP traffic, but since EPIs are in a public registry this creates no additional privacy concern. However, RADIUS Access-Request packets may contain MAC addresses and device location; this specification does not change existing RADIUS privacy properties.
An EAP Provisioning Identifier (EPI) is a strict subset of the NAI (RFC 7542) whose realm is a subdomain of 'eap.arpa'. EAP peers use EPIs to signal to EAP servers that they wish to obtain limited, unauthenticated network access for credential bootstrapping. The EPI format is 'username@subdomain.eap.arpa', where the subdomain identifies the requested provisioning method.
The NAI '@noob.eap.arpa' replaces the deprecated 'noob@eap-noob.arpa' for EAP-NOOB (RFC 9140) provisioning. Both identifiers share EAP-NOOB as their Method Type; EAP-NOOB servers and peers should support both during migration.
The NAI 'portal@tls.eap.arpa' signals that an EAP peer wishes to obtain peer unauthenticated EAP-TLS access to a captive portal, as defined in RFC 5216 Section 2.1.1 and RFC 9190. The EAP server must authenticate itself (e.g., via server certificate), and the peer must be placed into a limited captive portal network.
The '.ARPA Zone Management' registry is updated to add 'eap.arpa' for EAP provisioning (RFC 9965) and to mark 'eap-noob.arpa' as DEPRECATED. Additionally, 'eap.arpa.' is added to the 'Special-Use Domain Names' registry.
The 'EAP Provisioning Identifiers' registry is created under the 'Extensible Authentication Protocol (EAP) Registry' group with Expert Review procedure. Initial entries are '@noob.eap.arpa' (EAP-NOOB, RFC 9140) and 'portal@tls.eap.arpa' (EAP-TLS, RFC 9190). Each entry has an NAI, Method Type, and Reference.
On-path attackers can succeed against the provisioning methods defined here because public credentials and/or skipping server certificate validation removes normal EAP protections. All EAP session data must be treated as visible and modifiable by attackers, and these methods must only be used for initial bootstrapping.
The provisioning network must be secured by allowing only traffic needed for the current provisioning method, blocking all other traffic (including DNS recursive resolvers to prevent exfiltration), limiting simultaneous device count, rate limiting per-device access, and capping both session duration and total data transfer.