rfc9965v1.txt   rfc9965.txt 
Internet Engineering Task Force (IETF) A. DeKok Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 9965 InkBridge Networks Request for Comments: 9965 InkBridge Networks
Updates: 5216, 9140, 9190 April 2026 Updates: 5216, 9140, 9190 May 2026
Category: Standards Track Category: Standards Track
ISSN: 2070-1721 ISSN: 2070-1721
The eap.arpa. Domain and Extensible Authentication Protocol (EAP) The eap.arpa. Domain and Extensible Authentication Protocol (EAP)
Provisioning Provisioning
Abstract Abstract
This document defines the eap.arpa. domain for use only in Network This document defines the eap.arpa. domain for use only in Network
Access Identifiers (NAIs) as a way for Extensible Authentication Access Identifiers (NAIs) as a way for Extensible Authentication
Protocol (EAP) peers to signal to EAP servers that they wish to Protocol (EAP) peers to signal to EAP servers that they wish to
obtain limited, and unauthenticated, network access. EAP peers obtain limited, and unauthenticated, network access. EAP peers
signal which kind of access is required via certain predefined signal which kind of access is required via certain predefined
identifiers that use the NAI format of RFC 7542. A table of identifiers that use the NAI format of RFC 7542. A table of
skipping to change at line 84 skipping to change at line 84
3.6.1. Negotiation 3.6.1. Negotiation
3.6.2. Renewal of Credentials 3.6.2. Renewal of Credentials
3.7. Notes on AAA Routability 3.7. Notes on AAA Routability
4. Interaction with EAP Methods 4. Interaction with EAP Methods
4.1. High Level Requirements 4.1. High Level Requirements
4.2. EAP-TLS 4.2. EAP-TLS
4.3. EAP-NOOB 4.3. EAP-NOOB
5. IANA Considerations 5. IANA Considerations
5.1. .arpa Updates 5.1. .arpa Updates
5.1.1. Deprecating eap-noob.arpa 5.1.1. Deprecating eap-noob.arpa
5.1.2. Defining the eap.arpa. Domain 5.1.2. Defining the eap.arpa. Domain
5.2. EAP Provisioning Identifiers Registry 5.2. EAP Provisioning Identifiers Registry
5.2.1. Initial Values of the EAP Provisioning Identifiers 5.2.1. Initial Values of the EAP Provisioning Identifiers
Registry Registry
5.3. Guidelines for Designated Experts 5.2.2. Guidelines for Designated Experts
5.3.1. NAIs 5.2.3. Method Type
5.4. Method-Type 5.2.4. Designated Experts
5.5. Designated Experts 5.2.5. Organization Self Assignment
5.6. Organization Self Assignment
6. Privacy Considerations 6. Privacy Considerations
7. Security Considerations 7. Security Considerations
7.1. On-Path Attackers and Impersonation 7.1. On-Path Attackers and Impersonation
7.2. Provisioning is Unauthenticated 7.2. Provisioning is Unauthenticated
8. References 8. References
8.1. Normative References 8.1. Normative References
8.2. Informative References 8.2. Informative References
Acknowledgements Acknowledgements
Author's Address Author's Address
1. Introduction 1. Introduction
In most uses, EAP [RFC3748] requires that the EAP peers have pre- In most uses, EAP [RFC3748] requires that the EAP peers have pre-
provisioned credentials. Without credentials, the device cannot provisioned credentials. Without pre-provisioned credentials, the
obtain network access in order to be provisioned with credentials. device cannot obtain network access in order to be provisioned with
This limitation creates a bootstrapping problem. credentials. This limitation creates a bootstrapping problem.
This specification addresses that bootstrapping problem. It creates This specification addresses that bootstrapping problem. It creates
a framework for predefined "well-known" provisioning credentials and a framework for predefined "well-known" provisioning credentials and
instantiates that framework for two mechanisms. instantiates that framework for two mechanisms.
Clients can submit these predefined provisioning credentials to a Clients can submit these predefined provisioning credentials to a
server in order to obtain limited network access. At the same time, server in order to obtain limited network access. At the same time,
servers can know in advance that these credentials are to be used servers can know in advance that these credentials are to be used
only for provisioning; thus, they can avoid granting unrestricted only for provisioning; thus, they can avoid granting unrestricted
network access to peers that submit these credentials. network access to peers that submit these credentials.
skipping to change at line 200 skipping to change at line 199
EAP / Authentication, Authorization, and Accounting (AAA) admin does EAP / Authentication, Authorization, and Accounting (AAA) admin does
not have control over the network. It is not always possible to not have control over the network. It is not always possible to
define a captive portal where provisioning can be done. As a result, define a captive portal where provisioning can be done. As a result,
we need to be able to perform provisioning via EAP: not via some IP. we need to be able to perform provisioning via EAP: not via some IP.
2. Terminology 2. Terminology
EAP Provisioning Identifier EAP Provisioning Identifier
The EAP Provisioning Identifier (or EPI) is defined to be a strict The EAP Provisioning Identifier (or EPI) is defined to be a strict
subset of the NAI [RFC7542]. The EPI is an NAI that is a subset of the NAI [RFC7542]. The EPI is an NAI that is a
subdomain of "eap.arpa". The "realm" portion of the NAI is subdomain of "eap.arpa.". The "realm" portion of the NAI is
defined in [RFC7542], Section 2.2, which is a more restrictive defined in [RFC7542], Section 2.2, which is a more restrictive
subset of the domain name conventions specified in [STD13]. subset of the domain name conventions specified in [STD13].
Readers of this document should note that the realm portion of the Readers of this document should note that the realm portion of the
NAI is different from a domain name. In addition to the character NAI is different from a domain name. In addition to the character
set being more limited, the realm portion of the NAI does not set being more limited, the realm portion of the NAI does not
include a trailing period ("."). include a trailing period (".").
eap.arpa eap.arpa
The realm portion of the NAI. The realm portion of the NAI.
skipping to change at line 258 skipping to change at line 257
wishing to use this specification, existing implementations will wishing to use this specification, existing implementations will
return EAP Failure and will not otherwise misbehave. return EAP Failure and will not otherwise misbehave.
3.1. The eap.arpa Realm 3.1. The eap.arpa Realm
This document defines the eap.arpa realm as being used for This document defines the eap.arpa realm as being used for
provisioning within EAP. A similar domain has previously been used provisioning within EAP. A similar domain has previously been used
for EAP-NOOB [RFC9140] as "eap-noob.arpa". This document extends for EAP-NOOB [RFC9140] as "eap-noob.arpa". This document extends
that concept and standardizes the practices surrounding it. that concept and standardizes the practices surrounding it.
NOTE: As the controller of the "arpa" domain, the IAB has approved NOTE: As the controller of the arpa domain, the IAB has approved the
the allocation of eap.arpa. allocation of eap.arpa.
3.2. The Realm Field 3.2. The Realm Field
The NAIs defined by this specification use the "realm" field defined The NAIs defined by this specification use the "realm" field defined
in [RFC7542] to signal the behavior being requested; in particular, in [RFC7542] to signal the behavior being requested; in particular,
the subdomain under the eap.arpa. domain allows for different the subdomain under the eap.arpa. domain allows for different
requested methods to be distinguished. The subdomain in the realm requested methods to be distinguished. The subdomain in the realm
field is assigned via the "EAP Provisioning Identifiers" registry field is assigned via the "EAP Provisioning Identifiers" registry
[EAPREG], which is defined in Section 5.2. The subdomain MUST follow [EAPREG], which is defined in Section 5.2. The subdomain MUST follow
the syntax defined in [RFC7542], Section 2.2, which is a more the syntax defined in [RFC7542], Section 2.2, which is a more
restrictive subset of the domain name conventions specified in restrictive subset of the domain name conventions specified in
[STD13]. [STD13].
Where possible, the first subdomain of the eap.arpa. domain SHOULD Where possible, the first subdomain of the eap.arpa. domain SHOULD
use the EAP method name, as defined in the "Extensible Authentication use the EAP method name, as defined in the "Extensible Authentication
Protocol (EAP) Registry" registry group, "Method Types" registry. Protocol (EAP) Registry" registry group, "Method Types" registry.
However, the EAP registry does not follow the domain name conventions However, the names in the "EAP Method Type" registry [EAP-METHOD] do
specified in [STD13], so it is not always possible to make a one-to- not follow the domain name formats specified in [STD13], so it is not
one mapping between the Method-Type name and a subdomain of the always possible to make a one-to-one mapping between the Method Type
eap.arpa. domain. name and a subdomain of the eap.arpa. domain.
Where it is not possible to make a direct mapping between the EAP Where it is not possible to make a direct mapping between the EAP
Method-Type name due to the EAP Method-Type name not matching the Method Type name due to the EAP Method Type name not matching the
[RFC7542], Section 2.2 format, the NAI that is defined in the "EAP [RFC7542], Section 2.2 format, the NAI that is defined in the "EAP
Provisioning Identifiers" registry MUST use a realm name that is Provisioning Identifiers" registry MUST use a realm name that is
similar enough to allow the average reader to understand which EAP similar enough to allow the average reader to understand which EAP
Method-Type is being used. Method Type is being used.
Additional subdomains are permitted in the realm; these permit Additional subdomains are permitted in the realm; these permit
vendors and Standards Development Organizations (SDOs) the ability to vendors and Standards Development Organizations (SDOs) the ability to
self-assign a delegated range of identifiers that do not conflict self-assign a delegated range of identifiers that do not conflict
with other identifiers. with other identifiers.
Any realm defined in this registry (e.g., "tls.eap.arpa") also Any realm defined in this registry (e.g., "tls.eap.arpa") also
implicitly defines a sub-realm "v." (e.g., "v.tls.eap.arpa"). implicitly defines a sub-realm "v." (e.g., "v.tls.eap.arpa").
Vendors or SDOs can self-allocate within the "v." realm using realms Vendors or SDOs can self-allocate within the "v." realm using realms
that they own. For example, a company that owns the "example.com." that they own. For example, a company that owns the "example.com."
domain could self-allocate and use the realm domain could self-allocate and use the realm
"example.com.v.tls.eap.arpa". See Section 5.6 for more discussion of "example.com.v.tls.eap.arpa". See Section 5.2.5 for more discussion
this topic. of this topic.
This specification does not make any provisions for private-use This specification does not make any provisions for private-use
realms. The "v." sub-realm is sufficient for all private uses. realms. The "v." sub-realm is sufficient for all private uses.
Experimental provisioning methods MUST be defined within the Experimental provisioning methods MUST be defined within the
appropriate vendor's name space. For documents within the IETF, the appropriate vendor's name space. For documents within the IETF, the
"ietf.org" vendor space MUST be used. Different uses SHOULD be "ietf.org" vendor space MUST be used. Different uses SHOULD be
distinguished by using the name of a working group or document, such distinguished by using the name of a working group or document, such
as "emu.ietf.org.v.eap.arpa". as "emu.ietf.org.v.eap.arpa".
skipping to change at line 331 skipping to change at line 330
registry, which is defined in Section 5.2. The username field MAY be registry, which is defined in Section 5.2. The username field MAY be
empty or hold a fixed value. While [RFC7542] recommends omitting the empty or hold a fixed value. While [RFC7542] recommends omitting the
username portion for user privacy, the names here are defined in username portion for user privacy, the names here are defined in
public specifications. Therefore, user privacy is not needed for public specifications. Therefore, user privacy is not needed for
provisioning identifiers; the username field can be publicly visible. provisioning identifiers; the username field can be publicly visible.
3.4. Operation 3.4. Operation
Having described the format and contents of NAIs in the eap.arpa 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 realm to define the EPI, we now describe how those EPIs are used by
EAP peers and EAP peers to signal provisioning information. EAP peers and EAP servers to signal provisioning information.
3.4.1. EAP Peers 3.4.1. EAP Peers
An EAP peer signals that it wishes a certain kind of provisioning by 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 using an EPI along with an associated EAP method. The meaning of the
EPI, and behavior of the peer, are defined by a separate EPI, and behavior of the peer, are defined by a separate
specification. That specification will typically define both the EPI specification. That specification will typically define both the EPI
and the EAP method or methods that are used for provisioning. and the EAP method or methods that are used for provisioning.
The EPI used by the peer MUST be taken from an entry in the "EAP The EPI used by the peer MUST be taken from an entry in the "EAP
skipping to change at line 411 skipping to change at line 410
Unfortunately, any re-provisioning process with EAP will involve the Unfortunately, any re-provisioning process with EAP will involve the
device dropping off from the "full" network in order to connect to device dropping off from the "full" network in order to connect to
the provisioning network. Therefore, it is RECOMMENDED that re- the provisioning network. Therefore, it is RECOMMENDED that re-
provisioning methods be provided that can be used when the device has provisioning methods be provided that can be used when the device has
full network access. See Section 3.6 for additional discussion on full network access. See Section 3.6 for additional discussion on
this topic. this topic.
3.4.2. EAP Servers 3.4.2. EAP Servers
An EAP session begins with the server receiving an initial EAP- An EAP session begins with the server receiving an initial EAP-
Request/Identity message. An EAP server supporting this Request/Identity message. An EAP server implementing this
specification MUST examine the identity to see if it uses a realm specification MUST examine the identity to see if it uses a realm
located under eap.arpa. If so, the identity is an EPI. Processing located under the eap.arpa realm. If so, the identity is an EPI.
of all other identities is unchanged by this specification. Processing of all other identities is unchanged by this
specification.
If the server receives an EPI that is malformed, it MUST reply with If the server receives an EPI that is malformed, it MUST reply with
an EAP Failure as per [RFC3748], Section 4.2. For example, an NAI an EAP Failure as per [RFC3748], Section 4.2. For example, an NAI
may end with the eap.arpa realm but may also contain data that is not may end with the eap.arpa realm but may also contain data that is not
permitted by the format described in [RFC7542]. Otherwise, the EPI permitted by the format described in [RFC7542]. Otherwise, the EPI
is examined to determine which provisioning method is being requested is examined to determine which provisioning method is being requested
by the peer. by the peer.
If the server does not recognize the EPI requested by the peer, it If the server does not recognize the EPI requested by the peer, it
MUST reply with an EAP Nak of type zero (0). This reply indicates MUST reply with an EAP Nak of type zero (0). This reply indicates
skipping to change at line 574 skipping to change at line 574
up in DNS. up in DNS.
4. Interaction with EAP Methods 4. Interaction with EAP Methods
As the provisioning identifier is used within EAP, it necessarily has As the provisioning identifier is used within EAP, it necessarily has
interactions with, and effects on, the various EAP methods. This interactions with, and effects on, the various EAP methods. This
section discusses those effects in more detail. section discusses those effects in more detail.
Some EAP methods require shared credentials such as passwords in Some EAP methods require shared credentials such as passwords in
order to succeed. For example, both EAP-MSCHAPv2 (Protected order to succeed. For example, both EAP-MSCHAPv2 (Protected
Extensible Authentication Protocol aka PEAP) and EAP-PWD [RFC5931] Extensible Authentication Protocol aka PEAP) and EAP-pwd [RFC5931]
perform cryptographic exchanges where both parties know a shared perform cryptographic exchanges where both parties know a shared
password. Where password-based methods are used, the password SHOULD password. Where password-based methods are used, the password SHOULD
be the same as the provisioning identifier, as there are few reasons be the same as the provisioning identifier, as there are few reasons
to define a method-specific password. to define a method-specific password.
This requirement also applies to TLS-based EAP methods such as EAP This requirement also applies to TLS-based EAP methods such as EAP
Tunneled Transport Layer Security (EAP-TTLS) and PEAP. Where the Tunneled Transport Layer Security (EAP-TTLS) and PEAP. Where the
TLS-based EAP method provides for an inner identity and inner TLS-based EAP method provides for an inner identity and inner
authentication method, the credentials used there SHOULD be the authentication method, the credentials used there SHOULD be the
provisioning identifier for both the inner identity and any inner provisioning identifier for both the inner identity and any inner
skipping to change at line 597 skipping to change at line 597
It is RECOMMENDED that provisioning be done via a TLS-based EAP It is RECOMMENDED that provisioning be done via a TLS-based EAP
method. TLS provides for authentication of the EAP server along with method. TLS provides for authentication of the EAP server along with
integrity and confidentiality protection for any provisioning data integrity and confidentiality protection for any provisioning data
exchanged in the tunnel. Similarly, if provisioning is done in a exchanged in the tunnel. Similarly, if provisioning is done in a
captive portal outside of EAP, EAP-TLS permits the EAP peer to run a captive portal outside of EAP, EAP-TLS permits the EAP peer to run a
full EAP authentication session while having nothing more than a few full EAP authentication session while having nothing more than a few
Certificate Authorities (CAs) locally configured. Certificate Authorities (CAs) locally configured.
4.1. High Level Requirements 4.1. High Level Requirements
All provisioning methods that are specified within the eap.arpa. All provisioning methods that are specified within the
domain MUST define a way to authenticate the server. This eap.arpa. domain MUST define a way to authenticate the server. This
authentication can happen either at the EAP layer (as with TLS-based authentication can happen either at the EAP layer (as with TLS-based
EAP methods) or after network access has been granted (if credentials EAP methods) or after network access has been granted (if credentials
are provisioned over HTTPS). are provisioned over HTTPS).
Where TLS-based EAP methods are used, implementations MUST still Where TLS-based EAP methods are used, implementations MUST still
validate EAP server certificates in all situations other than validate EAP server certificates in all situations other than
provisioning. Where the provisioning method under the eap.arpa. provisioning. Where the provisioning method under the
domain defines that provisioning happens via another protocol such as eap.arpa. domain defines that provisioning happens via another
with HTTPS, the EAP peer MAY skip validating the EAP server protocol such as with HTTPS, the EAP peer MAY skip validating the EAP
certificate. server certificate.
Whether or not the server certificate is ignored, the peer MUST treat Whether or not the server certificate is ignored, the peer MUST treat
the local network as untrusted. [RFC8952], Section 6 has more the local network as untrusted. [RFC8952], Section 6 has more
discussion on this topic. discussion on this topic.
The ability to not validate the EAP server certificates relaxes the The ability to not validate the EAP server certificates relaxes the
requirements of [RFC5216], Section 5.3 that the server certificate requirements of [RFC5216], Section 5.3 that the server certificate
always be validated. For provisioning, it is acceptable in some always be validated. For provisioning, it is acceptable in some
cases to not validate the EAP server certificate but only when there cases to not validate the EAP server certificate but only when there
are other means to authenticate the data that is being provisioned. are other means to authenticate the data that is being provisioned.
skipping to change at line 650 skipping to change at line 650
value is generally not appropriate, as it would not provide server value is generally not appropriate, as it would not provide server
authentication. authentication.
An EAP server that agrees to authenticate this request MUST ensure An EAP server that agrees to authenticate this request MUST ensure
that the device is placed into a captive portal with limited network that the device is placed into a captive portal with limited network
access as discussed above in Section 3.4.2. access as discussed above in Section 3.4.2.
This method is an improvement over existing captive portals, which This method is an improvement over existing captive portals, which
are typically completely unsecured and unauthenticated. Using peer are typically completely unsecured and unauthenticated. Using peer
unauthenticated TLS for network access ensures that the EAP server is unauthenticated TLS for network access ensures that the EAP server is
proven to be authentic. The use of 802.1X ensures that the link proven to be authentic. The use of 802.1X [IEEE802.1X] ensures that
between the EAP peer and EAP authenticator (e.g., access point) is the link between the EAP peer and EAP authenticator (e.g., access
also secured. point) is also secured.
Further details of the captive portal architecture can be found in Further details of the captive portal architecture can be found in
[RFC8952]. The captive portal can advertise support for the [RFC8952]. The captive portal can advertise support for the
eap.arpa. domain via an 802.11u realm. eap.arpa. domain via an 802.11u [IEEE802.11u] realm.
4.3. EAP-NOOB 4.3. EAP-NOOB
It is RECOMMENDED that server implementations of EAP-NOOB accept both It is RECOMMENDED that server implementations of EAP-NOOB accept both
identities "noob@eap-noob.arpa" and "@noob.eap.arpa" as synonyms. identities "noob@eap-noob.arpa" and "@noob.eap.arpa" as synonyms.
It is RECOMMENDED that EAP-NOOB peers use "@noob.eap.arpa" first and, It is RECOMMENDED that EAP-NOOB peers use "@noob.eap.arpa" first and,
if that does not succeed, then they use "noob@eap-noob.arpa". if that does not succeed, then they use "noob@eap-noob.arpa".
5. IANA Considerations 5. IANA Considerations
This document describes a number of IANA actions: This document describes a number of IANA actions:
* There are two registry updates in order to define the eap.arpa. * IANA has made two registry updates in order to define the
domain (Section 5.1). eap.arpa. domain (Section 5.1).
* A new registry is created (see Section 5.2).
* The "noob@eap-noob.arpa" registry entry is deprecated (see * IANA has created a new registry (see Section 5.2).
Section 5.1.1).
5.1. .arpa Updates 5.1. .arpa Updates
There are two updates to the ".ARPA Zone Management" registry There are two updates to the ".ARPA Zone Management" registry
[ARPAREG] (detailed in Sections 5.1.1 and 5.1.2). [ARPAREG] (detailed in Sections 5.1.1 and 5.1.2).
IANA has also been instructed to refuse further allocation requests IANA has also been instructed to refuse further allocation requests
that are directly within the ".ARPA Zone Management" registry for any that are directly within the ".ARPA Zone Management" registry for any
functionality related to the EAP. Instead, allocations related to functionality related to the EAP. Instead, allocations related to
EAP are to be made within the new "EAP Provisioning Identifiers" EAP are to be made within the new "EAP Provisioning Identifiers"
skipping to change at line 698 skipping to change at line 695
registry group (see [EAPREG]). registry group (see [EAPREG]).
5.1.1. Deprecating eap-noob.arpa 5.1.1. Deprecating eap-noob.arpa
IANA has updated the "eap-noob.arpa" entry in the ".ARPA Zone IANA has updated the "eap-noob.arpa" entry in the ".ARPA Zone
Management" registry [ARPAREG] as follows: Management" registry [ARPAREG] as follows:
The USAGE/REFERENCE field has been updated to prefix the text with The USAGE/REFERENCE field has been updated to prefix the text with
(DEPRECATED) and to add a reference to this document (RFC 9965). (DEPRECATED) and to add a reference to this document (RFC 9965).
5.1.2. Defining the eap.arpa. Domain 5.1.2. Defining the eap.arpa. Domain
IANA has updated the ".ARPA Zone Management" registry [ARPAREG] to IANA has updated the ".ARPA Zone Management" registry [ARPAREG] to
include the following entry: include the following entry:
DOMAIN: eap.arpa DOMAIN: eap.arpa
USAGE/REFERENCE: For provisioning within the Extensible USAGE/REFERENCE: For provisioning within the Extensible
Authentication Protocol framework. RFC 9965 Authentication Protocol framework. RFC 9965
IANA has updated the "Special-Use Domain Names" registry (see IANA has updated the "Special-Use Domain Names" registry (see
[SPECIAL-USE]) as follows: [SPECIAL-USE]) as follows:
skipping to change at line 750 skipping to change at line 747
are not expected to recognize these names or treat them are not expected to recognize these names or treat them
differently. differently.
6. DNS Server Operators: These domain names have minimal impact on 6. DNS Server Operators: These domain names have minimal impact on
DNS server operators. They should never be used in DNS or in any DNS server operators. They should never be used in DNS or in any
networking protocol outside of EAP. networking protocol outside of EAP.
Some DNS servers may receive lookups for this domain, if EAP or Some DNS servers may receive lookups for this domain, if EAP or
RADIUS servers are configured to do dynamic discovery for realms RADIUS servers are configured to do dynamic discovery for realms
as defined in [RFC7585], and where those servers are not updated as defined in [RFC7585], and where those servers are not updated
to ignore the ".arpa" domain. When queried for the eap.arpa. to ignore the .arpa domain. When queried for the
domain, DNS servers SHOULD return an NXDOMAIN error. eap.arpa. domain, DNS servers SHOULD return an NXDOMAIN error.
If they try to configure their authoritative DNS as authoritative If they try to configure their authoritative DNS as authoritative
for this reserved name, compliant name servers do not need to do for this reserved name, compliant name servers do not need to do
anything special. They can accept the domain or reject it. anything special. They can accept the domain or reject it.
Either behavior will have no impact on this specification. Either behavior will have no impact on implementations of this
specification.
7. DNS Registries/Registrars: DNS Registries/Registrars should deny 7. DNS Registries/Registrars: DNS Registries/Registrars should deny
requests to register this reserved domain name. requests to register this reserved domain name.
5.2. EAP Provisioning Identifiers Registry 5.2. EAP Provisioning Identifiers Registry
IANA has added the following new registry to the "Extensible IANA has added the following new registry to the "Extensible
Authentication Protocol (EAP) Registry" registry group (see Authentication Protocol (EAP) Registry" registry group (see
[EAPREG]). [EAPREG]).
Assignments in this registry are made via "Expert Review" as Assignments in this registry are made via "Expert Review" as
described in [RFC8126], Section 4.5. Guidelines for experts are described in [RFC8126], Section 4.5. Guidelines for experts are
provided in Section 5.3. provided in Section 5.2.2.
The registry format is as follows: The registry format is as follows:
Title: EAP Provisioning Identifiers Title: EAP Provisioning Identifiers
Registration Procedure(s): Expert Review Registration Procedure(s): Expert Review
Reference: RFC 9965 Reference: RFC 9965
NAI: The Network Access Identifier in the format described in NAI: The Network Access Identifier in the format described in
[RFC7542]. [RFC7542].
Method-Type: The EAP method name, taken from the "Description" field Method Type: The EAP method name, taken from the "Description" field
of the "Method Types" registry (see [EAPREG]) . of the "Method Types" registry (see [EAPREG]) .
Reference: Reference where this identifier was defined. Reference: Reference where this identifier was defined.
5.2.1. Initial Values of the EAP Provisioning Identifiers Registry 5.2.1. Initial Values of the EAP Provisioning Identifiers Registry
+=====================+=============+========================+ +=====================+=============+========================+
| NAI | Method-Type | Reference | | NAI | Method Type | Reference |
+=====================+=============+========================+ +=====================+=============+========================+
| @noob.eap.arpa | EAP-NOOB | [RFC9140] and RFC 9965 | | @noob.eap.arpa | EAP-NOOB | [RFC9140] and RFC 9965 |
+---------------------+-------------+------------------------+ +---------------------+-------------+------------------------+
| portal@tls.eap.arpa | EAP-TLS | [RFC9190] and RFC 9965 | | portal@tls.eap.arpa | EAP-TLS | [RFC9190] and RFC 9965 |
+---------------------+-------------+------------------------+ +---------------------+-------------+------------------------+
Table 1: Initial Values of the EAP Provisioning Table 1: Initial Values of the EAP Provisioning
Identifiers Registry Identifiers Registry
5.3. Guidelines for Designated Experts 5.2.2. Guidelines for Designated Experts
The following text gives guidelines for designated experts who review The following text gives guidelines for designated experts who review
allocation requests for the "EAP Provisioning Identifiers" registry. allocation requests for the "EAP Provisioning Identifiers" registry.
5.3.1. NAIs 5.2.2.1. NAIs
The intent is for the NAI to describe both the EAP Method-Type and The intent is for the NAI to describe both the EAP Method Type and
the purpose of the provisioning method. A descriptive format allows the purpose of the provisioning method. A descriptive format allows
administrators who are unfamiliar with a particular NAI to make administrators who are unfamiliar with a particular NAI to make
reasonable deductions about the provisioning method being requested. reasonable deductions about the provisioning method being requested.
For example, with an EAP Method-Type "name" and a purpose "action", 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 SHOULD be of the form "action@name.eap.arpa".
The NAI MUST satisfy the requirements of the format in [RFC7542], The NAI MUST satisfy the requirements of the format in [RFC7542],
Section 2.2. The utf8-username portion MAY be empty. The Section 2.2. The utf8-username portion MAY be empty. The
utf8-username portion MUST NOT be "anonymous". The NAI MUST be a utf8-username portion MUST NOT be "anonymous". The NAI MUST be a
subdomain within the eap.arpa realm. NAIs with any "v." subdomain subdomain within the eap.arpa realm. NAIs with any "v." subdomain
MUST NOT be registered in order to preserve the functionality of that MUST NOT be registered in order to preserve the functionality of that
subdomain. subdomain.
NAIs in the registry MUST NOT contain more than one subdomain. NAIs NAIs in the registry MUST NOT contain more than one subdomain. NAIs
with a leading "v." subdomain MUST NOT be registered. That subdomain with a leading "v." subdomain MUST NOT be registered. That subdomain
is reserved for vendor and SDO extensions. is reserved for vendor and SDO extensions.
The subdomain of the NAI field should correspond to the EAP Method- The subdomain of the NAI field should correspond to the EAP Method
Type name. Care should be taken so that the domain name conventions Type name. Care should be taken so that the domain name conventions
specified in [STD13] are followed. specified in [STD13] are followed.
The NAIs in this registry are case-insensitive. While [RFC7542] The NAIs in this registry are case-insensitive. While [RFC7542]
notes that similar identifiers of different cases can be considered notes that similar identifiers of different cases can be considered
to be different, this registry requires that all entries MUST be to be different, this registry requires that all entries MUST be
lowercase for simplicity. lowercase for simplicity.
Identifiers MUST be unique when compared in a case-insensitive Identifiers MUST be unique when compared in a case-insensitive
fashion. While [RFC7542] notes that similar identifiers of different fashion. While [RFC7542] notes that similar identifiers of different
skipping to change at line 846 skipping to change at line 844
([RFC2865], Section 5.1). That specification recommends that ([RFC2865], Section 5.1). That specification recommends that
implementations should support User-Names of at least 63 octets. NAI implementations should support User-Names of at least 63 octets. NAI
length considerations are further discussed in [RFC7542], length considerations are further discussed in [RFC7542],
Section 2.3, and any allocations in this registry need to take those Section 2.3, and any allocations in this registry need to take those
limitations into consideration. limitations into consideration.
Implementations are likely to support a total NAI length of 63 Implementations are likely to support a total NAI length of 63
octets. Lengths between 63 and 253 octets may work. Lengths of 254 octets. Lengths between 63 and 253 octets may work. Lengths of 254
octets or more will not work with RADIUS [RFC2865]. octets or more will not work with RADIUS [RFC2865].
5.4. Method-Type 5.2.3. Method Type
Values in the "Method-Type" field of this registry MUST be taken from Values in the "Method Type" field of this registry MUST be taken from
the "Method Types" registry (see [EAPREG]); otherwise, a value MUST the "Method Types" registry (see [EAPREG]); otherwise, a value MUST
be an Expanded Type, which usually indicates a vendor-specific EAP be an Expanded Type, which usually indicates a vendor-specific EAP
method. method.
The EAP Method-Type MUST provide a Master Session Key (MSK) and an The EAP Method Type MUST provide a Master Session Key (MSK) and an
Extended MSK (EMSK) as defined in [RFC3748]. Failure to provide Extended MSK (EMSK) as defined in [RFC3748]. Failure to provide
these keys means that the Method-Type will not be usable within an these keys means that the Method Type will not be usable within an
authentication framework that requires those methods, such as with authentication framework that requires those methods, such as with
IEEE 802.1X. [IEEE802.1X].
5.5. Designated Experts 5.2.4. Designated Experts
The designated expert will post a request to the EAP Method Update The designated expert will post a request to the EAP Method Update
(EMU) WG mailing list (or a successor designated by the Area (EMU) WG mailing list (or a successor designated by the Area
Director) for comment and review, including an I-D or reference to an Director) for comment and review, including an I-D or reference to an
external specification. Before a period of 30 days has passed, the external specification. Before a period of 30 days has passed, the
designated expert will either approve or deny the registration designated expert will either approve or deny the registration
request and publish a notice of the decision to the EMU WG mailing request and publish a notice of the decision to the EMU WG mailing
list (or its successor) as well as inform IANA. A denial notice must list (or its successor) as well as inform IANA. A denial notice must
be justified by an explanation; in the cases where it is possible, be justified by an explanation; in the cases where it is possible,
concrete suggestions on how the request can be modified so as to concrete suggestions on how the request can be modified so as to
become acceptable should be provided. become acceptable should be provided.
5.6. Organization Self Assignment 5.2.5. Organization Self Assignment
The "EAP Provisioning Identifiers" registry allows organizations to The "EAP Provisioning Identifiers" registry allows organizations to
request allocations from it, but explicit allocations are not always request allocations from it, but explicit allocations are not always
required. Any NAI defined in this registry also implicitly defines a required. Any NAI defined in this registry also implicitly defines a
subdomain "v.". Organizations can self-allocate in this space under subdomain "v.". Organizations can self-allocate in this space under
the "v." subdomain, e.g., "local@example.com.v.tls.eap.arpa". the "v." subdomain, e.g., "local@example.com.v.tls.eap.arpa".
The purpose of self-assigned realms is for testing and for future The purpose of self-assigned realms is for testing and for future
expansion. There are currently no use cases being envisioned for expansion. There are currently no use cases being envisioned for
these realms, but we do not wish to forbid future expansion. these realms, but we do not wish to forbid future expansion.
skipping to change at line 963 skipping to change at line 961
session is visible to attackers and can be modified by them. session is visible to attackers and can be modified by them.
The methods defined here MUST only be used to bootstrap initial The methods defined here MUST only be used to bootstrap initial
network access. Once a device has been provisioned, it gains network network access. Once a device has been provisioned, it gains network
access via the provisioned credentials and any network access access via the provisioned credentials and any network access
policies can be applied. policies can be applied.
7.2. Provisioning is Unauthenticated 7.2. Provisioning is Unauthenticated
This specification allows unauthenticated EAP peers to obtain network This specification allows unauthenticated EAP peers to obtain network
access, however limited. As with any unauthenticated process, it can access, however limited. As with any unauthenticated process, this
be abused. Implementations should take care to limit the use of the access can be abused. Implementations should take care to limit the
provisioning network. use of the provisioning network.
Section 3.4.2 describes a number of methods that can be used to Section 3.4.2 describes a number of methods that can be used to
secure the provisioning network. In summary: secure the provisioning network. In summary:
* allow only traffic that is needed for the current provisioning * allow only traffic that is needed for the current provisioning
method. All other traffic should be blocked. Most notable, DNS method. All other traffic should be blocked. Most notable, DNS
has been used to exfiltrate network traffic, so DNS recursive has been used to exfiltrate network traffic, so DNS recursive
resolvers SHOULD NOT be made available on the provisioning resolvers SHOULD NOT be made available on the provisioning
network. network.
* limit the services available on the provisioning network to only * limit the services available on the provisioning network to only
those services that are needed for provisioning. those services that are needed for provisioning.
* limit the number of devices that can access the provisioning * limit the number of devices that can access the provisioning
network at the same time. network at the same time.
* for any one device, rate limit its access the provisioning * for any one device, rate limit its access to the provisioning
network. network.
* for a device that has accessed the provisioning network, limit the * for a device that has accessed the provisioning network, limit the
total amount of time that it is allowed to remain on the network. total amount of time that it is allowed to remain on the network.
* for a device that has accessed the provisioning network, limit the * for a device that has accessed the provisioning network, limit the
total amount of data that it is allowed to transfer through the total amount of data that it is allowed to transfer through the
network. network.
8. References 8. References
skipping to change at line 1048 skipping to change at line 1046
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
8.2. Informative References 8.2. Informative References
[ARPAREG] IANA, ".ARPA Zone Management", [ARPAREG] IANA, ".ARPA Zone Management",
<https://www.iana.org/domains/arpa>. <https://www.iana.org/domains/arpa>.
[CAB] CA/Browser Forum, "CA/Browser Forum", [CAB] CA/Browser Forum, "CA/Browser Forum",
<https://cabforum.org/>. <https://cabforum.org/>.
[EAP-METHOD]
IANA, "Extensible Authentication Protocol (EAP) Registry",
<https://www.iana.org/assignments/eap-numbers>.
[EAPREG] IANA, "Extensible Authentication Protocol (EAP) Registry", [EAPREG] IANA, "Extensible Authentication Protocol (EAP) Registry",
<https://www.iana.org/assignments/eap-numbers>. <https://www.iana.org/assignments/eap-numbers>.
[HOTSPOT] Wi-Fi Alliance, "Passpoint", [HOTSPOT] Wi-Fi Alliance, "Passpoint",
<https://www.wi-fi.org/discover-wi-fi/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-2010, DOI 10.1109/IEEESTD.2010.5409813, 2010,
<https://ieeexplore.ieee.org/document/5409813>.
[INSECURE-RADIUS] [INSECURE-RADIUS]
DeKok, A., "Deprecating Insecure Practices in RADIUS", DeKok, A., "Deprecating Insecure Practices in RADIUS",
Work in Progress, Internet-Draft, draft-ietf-radext- Work in Progress, Internet-Draft, draft-ietf-radext-
deprecating-radius-09, 15 March 2026, deprecating-radius-09, 15 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-radext- <https://datatracker.ietf.org/doc/html/draft-ietf-radext-
deprecating-radius-09>. deprecating-radius-09>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000, RFC 2865, DOI 10.17487/RFC2865, June 2000,
 End of changes. 43 change blocks. 
66 lines changed or deleted 84 lines changed or added

This html diff was produced by rfcdiff 1.48.