RFC 9965

The eap.arpa. Domain and Extensible Authentication Protocol (EAP) Provisioning

📅 published May 2026, from ietf

RFC 9965: The eap.arpa. Domain and Extensible Authentication Protocol (EAP) Provisioning 🎀

Okay bestie, RFC 9965 just dropped 💖 It's called The eap.arpa. Domain and Extensible Authentication Protocol (EAP) Provisioning, written by A. DeKok at InkBridge Networks for the Internet Engineering Task Force (IETF) 🌸 It's dated May 2026, it's a Standards Track document, its ISSN is 2070-1721, and it updates RFCs 5216, 9140, and 9190 ✨

Abstract ✨

Okay so this doc defines the eap.arpa. domain, but only for use in Network Access Identifiers (NAIs) 🦋 It's how EAP peers tell EAP servers "hey, I want limited access, and I'm not authenticating" 🫶 Peers pick which kind of access they need using certain predefined identifiers that follow the NAI format of RFC 7542. There's a table of identifiers and what they mean, and it includes entries for RFC 9140 💅

This doc updates RFCs 5216 and 9190 to define an unauthenticated provisioning method 👑 Those specs hint that a method like this is possible, but they never actually say how to do it. This doc also updates RFC 9140 to deprecate eap-noob.arpa and replace it with @noob.eap.arpa 💀

Status of This Memo 🌈

This is an Internet Standards Track document 🔥

It's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841 🧚

For the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9965 💜

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved 🌸

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this document 🫶 Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License ⭐

Table of Contents 📚

1.  Introduction
  1.1.  Background and Rationale
    1.1.1.  Review of Existing Functionality
    1.1.2.  Taxonomy of Provisioning Types
    1.1.3.  Rationale for Provisioning over EAP
2.  Terminology
3.  Overview
  3.1.  The eap.arpa Realm
  3.2.  The Realm Field
  3.3.  The Username Field
  3.4.  Operation
    3.4.1.  EAP Peers
    3.4.2.  EAP Servers
  3.5.  Other Considerations
  3.6.  Considerations for Provisioning Specifications
    3.6.1.  Negotiation
    3.6.2.  Renewal of Credentials
  3.7.  Notes on AAA Routability
4.  Interaction with EAP Methods
  4.1.  High Level Requirements
  4.2.  EAP-TLS
  4.3.  EAP-NOOB
5.  IANA Considerations
  5.1.  .arpa Updates
    5.1.1.  Deprecating eap-noob.arpa
    5.1.2.  Defining the eap.arpa. Domain
  5.2.  EAP Provisioning Identifiers Registry
    5.2.1.  Initial Values of the EAP Provisioning Identifiers
            Registry
    5.2.2.  Guidelines for Designated Experts
    5.2.3.  Method Type
    5.2.4.  Designated Experts
    5.2.5.  Organization Self Assignment
6.  Privacy Considerations
7.  Security Considerations
  7.1.  On-Path Attackers and Impersonation
  7.2.  Provisioning is Unauthenticated
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgements
Author's Address

1. Introduction ✨

Okay so most of the time, EAP [RFC3748] needs peers to already have pre-provisioned credentials 😭 Without those, the device can't get network access, and without network access it can't get provisioned with credentials. Total chicken-and-egg situation, and this is the bootstrapping problem 🙈

This spec goes after that bootstrapping problem 💅 It sets up a framework for predefined "well-known" provisioning credentials and then fills that framework in with two mechanisms 🦋

Clients can submit these predefined provisioning credentials to a server to get limited network access. At the same time, servers can know in advance that these credentials are only for provisioning, so they can avoid giving full, unrestricted access to peers that submit them 🫶

The device can either use the EAP channel itself for provisioning, like with the Tunnel Extensible Authentication Protocol (TEAP) [RFC9930], or the EAP server can give the device access to a limited captive portal, like with [RFC8952] 🌸 Once the device is provisioned, it can use those credentials to get full network access ✨

The predefined provisioning credentials use a generic identity format, and identifiers in this space are called "EAP Provisioning Identifiers" (or "EPIs") 🧚

Since the identity is predefined and only used for unauthenticated network access, predefined passwords aren't really worth much 🙄 Where the underlying EAP method supports it, this spec allows password-less access 🔥 Where passwords are required, the password is defined to be the same as the identity 💜

1.1. Background and Rationale 📖

In this section we give some background on the existing functionality and explain why defining provisioning methods for EAP was necessary 💖

1.1.1. Review of Existing Functionality 🌸

For EAP-TLS, both [RFC5216], Section 2.1.1 and [RFC9190] provide for "peer unauthenticated access" 🫶 Those docs don't define any way for a peer to say it's requesting that kind of access, though 🙃 The assumption is that the peer connects with some value for the EAP Identity but doesn't use a client certificate. The EAP server is then supposed to figure out that the peer wants unauthenticated access and take the right steps to limit authorization ✨

There appear to be no EAP peer or server implementations that support this access, because there's no defined way to do any of the steps needed, meaning signalling that this access is wanted and then limiting it 💀

The Wi-Fi Alliance defined an unauthenticated EAP-TLS method using a vendor-specific EAP method as part of HotSpot 2.0r2 [HOTSPOT] 🦋 But there appear to be few deployments of that spec 😭

Nimble Out-of-Band Authentication for EAP (EAP-NOOB) [RFC9140] takes it a step further 👑 It defines both a way to signal that provisioning is wanted and a way to exchange provisioning information inside EAP-NOOB itself. So the device doesn't need limited network access at all, because all the provisioning happens inside the EAP-NOOB protocol 🔥

TEAP [RFC9930] provides for provisioning over an unauthenticated TLS tunnel 🌈 It has a server unauthenticated provisioning mode, but the inner TLS exchange requires that both ends authenticate each other. You can provision a certificate, but the peer still has to authenticate itself to the server with pre-existing credentials 😤 So any provisioning method that uses TEAP will have to deal with this limitation 💅

1.1.2. Taxonomy of Provisioning Types 🧚

There are two scenarios where provisioning can happen 🎀 In the first, provisioning is done within the EAP method, like with EAP-NOOB [RFC9140] ✨ In the second, EAP is used to get limited network access (for example, with a captive portal) 🦋 That limited access is then used to run IP-based provisioning over more complex protocols 🌸

1.1.3. Rationale for Provisioning over EAP 💖

Doing all of the provisioning inside EAP is often useful, because the EAP / Authentication, Authorization, and Accounting (AAA) admin doesn't control the network 🙈 It's not always possible to set up a captive portal where provisioning can happen. So we need to be able to provision via EAP: not via some IP 🫶

2. Terminology 💅

EAP Provisioning Identifier The EAP Provisioning Identifier (or EPI) is defined as a strict subset of the NAI [RFC7542] 🦋 An EPI is an NAI that is a subdomain of eap.arpa.. The "realm" portion of the NAI is defined in [RFC7542], Section 2.2, and it's a more restrictive subset of the domain name conventions in [STD13] 👑

Readers should note that the realm portion of the NAI is different from a domain name 🙃 Besides having a more limited character set, the realm portion of the NAI doesn't include a trailing period (".") 🌸

eap.arpa The realm portion of the NAI 💜

This document uses the term "eap.arpa realm" when using that name in the context of an NAI ✨

eap.arpa. The domain name eap.arpa. 🌈

This document uses the term "eap.arpa. domain" when using that name in the context of the DNS. The trailing period (".") is added for consistency with DNS specifications 🧚

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🔥

3. Overview 🌸

A device with no device-specific credentials can use a predefined provisioning identifier in NAI format [RFC7542] 💖 The NAI has two portions: the utf8-username and the utf8-realm domain. To keep it simple, we call these the "username" and "realm" fields 🫶

The realm is chosen to be independent of, and unused by, any existing organization, so every organization can use it ✨ The realm also needs to be one that no existing AAA proxy framework automatically proxies, as defined in [RFC7542], Section 3 🦋 And it needs to be one that doesn't return results for dynamic discovery, as described in [RFC7585] 👑

That said, this spec does not forbid routing packets for NAIs in the eap.arpa realm 🙃 It leaves that routing up to individual organizations 💅

This spec is fully compatible with all known EAP implementations, so it's fail-safe 🛡️ When a peer that wants to use this spec shows up, existing implementations return EAP Failure and won't otherwise misbehave 🌈

3.1. The eap.arpa Realm 🎀

This document defines the eap.arpa realm as being used for provisioning within EAP ✨ A similar domain was previously used for EAP-NOOB [RFC9140] as "eap-noob.arpa" 🦋 This document extends that concept and standardizes the practices around it 💖

3.2. The Realm Field ✨

okay so the realm is where the magic happens 🔮 NAIs in this spec use the "realm" field from [RFC7542] to signal what behavior you're asking for 💅 The subdomain under the eap.arpa. domain is how different requested methods get told apart, iykyk 🫶

The subdomain in the realm field is assigned through the "EAP Provisioning Identifiers" registry [EAPREG], which is defined in Section 5.2 🗂️ The subdomain MUST follow the syntax in [RFC7542], Section 2.2, which is a stricter subset of the domain name conventions in [STD13]. no wiggle room, bestie 🙅‍♀️

Where possible, the first subdomain of the eap.arpa. domain SHOULD use the EAP method name from the "Extensible Authentication Protocol (EAP) Registry" registry group, "Method Types" registry 🧚 BUT the names in the "EAP Method Type" registry [EAPREG] don't follow the [STD13] domain formats, so a one-to-one mapping isn't always possible 🥲

When a direct mapping isn't possible because the EAP Method Type name doesn't match the [RFC7542], Section 2.2 format, the NAI defined in the "EAP Provisioning Identifiers" registry MUST use a realm name that is similar enough for the average reader to understand which EAP Method Type is being used 🔍

Additional subdomains are permitted in the realm. These let vendors and Standards Development Organizations (SDOs) self-assign a delegated range of identifiers that don't conflict with other identifiers 🌸

Any realm defined in this registry (e.g., tls.eap.arpa) also implicitly defines a sub-realm "v." (e.g., v.tls.eap.arpa) 🦋 Vendors or SDOs can self-allocate within the "v." realm using realms that they own. For example, a company that owns the "example.com." domain could self-allocate and use the realm example.com.v.tls.eap.arpa ✨ See Section 5.2.5 for more discussion of this topic.

This specification does not make any provisions for private-use realms. The "v." sub-realm is sufficient for all private uses 🙌

Experimental provisioning methods MUST be defined within the appropriate vendor's name space. For documents within the IETF, the "ietf.org" vendor space MUST be used. Different uses SHOULD be distinguished by using the name of a working group or document, such as emu.ietf.org.v.eap.arpa 🎀

3.3. The Username Field

The username field depends on the EAP method being used for provisioning 🧩 For example, [RFC9140] uses the username noob 🥚 Other EAP methods MAY omit the username as recommended in [RFC7542].

The username anonymous is NOT RECOMMENDED for specifications using this format, even though [RFC7542] permits it. "anonymous" is widely used in NAIs today, and we wish to avoid confusion 🙈

The username field is assigned via the "EAP Provisioning Identifiers" registry, which is defined in Section 5.2 📒 The username field MAY be empty or hold a fixed value. While [RFC7542] recommends omitting the username portion for user privacy, the names here are defined in public specifications. Therefore, user privacy is not needed for provisioning identifiers, and the username field can be publicly visible 👀

3.4. Operation

Having described the format and contents of NAIs in the eap.arpa realm to define the EPI, we now describe how those EPIs are used by EAP peers and EAP servers to signal provisioning information 🚀

3.4.1. EAP Peers

An EAP peer signals that it wishes a certain kind of provisioning by using an EPI along with an associated EAP method 📣 The meaning of the EPI, and the behavior of the peer, are defined by a separate specification. That specification will typically define both the EPI and the EAP method or methods used for provisioning 🧠

The EPI used by the 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 entry 📋

Where an EAP peer allows local selection of a provisioning method, the EPI is defined by the provisioning method and not by the end user 💁‍♀️ As a result, when a provisioning method is being selected, the EAP peer MUST NOT have a configuration interface that lets the EAP user identifier field be configured directly. Instead, the user (or some other process) chooses a provisioning method, and the EAP peer then selects the EPI that matches that provisioning method 🎯

While EAP peers allow users to enter user identifiers directly for existing EAP methods, they MUST NOT check whether those identifiers match any EPI. Any user who enters an identifier that matches an EPI will either get rejected because the server does not support provisioning, or the user will be placed into a captive portal 🙃 There are no security or privacy issues with a user manually entering an EPI as the user identifier 🫠

When all goes well, running EAP with the EPI results in new authentication credentials being provisioned 🎉 The peer then drops its network connection and re-authenticates using the newly provisioned credentials. The user MAY be involved in this process, but in general, provisioning results in the EAP peer automatically gaining network access using the provisioned credentials 🌈

There are a number of ways provisioning can fail 💀 One way is when the server does not implement the provisioning method. Therefore, EAP peers MUST track which provisioning methods have been tried and not repeat the same method to the same EAP server when receiving an EAP Nak 🚫

Peers MUST rate limit their provisioning attempts. If provisioning fails, it is likely because provisioning is not available. Retrying provisioning repeatedly and in quick succession is not likely to change the server behavior. Instead, it is likely to result in the peer being blocked 😭 The peer SHOULD retry provisioning no more than once every few minutes, and SHOULD include jitter and exponential backoff on its provisioning attempts 🍓

Since there is no way to signal whether the failed provisioning is due to a transient failure on the EAP server or due to the EAP server not supporting that provisioning method, EAP peers SHOULD err on the side of long delays between retrying the same provisioning method to an EAP server ⏳ EAP peers MAY retry a given provisioning method after a sufficiently long interval that the EAP server might have implemented the provisioning method, e.g., at least a day and perhaps no more than a month 📅

Another way for the provisioning method to fail is when the new credentials do not result in network access. It is RECOMMENDED that when peers are provisioned with credentials, they immediately try to gain network access using those credentials 🔥 That process allows errors to be quickly discovered and addressed 🛠️

An EAP peer may have been provisioned with temporary credentials, or credentials that expire after some period of time (e.g., an X.509 certificate with notAfter date set) 🥀 Therefore, it SHOULD attempt to provision new credentials before the current set expires. Unfortunately, any re-provisioning process with EAP will involve the device dropping off from the "full" network in order to connect to the provisioning network 😩 Therefore, it is RECOMMENDED that re-provisioning methods be provided that can be used when the device has full network access. See Section 3.6 for additional discussion on this topic 💖

3.4.2. EAP Servers ✨

okay so the EAP server is the one who gets the first move 🎬 An EAP session kicks off when the server gets the initial EAP-Request/Identity message. Any server that follows this spec MUST check the identity to see if it uses a realm under the eap.arpa realm. If it does, that identity is an EPI 🎀 Everything else is handled exactly like before, and this spec doesn't change a thing for those identities.

If the server gets an EPI that's malformed, it MUST reply with an EAP Failure as per [RFC3748], Section 4.2 💀 For example, an NAI might end with the eap.arpa realm but also have stuff in it that isn't allowed by the format in [RFC7542]. Bestie, that's a no-go 🙅‍♀️ If the EPI is fine, the server looks at it to figure out which provisioning method the peer is asking for.

If the server doesn't recognize the EPI the peer asked for, it MUST reply with an EAP Nak of type zero (0) 🙈 That reply just means "sorry babe, that provisioning method isn't available here." The server also MUST reply with a Nak of type zero (0) as per [RFC3748], Section 5.3.1 if the peer proposes an EAP method that the server doesn't support, or that isn't valid for that provisioning method. The peer can then do whatever remedial action it decides is appropriate 🫶

Once the server accepts the provisioning method, it replies with an EAP method that MUST match the one linked to the EPI ✨ After that, the EAP process carries on following the EAP state machine outlined in [RFC3748]. Iconic flow, no notes.

Now the big one 🚨 Implementations MUST treat peers using an EPI as untrusted and untrustworthy 😭 Once a peer like that is authenticated, it MUST be placed into a limited network, like a captive portal. That limited network MUST NOT permit unrestricted network access. Implementations should be aware of methods that get around simple blocking, like tunneling data over DNS 👀 It's giving sneaky tunnel energy, so stay alert.

A secure provisioning network is one where only the expected traffic is allowed and everything else gets blocked 🛡️ Trying to block only the selected "bad" traffic leads to serious security fails. Most provisioning methods let unauthenticated devices onto the network, so there's a lot of room for malicious actors to misuse them 💅 That's why the limited network needs to be designed assuming it WILL get abused by bad actors. Plan for the worst, periodt 💜

A limited network SHOULD also limit how long devices being provisioned can keep network access ⏱️ Provisioning should be pretty quick, like seconds to tens of seconds 🍓 If it takes longer than that, something is probably wrong, and it might be useful to block that problematic device from the network 🚫

A limited network SHOULD also cap how much data the devices being provisioned can transfer, and SHOULD limit which network services those devices can reach 📦 Provisioning doesn't need to download big amounts of data, and it doesn't need access to a bunch of services either, so why give it?

Servers SHOULD rate limit provisioning attempts 🚦 A misbehaving peer can get blocked temporarily or even permanently. Implementations SHOULD limit the total number of peers being provisioned at the same time 🌸 There's no requirement for RADIUS servers to let every peer connect without limits. Instead, peers get provisioned at the discretion of the network being accessed, which may allow or deny those devices for reasons they never get told about 🤷‍♀️ Very mysterious, very gatekeepy.

Implementations SHOULD use functionality like the RADIUS Filter-Id attribute ([RFC2865], Section 5.11) to limit network access for the peer being provisioned, as discussed in Section 3.4.2 🎟️ For ease of admin, the Filter-Id name could just be the EPI or something similar 🧚 Keeping things consistent like that helps a ton when you're managing complex networks.

Implementations MUST prevent peers in the limited network from communicating with each other 🙅‍♀️ There's zero reason for a system that's being provisioned to talk to anything except the provisioning server(s). Strict guest energy, no mingling 💅

3.5. Other Considerations ✨

Implementations MUST NOT permit EAP method negotiation with provisioning credentials 🔐 So when an EPI is in use, any EAP Nak a server sends must contain only EAP method zero (0). When an EAP peer uses an EPI and gets an EAP Nak, any EAP methods listed in that Nak MUST be ignored 🙃

Servers can support more than one provisioning method, but EAP has no way to negotiate which one gets used 🤔 It's also expected that provisioning methods will be specific to a particular type of peer device. So a given peer will most likely only support one provisioning method. Simple.

Because of that, there's no need to require a method for negotiating provisioning methods 💖

3.6. Considerations for Provisioning Specifications 🎀

The operational considerations we've been talking about in this document affect specifications that define provisioning methods in a bunch of ways 🦋

3.6.1. Negotiation ✨

Specifications that define provisioning for an EAP method SHOULD provide a method-specific process that lets implementations negotiate a mutually acceptable provisioning method 🤝

Here's the tea though: for the reasons already covered in this document, we can't make that suggestion mandatory 🙈 If a provisioning method can't define any negotiation at all, that limitation should not be a barrier to publishing the specification. Not every method can do everything, and that's fine.

3.6.2. Renewal of Credentials 🔄

When a provisioning method is expected to create credentials that never expire, the specification SHOULD say so explicitly 📣

When credentials do expire, it is RECOMMENDED that specifications give guidance on how those credentials get updated 🔁 For example, an EAP method could allow re-provisioning as part of a normal EAP authentication, using the credentials that are already provisioned. Clean and simple.

It is RECOMMENDED that provisioning methods include a method that can be used without affecting network access 🌈 A specification could define provisioning endpoints like Enrollment over Secure Transport (EST) [RFC7030] or Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP) [RFC9810]. Those endpoints could be available both on the provisioning network and on the provisioned (a.k.a. normal) network. With an architecture like that, devices can be re-provisioned without losing network access. Main character re-provisioning energy 👑

3.7. Notes on AAA Routability 🗺️

[RFC7542], Section 3 explains how the NAI lets authentication requests be routable within a AAA proxy system ✨ The EPI uses the NAI format too, but the eap.arpa realm was picked specifically because it is NOT routable within a AAA proxy system 🙅‍♀️

When we say the eap.arpa realm isn't routable in a AAA proxy system, we mean two different things 👇

  1. The eap.arpa. domain doesn't exist in DNS, so it will never be resolvable for dynamic discovery as described in [RFC7585] 💀
  2. The eap.arpa realm will never be used by any administrator. The administrator can't meet the requirements of [RFC7542], Section 2.5 by registering the realm in DNS 🚫

On top of that, administrators won't have statically configured AAA proxy routes for this domain. And if routes do get added for this domain, they'll generally be used to implement this specification 🧩

To avoid pointless DNS lookups, RADIUS servers supporting [RFC7585] SHOULD filter the domains that get sent to DNS 🧹 Specifically, names in the eap.arpa. domain MUST NOT be looked up in DNS. No spam lookups, no drama 💜

4. Interaction with EAP Methods 🦋

Since the provisioning identifier gets used inside EAP, it definitely interacts with, and affects, the different EAP methods 💫 This section breaks down those effects in more detail.

Some EAP methods need shared credentials, like passwords, to succeed 🔑 For example, both EAP-MSCHAPv2 (Protected Extensible Authentication Protocol aka PEAP) and EAP-pwd [RFC5931] do cryptographic exchanges where both parties know a shared password. When password-based methods are used, the password SHOULD be the same as the provisioning identifier, because there are few reasons to define a method-specific password 🎀

This also applies to TLS-based EAP methods like EAP Tunneled Transport Layer Security (EAP-TTLS) and PEAP 🌊 When the TLS-based EAP method has an inner identity and inner authentication method, the credentials used there SHOULD be the provisioning identifier for both the inner identity and any inner password. Consistency is everything, bestie 💅

It is RECOMMENDED that provisioning be done via a TLS-based EAP method 🔐 TLS authenticates the EAP server and gives integrity and confidentiality protection for any provisioning data exchanged inside the tunnel. Similarly, if provisioning happens in a captive portal outside of EAP, EAP-TLS lets the EAP peer run a full EAP authentication session while only having a few Certification Authorities (CAs) configured locally 🏰

4.1. High Level Requirements 📋

All provisioning methods specified within the eap.arpa. domain MUST define a way to authenticate the server 🙌 That authentication can happen either at the EAP layer (like with TLS-based EAP methods) or after network access has been granted (if credentials are provisioned over HTTPS).

Where TLS-based EAP methods are used, implementations MUST still validate EAP server certificates in all situations other than provisioning 🔍 Where the provisioning method under the eap.arpa. domain defines that provisioning happens via another protocol, like HTTPS, the EAP peer MAY skip validating the EAP server certificate 🫠

Whether or not the server certificate gets ignored, the peer MUST treat the local network as untrusted 🚧 [RFC8952], Section 6 has more discussion on this topic.

Not validating EAP server certificates relaxes the requirement in [RFC5216], Section 5.3 that the server certificate always gets validated. For provisioning, it's acceptable in some cases to skip validating the EAP server certificate, but only when there are other ways to authenticate the data being provisioned 🙏

Still, since the device is likely already configured with web CAs [CAB], a captive portal that does unauthenticated provisioning could use those CAs within an EAP method so the peer can authenticate the EAP server 🧁 More discussion on this belongs in the specification(s) that define a particular provisioning method. This issue isn't discussed any further here, other than to say that it is technically possible ✨

4.2. EAP-TLS 🦋

Okay so this bit defines an NAI "portal@tls.eap.arpa" 🧚, which lets EAP peers use unauthenticated EAP-TLS. The whole point is that peers can tell EAP servers "hey, I want captive portal network access" 💖

This identifier tells the EAP server that the peer wants "peer unauthenticated access," as described in [RFC5216], Section 2.1.1 and [RFC9190]. Ngl, this part is super important: peer unauthenticated access MUST provide for authentication of the EAP server, such as with a server certificate 🔥. Using TLS-PSK with a well-known Pre-Shared Key (PSK) value is generally not appropriate, because it would not give you server authentication 💀

An EAP server that agrees to handle this request MUST make sure the device is placed into a captive portal with limited network access, as discussed above in Section 3.4.2 ✨

This method is a huge upgrade over regular captive portals, which are usually totally unsecured and unauthenticated 😭 With peer unauthenticated TLS for network access, the EAP server is proven to be authentic 👑 And the use of 802.1X [IEEE802.1X] means the link between the EAP peer and the EAP authenticator (for example, an access point) is secured too 🫶

If you want more details on the captive portal architecture, check out [RFC8952] 🌸 The captive portal can advertise support for the eap.arpa. domain through an 802.11u [IEEE802.11u] realm 💅

4.3. EAP-NOOB 🍓

It is RECOMMENDED that server implementations of EAP-NOOB accept both identities "noob@eap-noob.arpa" and "@noob.eap.arpa" as synonyms 🌈

It is RECOMMENDED that EAP-NOOB peers try "@noob.eap.arpa" first and, if that doesn't work, then use "noob@eap-noob.arpa" 🙈

5. IANA Considerations ✨

Okay, so this document covers a few IANA actions 📋

  • IANA has made two registry updates to define the eap.arpa. domain (Section 5.1) 🎀
  • IANA has created a new registry (see Section 5.2) 🧚

5.1. .arpa Updates 🌸

There are two updates to the ".ARPA Zone Management" registry [ARPAREG] (detailed in Sections 5.1.1 and 5.1.2) 💜

IANA has also been told to refuse any further allocation requests inside the ".ARPA Zone Management" registry for anything related to EAP. Instead, EAP allocations go into the new "EAP Provisioning Identifiers" registry, which lives in the "Extensible Authentication Protocol (EAP) Registry" registry group (see [EAPREG]) 🔥

5.1.1. Deprecating eap-noob.arpa 🥀

IANA has updated the "eap-noob.arpa" entry in the ".ARPA Zone Management" registry [ARPAREG] like this:

The USAGE/REFERENCE field now starts with (DEPRECATED) and has a reference to this document (RFC 9965) added 💀

5.1.2. Defining the eap.arpa. Domain 🦋

IANA has updated the ".ARPA Zone Management" registry [ARPAREG] to include this new entry:

DOMAIN:  eap.arpa
USAGE/REFERENCE:  For provisioning within the Extensible
   Authentication Protocol framework.  RFC 9965

IANA has also updated the "Special-Use Domain Names" registry (see [SPECIAL-USE]) like this:

Name:  eap.arpa.
Reference:  RFC 9965

5.1.2.1. Domain Name Reservation Considerations 🙈

This section answers the questions that Section 5 of [RFC6761] asks. Basically, these new domain names get used in certain EAP situations. Users never see them, and they don't show up in any networking protocol other than EAP ✨

  1. Users: Human users aren't expected to recognize these names as special or to treat them differently from other domain names. Using them in EAP is invisible to end users 👑
  2. Application Software: EAP servers and clients are expected to make their software recognize these names as special and treat them differently. This document talks about that behavior. EAP peers should recognize these names as special and should refuse to let users type them into any interface. EAP servers and RADIUS servers should recognize the eap.arpa. domain as special and refuse to do dynamic discovery ([RFC7585]) for it 🔥
  3. Name Resolution APIs and Libraries: Writers of these APIs and libraries aren't expected to recognize these names or treat them differently 🌈
  4. Caching DNS Servers: Writers of caching DNS servers aren't expected to recognize these names or treat them differently 🫶
  5. Authoritative DNS Servers: Writers of authoritative DNS servers aren't expected to recognize these names or treat them differently 💅
  6. DNS Server Operators: These domain names barely affect DNS server operators. They should never be used in DNS or in any networking protocol outside of EAP 🍓

Some DNS servers might get lookups for this domain, if EAP or RADIUS servers are set up to do dynamic discovery for realms as defined in [RFC7585], and those servers haven't been updated to ignore the .arpa domain. When queried for the eap.arpa. domain, DNS servers SHOULD return an NXDOMAIN error 💀

If operators try to configure their authoritative DNS as authoritative for this reserved name, compliant name servers don't need to do anything special. They can accept the domain or reject it. Either way, it won't affect implementations of this specification 🧚

  1. DNS Registries/Registrars: DNS Registries/Registrars should deny requests to register this reserved domain name 🙅‍♀️

5.2. EAP Provisioning Identifiers Registry 🌟

IANA has added this new registry to the "Extensible Authentication Protocol (EAP) Registry" registry group (see [EAPREG]) 💖

Assignments in this registry are made via "Expert Review," as described in [RFC8126], Section 4.5. Guidelines for experts are in Section 5.2.2 🎀

The registry format looks like this:

Title:  EAP Provisioning Identifiers
Registration Procedure(s):  Expert Review
Reference:  RFC 9965
NAI:  The Network Access Identifier in the format described in
   [RFC7542].
Method Type:  The EAP method name, taken from the "Description" field
   of the "Method Types" registry (see [EAPREG]) .
Reference:  Reference where this identifier was defined.

5.2.1. Initial Values of the EAP Provisioning Identifiers Registry 🦋

Here are the starter entries for this registry 🍓

      +=====================+=============+========================+
      | NAI                 | Method Type | Reference              |
      +=====================+=============+========================+
      | @noob.eap.arpa      | EAP-NOOB    | [RFC9140] and RFC 9965 |
      +---------------------+-------------+------------------------+
      | portal@tls.eap.arpa | EAP-TLS     | [RFC9190] and RFC 9965 |
      +---------------------+-------------+------------------------+

             Table 1: Initial Values of the EAP Provisioning
                           Identifiers Registry

5.2.2. Guidelines for Designated Experts 🧚

This part gives guidelines for the designated experts who review allocation requests for the "EAP Provisioning Identifiers" registry 💜

5.2.2.1. NAIs ✨

The idea is that the NAI describes both the EAP Method Type and the purpose of the provisioning method. A descriptive format helps administrators who don't know a particular NAI make reasonable guesses about the provisioning method being requested 👑 For example, with an EAP Method Type "name" and a purpose "action," the NAI SHOULD be of the form "action@name.eap.arpa" 🌈

The NAI MUST satisfy the format requirements in [RFC7542], Section 2.2. The utf8-username portion MAY be empty. The utf8-username portion MUST NOT be "anonymous." The NAI MUST be a subdomain within the eap.arpa realm. NAIs with any "v." subdomain MUST NOT be registered, so that the functionality of that subdomain is preserved 🔥

NAIs in the registry MUST NOT contain more than one subdomain. NAIs with a leading "v." subdomain MUST NOT be registered. That subdomain is reserved for vendor and SDO extensions 🫶

The subdomain of the NAI field should match the EAP Method Type name. Care should be taken so that the domain name conventions in [STD13] are followed 💅

The NAIs in this registry are case-insensitive. [RFC7542] notes that similar identifiers in different cases can be considered different, but this registry requires that all entries MUST be lowercase, for simplicity 🍓

Identifiers MUST be unique when compared in a case-insensitive fashion. [RFC7542] notes that similar identifiers in different cases can be considered different, but this registry is made simpler by requiring case-insensitivity 🌸

Entries in the registry should be short. NAIs defined here will generally be sent in a RADIUS packet in the User-Name attribute ([RFC2865], Section 5.1). That specification recommends that implementations should support User-Names of at least 63 octets. NAI length considerations are further discussed in [RFC7542], Section 2.3, and any allocations in this registry need to take those limits into account 🙈

Implementations are likely to support a total NAI length of 63 octets. Lengths between 63 and 253 octets may work. Lengths of 254 octets or more will not work with RADIUS [RFC2865] 💀

5.2.3. Method Type 🎀

Values in the "Method Type" field of this registry MUST be taken from the "Method Types" registry (see [EAPREG]). Otherwise, a value MUST be an Expanded Type, which usually indicates a vendor-specific EAP method 🌈

The EAP Method Type MUST provide a Master Session Key (MSK) and an Extended MSK (EMSK), as defined in [RFC3748]. If a method doesn't provide these keys, it won't be usable within an authentication framework that requires them, such as [IEEE802.1X] 🔥

5.2.4. Designated Experts 👑

The designated expert will post a request to the EAP Method Update (EMU) WG mailing list (or a successor designated by the Area Director) for comment and review. That includes an I-D or a reference to an external specification 🦋 Before a period of 30 days has passed, the designated expert will either approve or deny the registration request and publish a notice of the decision to the EMU WG mailing list (or its successor), and also inform IANA 💖 A denial notice must be justified with an explanation. Where it's possible, concrete suggestions on how the request can be changed to become acceptable should be provided 🫶

5.2.5. Organization Self Assignment

okay so the "EAP Provisioning Identifiers" registry lets organizations request allocations 💅 but explicit allocations aren't always needed. Any NAI defined in this registry also implicitly defines a subdomain v., so organizations can self-allocate in that space under the v. subdomain, e.g., local@example.com.v.tls.eap.arpa 🦋

The point of self-assigned realms is testing and future expansion ✨. There are currently no use cases envisioned for these realms, but we don't want to forbid future expansion, so the door stays open 🚪

An organization that has registered a Fully Qualified Domain Name (FQDN) within the DNS can use that name within the v. subdomain 🌸

DNS registrations can change over time, and an organization may stop using a domain at some point. That change shows up in the DNS but is unlikely to reach shipped products that use a self-assigned realm 😭 There is no solution to this problem other than suggesting that organizations using self-assigned realms do not allow their DNS registrations to expire. (the DNS situation is giving major drama 💀)

Therefore, it is RECOMMENDED that organizations avoid the use of self-assigned realms 🫶 Organizations MAY use self-assigned realms only when no other alternative exists and when the organization expects to maintain operation for at least the lifetime of the devices that use these realms 🍓

6. Privacy Considerations 🔐

The EAP Identity field is generally publicly visible to anyone who can observe the EAP traffic 👀 Since the names given here are in a public specification, there's no privacy implication to exposing those names within EAP. Honestly the whole goal of this specification is to make those names public, so unknown (and private) parties can publicly (and anonymously) declare what kind of network access they want ✨

However, there are many additional privacy concerns around this specification 😬 Most EAP traffic is sent over RADIUS [RFC2865]. The RADIUS Access-Request packets typically contain large amounts of information such as Media Access Control (MAC) addresses, device location, etc.

This specification does not change RADIUS or EAP, so it does not change which information is publicly available or kept private 🙅‍♀️ Those issues are dealt with in other specifications, such as [INSECURE-RADIUS].

BUT, this specification can increase privacy 🌈 by letting devices anonymously obtain network access and then securely obtain credentials.

The NAIs used here are contained in a public registry, so they do not have to follow the username privacy recommendations of [RFC7542], Section 2.4. However, there may be other personally identifying information contained in EAP or AAA packets. This situation is no different from normal EAP authentication, so it has no additional positive or negative implications for privacy 💖

7. Security Considerations 🔥🚨

This specification defines a framework that permits unknown, anonymous, and unauthenticated devices to request and obtain network access. As such, it is critical that network operators provide limited access to those devices 😤💀

Future specifications that define an NAI within this registry should give detailed descriptions of what kind of network access is to be provided 📝

7.1. On-Path Attackers and Impersonation

In most EAP use cases, the server identity is validated (usually through a certificate) or the EAP method allows the TLS tunnel to be cryptographically bound to the inner application data. For the methods outlined here, using public credentials and/or skipping server validation lets "on-path" attacks succeed where they would normally fail 🙈 this is the part where things get spicy 🌶️

EAP peers and servers MUST assume that all data sent over an EAP session is visible to attackers and can be modified by them 👁️

The methods defined here MUST only be used to bootstrap initial network access. Once a device has been provisioned, it gains network access via the provisioned credentials, and any network access policies can be applied 🎀

7.2. Provisioning is Unauthenticated

This specification allows unauthenticated EAP peers to obtain network access, however limited. As with any unauthenticated process, this access can be abused 😩 Implementations should take care to limit the use of the provisioning network 🧚

Section 3.4.2 describes a number of methods that can be used to secure the provisioning network. In summary:

  • allow only traffic that is needed for the current provisioning method. All other traffic should be blocked. Most notably, DNS has been used to exfiltrate network traffic, so DNS recursive resolvers SHOULD NOT be made available on the provisioning network 🙅‍♀️
  • limit the services available on the provisioning network to only those services that are needed for provisioning 🧼
  • limit the number of devices that can access the provisioning network at the same time 👯
  • for any one device, rate limit its access to the provisioning network ⏳
  • for a device that has accessed the provisioning network, limit the total amount of time that it is allowed to remain on the network ⏰
  • for a device that has accessed the provisioning network, limit the total amount of data that it is allowed to transfer through the network 📦

8. References 📚

8.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
           Levkowetz, Ed., "Extensible Authentication Protocol (EAP)",
           RFC 3748, DOI 10.17487/RFC3748, June 2004,
           <https://www.rfc-editor.org/info/rfc3748>.

[RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
           Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
           March 2008, <https://www.rfc-editor.org/info/rfc5216>.

[RFC7542]  DeKok, A., "The Network Access Identifier", RFC 7542,
           DOI 10.17487/RFC7542, May 2015,
           <https://www.rfc-editor.org/info/rfc7542>.

[RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
           Writing an IANA Considerations Section in RFCs", BCP 26,
           RFC 8126, DOI 10.17487/RFC8126, June 2017,
           <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9140]  Aura, T., Sethi, M., and A. Peltonen, "Nimble Out-of-Band
           Authentication for EAP (EAP-NOOB)", RFC 9140,
           DOI 10.17487/RFC9140, December 2021,
           <https://www.rfc-editor.org/info/rfc9140>.

[STD13]    Internet Standard 13,
           <https://www.rfc-editor.org/info/std13>.
           At the time of writing, this STD comprises the following:

           Mockapetris, P., "Domain names - concepts and facilities",
           STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
           <https://www.rfc-editor.org/info/rfc1034>.

           Mockapetris, P., "Domain names - implementation and
           specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
           November 1987, <https://www.rfc-editor.org/info/rfc1035>.

8.2. Informative References

[ARPAREG]  IANA, ".ARPA Zone Management",
           <https://www.iana.org/domains/arpa>.

[CAB]      CA/Browser Forum, "CA/Browser Forum",
           <https://cabforum.org/>.

[EAPREG]   IANA, "Extensible Authentication Protocol (EAP) Registry",
           <https://www.iana.org/assignments/eap-numbers>.

[HOTSPOT]  Wi-Fi Alliance, "Passpoint",
           <https://www.wi-fi.org/discover-wi-fi/passpoint>.

[IEEE802.11u]
           IEEE, "IEEE Standard for Information Technology -
           Telecommunications and information exchange between
           systems - Local and Metropolitan networks-specific
           requirements - Part II: Wireless LAN Medium Access Control
           (MAC) and Physical Layer (PHY) specifications: Amendment
           9: Interworking with External Networks", IEEE Std 802.11u-
           2011, DOI 10.1109/IEEESTD.2011.5721908, 2011,
           <https://ieeexplore.ieee.org/document/5721908>.

[IEEE802.1X]
           IEEE, "IEEE Standard for Local and metropolitan area
           networks--Port-Based Network Access Control", IEEE Std
           802.1X-2020, DOI 10.1109/IEEESTD.2020.9018454, 2020,
           <https://ieeexplore.ieee.org/document/5409813>.

[INSECURE-RADIUS]
           DeKok, A., "Deprecating Insecure Practices in RADIUS",
           Work in Progress, Internet-Draft, draft-ietf-radext-
           deprecating-radius-09, 15 March 2026,
           <https://datatracker.ietf.org/doc/html/draft-ietf-radext-
           deprecating-radius-09>.

[RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
           "Remote Authentication Dial In User Service (RADIUS)",
           RFC 2865, DOI 10.17487/RFC2865, June 2000,
           <https://www.rfc-editor.org/info/rfc2865>.

[RFC5931]  Harkins, D. and G. Zorn, "Extensible Authentication
           Protocol (EAP) Authentication Using Only a Password",
           RFC 5931, DOI 10.17487/RFC5931, August 2010,
           <https://www.rfc-editor.org/info/rfc5931>.

[RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
           RFC 6761, DOI 10.17487/RFC6761, February 2013,
           <https://www.rfc-editor.org/info/rfc6761>.

[RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
           "Enrollment over Secure Transport", RFC 7030,
           DOI 10.17487/RFC7030, October 2013,
           <https://www.rfc-editor.org/info/rfc7030>.

[RFC7585]  Winter, S. and M. McCauley, "Dynamic Peer Discovery for
           RADIUS/TLS and RADIUS/DTLS Based on the Network Access
           Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October
           2015, <https://www.rfc-editor.org/info/rfc7585>.

[RFC8952]  Larose, K., Dolson, D., and H. Liu, "Captive Portal
           Architecture", RFC 8952, DOI 10.17487/RFC8952, November
           2020, <https://www.rfc-editor.org/info/rfc8952>.

[RFC9190]  Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the
           Extensible Authentication Protocol with TLS 1.3",
           RFC 9190, DOI 10.17487/RFC9190, February 2022,
           <https://www.rfc-editor.org/info/rfc9190>.

[RFC9810]  Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
           "Internet X.509 Public Key Infrastructure -- Certificate
           Management Protocol (CMP)", RFC 9810,
           DOI 10.17487/RFC9810, July 2025,
           <https://www.rfc-editor.org/info/rfc9810>.

[RFC9930]  DeKok, A., Ed., "Tunnel Extensible Authentication Protocol
           (TEAP) Version 1", RFC 9930, DOI 10.17487/RFC9930,
           February 2026, <https://www.rfc-editor.org/info/rfc9930>.

[SPECIAL-USE]
           IANA, "Special-Use Domain Names",
           <https://www.iana.org/assignments/special-use-domain-
           names>.

Acknowledgements 🫶

Mohit Sethi provided valuable insight that using subdomains was better and more informative than the original method, which used only the utf8-username portion of the NAI 🧠✨

The document was further improved with reviews from Maria Ines Robles and Ben Kaduk 💜 bestie-approved reviewers, no notes 🌟

Author's Address 🎀

Okay bestie, last stop! 🧚 This is where you find the person who wrote the thing and how to reach them if you have questions. Alan DeKok is the author, and he's with InkBridge Networks 💅

Alan DeKok
InkBridge Networks
Email: alan.dekok@inkbridge.io

Slide into that inbox if you've got a question about the spec 💌✨

📦 where this page comes from