3. Overview

A device with no device-specific credentials can use a predefined provisioning identifier in NAI format. The NAI contains a username field and a realm field. The realm is chosen to be independent of any organization, not automatically proxied by AAA routing, and not resolvable by dynamic discovery.

3.1. The eap.arpa Realm

The eap.arpa realm is used for provisioning within EAP. The older eap-noob.arpa name from EAP-NOOB is deprecated and replaced by @noob.eap.arpa.

3.2. Realm Field

The subdomain under eap.arpa identifies the requested method. It MUST follow RFC 7542 Section 2.2 syntax. Where possible, the first subdomain SHOULD use the EAP Method Type name. Vendor and SDO extensions use the implicit v. sub-realm, for example example.com.v.tls.eap.arpa or emu.ietf.org.v.eap.arpa.

3.3. Username Field

The username depends on the provisioning method. The username MAY be empty. The username anonymous is NOT RECOMMENDED.

3.4. Operation

An EAP peer MUST use an EPI from the EAP Provisioning Identifiers registry, and the EAP method used with that NAI MUST match the Method Type in the same registry entry. A peer MUST NOT expose direct configuration of the EAP user identifier when a provisioning method is selected, and MUST NOT check user-entered identifiers against the EPI list.

Peers MUST track attempted provisioning methods and avoid repeating the same method to the same EAP server after an EAP Nak. Peers MUST rate limit attempts, SHOULD retry no more than once every few minutes, and SHOULD use jitter and exponential backoff. Retrying the same method after a long interval, such as at least a day and no more than a month, MAY be appropriate.

An EAP server MUST examine identities under the eap.arpa realm. Malformed EPIs MUST produce EAP Failure. Unknown EPIs or unsupported methods MUST produce an EAP Nak of type zero (0). Accepted provisioning MUST use the EAP method associated with the EPI.

Peers using an EPI MUST be treated as untrusted. After authentication they MUST be placed into a limited network, and unrestricted access MUST NOT be allowed. Implementations MUST prevent peers in the limited network from communicating with each other.

3.5-3.7. Other Considerations

Implementations MUST NOT permit EAP method negotiation with provisioning credentials. EAP Nak must contain only method zero (0), and peers MUST ignore any other EAP methods in that Nak. Names in the eap.arpa. domain MUST NOT be looked up in DNS.