The eap.arpa domain and EAP provisioning
draft-ietf-emu-eap-arpa-05

EMU Working Group                                               A. DeKok
Internet-Draft                                        InkBridge Networks
Updates: 9140 (if approved)                               2 January 2025
Intended status: Standards Track                                        
Expires: 6 July 2025

                The eap.arpa domain and EAP provisioning
                       draft-ietf-emu-eap-arpa-05

Abstract

   This document defines the eap.arpa domain as a way for Extensible
   Authentication Protocol (EAP) peers to signal to EAP servers that
   they wish to obtain limited, and unauthenticated, network access.
   EAP peers signal which kind of access is required via certain pre-
   defined identifiers which use the Network Access Identifier (NAI)
   format of RFC 7542.  A table of identifiers and meanings is defined,
   which includes entries for RFC 9140.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-emu-eap-arpa/.

   Discussion of this document takes place on the EMU Working Group
   mailing list (mailto:emut@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/emut/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/emut/.

   Source for this draft and an issue tracker can be found at
   https://github.com/freeradius/eap-arpa.git.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

DeKok                      Expires 6 July 2025                  [Page 1]
Internet-Draft                  eap.arpa                    January 2025

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 6 July 2025.

Copyright Notice

   Copyright (c) 2025 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) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Concepts  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  The eap.arpa realm  . . . . . . . . . . . . . . . . . . .   4
     3.2.  The realm field . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  The username field  . . . . . . . . . . . . . . . . . . .   5
     3.4.  Operation . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.4.1.  EAP Peer  . . . . . . . . . . . . . . . . . . . . . .   6
       3.4.2.  EAP Servers . . . . . . . . . . . . . . . . . . . . .   7
     3.5.  Other Considerations  . . . . . . . . . . . . . . . . . .   8
     3.6.  Considerations for Provisioning Specifications  . . . . .   8
       3.6.1.  Negotiation . . . . . . . . . . . . . . . . . . . . .   8
       3.6.2.  Renewal of Credentials  . . . . . . . . . . . . . . .   9
     3.7.  Notes on AAA Routability  . . . . . . . . . . . . . . . .   9
   4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Review of Existing Functionality  . . . . . . . . . . . .   9
     4.2.  Taxonomy of Provisioning Types  . . . . . . . . . . . . .  10
       4.2.1.  Rationale for Provisioning over EAP . . . . . . . . .  10
   5.  Interaction with existing EAP types . . . . . . . . . . . . .  10
     5.1.  EAP-TLS . . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.2.  TLS-based EAP methods . . . . . . . . . . . . . . . . . .  12
     5.3.  EAP-NOOB  . . . . . . . . . . . . . . . . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     6.1.  .arpa updates . . . . . . . . . . . . . . . . . . . . . .  12
       6.1.1.  Domain Name Reservation Considerations  . . . . . . .  13

DeKok                      Expires 6 July 2025                  [Page 2]
Internet-Draft                  eap.arpa                    January 2025

     6.2.  EAP Provisioning Identifiers Registry . . . . . . . . . .  14
       6.2.1.  Initial Values  . . . . . . . . . . . . . . . . . . .  15
     6.3.  Guidelines for Designated Experts . . . . . . . . . . . .  15
       6.3.1.  NAIs  . . . . . . . . . . . . . . . . . . . . . . . .  15
     6.4.  Method Type . . . . . . . . . . . . . . . . . . . . . . .  16
     6.5.  Designated Experts  . . . . . . . . . . . . . . . . . . .  16
     6.6.  Organization Self Assignment  . . . . . . . . . . . . . .  17
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  17
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
     8.1.  On-Path Attackers and Impersonation . . . . . . . . . . .  18
     8.2.  Provisioning is Unauthenticated . . . . . . . . . . . . .  18
     8.3.  Privacy Considerations  . . . . . . . . . . . . . . . . .  18
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18
   10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     11.2.  Informative References . . . . . . . . . . . . . . . . .  19
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   In most uses, EAP [RFC3748] requires that the EAP peer have pre-
   provisioned credentials.  Without credentials, the device cannot
   obtain network access in order to be provisioned with credentials.
   This limitation creates a bootstrapping problem.

   This specification addresses that problem.  It creates a framework by
   which clients can submit predefined provisioning credentials to a
   server in order to obtain limited network access.  At the same time,
   servers can know in advance that these credentials are to be used
   only for provisioning, and that unrestricted network access should
   not be granted.

   The device can either use the EAP channel itself for provisioning, as
   with TEAP [RFC7170], or the EAP server can give the device access to
   a limited captive portal such as with [RFC8952].  Once the device is
   provisioned, it can use those provisioned credentials to obtain full
   network access.

   The pre-defined credentials use a generic identity format.
   Identifiers in this space are generically referred to as "EAP
   Provisioning Identifiers" (EPI).  The choice of "Provisioning
   Identifiers for EAP" (PIE) was considered and rejected.

DeKok                      Expires 6 July 2025                  [Page 3]
Internet-Draft                  eap.arpa                    January 2025

   Since the identity is predefined, there is little benefit to defining
   pre-defined passwords.  Where supported by the underlying EAP method,
   this specification provides for password-less access.  Where
   passwords are required, the password is defined to be the same as the
   identity.

2.  Terminology

   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.  Concepts

   A device which has no device-specific credentials can use a
   predefined identifier in Network Access Identifier (NAI) format
   [RFC7542].  The NAI is composed of two portions, the utf8-username,
   and the utf8-realm domain.  For simplicity here, we refer to these as
   the "username" and "realm" fields.

   The realm is chosen to be independent of, and unused by, any existing
   organization, and thus to be usable by all organizations.  The realm
   is one which should not be automatically proxied by any any
   Authentication, Authorization, and Accounting (AAA) proxy framework
   as defined in [RFC7542], Section 3.  The realm is also one which will
   not return results for [RFC7585] dynamic discovery.

   This specification does not, however, forbid routing of packets for
   realms in the "eap.arpa" domain.  Instead, it leaves such routing up
   to individual organizations.

   We note that this specification is fully compatible with all existing
   EAP implementations, so it is fail-safe.  When presented with a peer
   wishing to use this specification, existing implementations will
   return EAP Failure, and will not otherwise misbehave.

   We now discuss the NAI format in more detail.  We first discuss the
   eap.arpa realm, and second the use and purpose of the username field.

3.1.  The eap.arpa realm

   This document defines the "eap.arpa" domain as being used for
   provisioning within EAP.  A similar domain has previously been used
   for EAP-NOOB [RFC9140], as "eap-noob.arpa".  This document extends
   that concept, and standardizes the practices surrounding it,

DeKok                      Expires 6 July 2025                  [Page 4]
Internet-Draft                  eap.arpa                    January 2025

   NOTE: the "arpa" domain is controlled by the IAB.  Allocation of
   "eap.arpa" requires agreement from the IAB.

3.2.  The realm field

   The subdomain in realm is assigned via the EAP Provisioning
   Identifier Registry which is defined in Section 6.2.  The subdomain
   MUST follow the domain name conventions specified in [RFC1034].

   It is RECOMMENDED that the first subdomain of "eap.arpa" use the EAP
   method name, as defined in the IANA Extensible Authentication
   Protocol (EAP) Registry, sub-registry "Method Types".  However, that
   registry does not follow the domain name conventions specified in
   [RFC1034], so it is not possible to make a "one-to-one" mapping
   between the Method Type name and the subdomain.

   Where it is not possible to make a direct mapping between the EAP
   Method Type name (e.g.  "TEAP"), and a subdomain (e.g.
   "teap.eap.arpa"), the name used in the realm registry SHOULD be
   similar enough to allow the average reader to understand which EAP
   Method Type is being used.

   Additional subdomains are permitted in the realm, which permit
   vendors and Standards Development organizations (SDOs) the ability to
   self-assign a delegated range of identifiers which cannot conflict
   with other identifiers.

   Any realm defined in this registry (e.g. "teap.eap.arpa") also
   implicitly defines a subdomain "v." (e.g. "v.teap.eap.arpa").
   Vendors or SDOs can self-allocate within the "v." subdomain, using
   domains which they own.  For example, An "example.com" company could
   self-allocate and use the realm "example.com.v.teap.eap.arpa".

3.3.  The username field

   The username field is dependent 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 of "anonymous" is NOT RECOMMENDED for specifications
   using this format, even though it is permitted by [RFC7542].

   The username field is assigned via the EAP Provisioning Identifier
   Registry which is defined in Section 6.2.  The username field MAY be
   empty, or else hold a fixed value.  While [RFC7542] recommends
   omitting the username portion for user privacy, the names here are
   defined in public specifications.  User privacy is therefore not
   needed for provisioning identifiers, and the username field can be
   publicly visible.

DeKok                      Expires 6 July 2025                  [Page 5]
Internet-Draft                  eap.arpa                    January 2025

3.4.  Operation

   Having defined the format and contents of NAIs in the eap.arpa realm,
   we now need to define how those NAIs are used by EAP supplicants and
   EAP peers.

3.4.1.  EAP Peer

   An EAP peer signals that it wishes a certain kind of provisioning by
   using a predefined NAI, along with an associated EAP method.  The
   meaning of the NAI, and behavior of the supplicant are defined by a
   separate specification.  That specification will typically define
   both the NAI, and the EAP method which is used for provisioning.

   The NAI 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.

   EAP peers MUST NOT allow these NAIs to be configured directly by end
   users.  Instead the user (or some other process) chooses a
   provisioning method, and the peer then chooses a predefined NAI which
   matches that provisioning method.

   When all goes well, running EAP with the provisioning NAI results in
   new authentication credentials being provisioned.  The peer then
   drops its network connection, and re-authenticates using the newly
   provisioned credentials.

   There are a number of ways in which provisioning can fail.  One way
   is when the server does not implement the provisioning method.  EAP
   peers therefore MUST track which provisioning methods have been
   tried, and not repeat the same method to the same EAP server when
   receiving a an EAP Nak.  EAP peers MUST rate limit attempts at
   provisioning, in order to avoid overloading the server.

   Another way for provisioning to fail is when the new credentials do
   not result in network access.  It is RECOMMENDED that peers
   immediately try to gain network access using the new credentials, as
   soon as they have been provisioned.  That process allows errors to be
   quickly discovered and addressed.

DeKok                      Expires 6 July 2025                  [Page 6]
Internet-Draft                  eap.arpa                    January 2025

   An EAP peer may be have been provisioned with temporary credentials.
   It SHOULD therefore attempt to provision new credentials before the
   current set expires.  Unfortunately, any re-provisioning process with
   EAP will involve the device dropping off of the "full" network, in
   order to connect to the provisioning network.  It is therefore
   RECOMMENDED that re-provisioning methods be provided which can be
   used when the device has full network access.  See Section 3.6 for
   additional discussion of this topic.

3.4.2.  EAP Servers

   An EAP session begins with the server receiving an initial EAP-
   Request/Identity message.  An EAP server supporting this
   specification MUST examining the identity to see if it uses the
   eap.arpa realm.  If not, the EAP server MUST process the request
   through pre-existing methods.

   If the server receives a malformed NAI in the eap.arpa domain, it
   MUST reply with an EAP Failure, as per [RFC3748], Section 4.2.

   Similarly, if the server does not support the current provisioning
   method, and is unable to negotiate a different one, it MUST reply
   with a NAK of type zero (0) as per [RFC3748], Section 5.3.1.  This
   reply indicates that the requested provisioning method is not
   available, and that the peer should choose a different method of
   authentication.  That different method may be another provisioning
   method, or it may be a full authentication.

   Once the server accepts the provisioning method, it then replies with
   an EAP method which MUST match the one proposed by the supplicant in
   the NAI.  The EAP process then proceeds as per the EAP state machine
   outlined in [RFC3748].

   Implementations MUST treat peers using a provisioning NAI as
   untrusted, and untrustworthy.  Once a peer is authenticated, it MUST
   be placed into a limited network, such as a captive portal.

   Systems implementing this specification SHOULD give peers access
   which is limited in duration.  The provisioning process should be
   fairly quick, and of the order of seconds to tens of seconds in
   duration.  Provisioning times longer than that likely indicate an
   issue.

   Implementations SHOULD give peers access which is limited in scope.
   The provisioning process likely does not need to download large
   amounts of data, and likely does not need access to a large number of
   services.  The provisioning networks SHOULD allow only traffic which
   is necessary for the operation of the named provisioning method.

DeKok                      Expires 6 July 2025                  [Page 7]
Internet-Draft                  eap.arpa                    January 2025

   Implementations SHOULD use functionality such as the RADIUS Filter-Id
   attribute ([RFC2865], Section 5.11) to set packet filters for the
   peer being provisioned.  For ease of administration, the Filter-Id
   name could simply be the provisioning NAI, or a similar name.  Such
   consistency aids with operational considerations when managing
   complex networks.

   Implementations SHOULD rate-limit provisioning attempts.  A
   misbehaving peer should be blocked temporarily, or even permanently.
   Implementations SHOULD limit the total number of peers being
   provisioned at the same time.  There is no requirement to allow all
   peers to connect without limit.

3.5.  Other Considerations

   Implementations MUST NOT permit EAP method negotiation with
   provisioning credentials.  That is, when a provisioning NAI is used,
   any EAP NAK sent by a server MUST contain only EAP type zero (0).
   Similarly, when an EAP peer uses a provisioning NAI and receives an
   EAP NAK, the contents MUST be ignored.

   While a server may support multiple provisioning methods, there is no
   way in EAP to negotiate which provisioning method can be used.  It is
   also expected that the provisioning methods will be specific to a
   particular type of device.  That is, a device is likely to support
   only one provisioning method.

   As a result, there is no need to require a method for negotiating
   provisioning methods.

3.6.  Considerations for Provisioning Specifications

   The operational considerations discussed above have a number of
   impacts on specifications which define provisioning methods.

3.6.1.  Negotiation

   Specifications which define provisioning for an EAP method SHOULD
   provide a method-specific process by which implementations can
   negotiate a mutually acceptable provisioning method.

   For the reasons noted above, however, we cannot make this suggestion
   mandatory.  If it is not possible for a provisioning method to define
   any negotiation, then that limitation should not be a barrier to
   publishing the specification.

DeKok                      Expires 6 July 2025                  [Page 8]
Internet-Draft                  eap.arpa                    January 2025

3.6.2.  Renewal of Credentials

   Where a provisioning method is expected to create credentials which
   do not expire, the specification SHOULD state this explicitly.

   Where credentials expire, it is RECOMMENDED that specifications
   provide guidance on how the credentials are to be updated.  For
   example, an EAP method could permit re-provisioning to be done as
   part of a normal EAP authentication, using the currently provisioned
   credentials.

   It is RECOMMENDED that the provisioning methods provide for a method
   which can be used without affecting network access.  A specification
   could define provisioning endpoints such as Enrollment over Secure
   Transport (EST) [RFC7030], or Automatic Certificate Management
   Environment (ACME) [RFC8555].  The provisioning endpoints could be
   available both on the provisioning network, and on the provisioned
   (i.e. normal) network.  Such an architecture means that devices can
   be re-provisioned without losing network access.

3.7.  Notes on AAA Routability

   When we say that the eap.arpa domain is not routable in an AAA proxy
   framework, we mean that the domain does not exist, and will never
   resolve to anything for dynamic discovery as defined in [RFC7585].
   In addition, administrators will not have statically configured AAA
   proxy routes for this domain.

   In order to avoid spurious DNS lookups, RADIUS servers supporting
   [RFC7585] SHOULD perform filtering in the domains which are sent to
   DNS.  Specifically, names in the "eap.arpa" domain SHOULD NOT be
   looked up in DNS.

4.  Overview

   In this section, we provide background on the existing functionality,
   and describe why it was necessary to define provisioning methods for
   EAP.

4.1.  Review of Existing Functionality

   For EAP-TLS, both [RFC5216] Section 2.1.1 and [RFC9190] provide for
   "peer unauthenticated access".  However, those documents define no
   way for a peer to signal that it is requesting such access.  The
   presumption is that the peer connects with some value for the EAP
   Identity, but without using a client certificate.  The EAP server is
   then supposed to determine that the peer is requesting
   unauthenticated access, and take the appropriate steps to limit

DeKok                      Expires 6 July 2025                  [Page 9]
Internet-Draft                  eap.arpa                    January 2025

   authorization.

   There appears to be no EAP peer or server implementations which
   support such access, since there is no defined way to perform any of
   the steps required.  i.e. to signal that this access is desired, and
   then limit access.

   Wi-Fi Alliance has defined an unauthenticated EAP-TLS method, using a
   vendor-specific EAP type as part of HotSpot 2.0r2 [HOTSPOT].
   However, there appears to be few deployments of this specification.

   EAP-NOOB [RFC9140] takes this process a step further.  It defines
   both a way to signal that provisioning is desired, and also a way to
   exchange provisioning information within EAP-NOOB.  That is, there is
   no need for the device to obtain limited network access, as all of
   the provisioning is done inside of the EAP-NOOB protocol.

   Tunnel Extensible Authentication Protocol (TEAP) [RFC7170] provides
   for provisioning via an unauthenticated TLS tunnel.  That document
   provides for a server unauthenticated provisioning mode, but the
   inner TLS exchange requires that both end authenticate each other.
   There are ways to provision a certificate, but the peer must still
   authenticate itself to the server with pre-existing credentials.

4.2.  Taxonomy of Provisioning Types

   There are two scenarios where provisioning can be done.  The first is
   where provisioning is done within the EAP type, as with EAP-NOOB
   [RFC9140].  The second is where EAP is used to obtain limited network
   access (e.g. as with a captive portal).  That limited network access
   is then used to run IP based provisioning over more complex
   protocols.

4.2.1.  Rationale for Provisioning over EAP

   It is often useful to do all provisioning inside of EAP, because the
   EAP / AAA admin does not have control over the network.  It is not
   always possible to define a captive portal where provisioning can be
   done.  As a result, we need to be able to perform provisioning via
   EAP, and not via some IP protocol.

5.  Interaction with existing EAP types

   As the provisioning identifier is used within EAP, it necessarily has
   interactions with, and effects on, the various EAP types.  This
   section discusses those effects in more detail.

DeKok                      Expires 6 July 2025                 [Page 10]
Internet-Draft                  eap.arpa                    January 2025

   Some EAP methods require shared credentials such as passwords in
   order to succeed.  For example, both EAP-MSCHAPv2 (PEAP) and EAP-PWD
   [RFC5931] perform cryptographic exchanges where both parties knowing
   a shared password.  Where password-based methods are used, the
   password MUST be the same as the provisioning identifier.

   This requirement also applies to TLS-based EAP methods such as EAP
   Tunneled Transport Layer Security (EAP-TTLS) and Protected Extensible
   Authentication Protocol (PEAP).  Where the TLS-based EAP method
   provides for an inner identity and inner authentication method, the
   credentials used there MUST be the provisioning identifier for both
   the inner identity, and any inner password.

   It is RECOMMENDED that provisioning be done via a TLS-based EAP
   methods.  TLS provides for authentication of the EAP server, along
   with security and confidentiality of any provisioning data 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 full EAP
   authentication session while having nothing more than a few
   certification authorities (CAs) locally configured.

5.1.  EAP-TLS

   This document defines an identifier "portal@tls.eap.arpa", which is
   the first step towards enabling unauthenticated client provisioning
   in EAP-TLS.  The purpose of the identifier is to allow EAP peers to
   signal EAP servers that they wish to obtain a "captive portal" style
   network access.

   This identifier signals the EAP server that the peer wishes to obtain
   "peer unauthenticated access" as per [RFC5216] Section 2.1.1 and
   [RFC9190].

   An EAP server which agrees to authenticate this request MUST ensure
   that the device is placed into a captive portal with limited network
   access.  Implementations SHOULD limit both the total amount of data
   transferred by devices in the captive portal, and SHOULD also limit
   the total amount of time a device spends within the captive portal.

   Further details of the captive portal architecture can be found in
   [RFC8952].

   The remaining question is how the EAP peer verifies the identity of
   the EAP server.  The device SHOULD ignore the EAP server certificate
   entirely, as the server's identity does not matter.  Any verification
   of servers can be done at the HTTPS layer when the device access the
   captive portal.  Where possible the device SHOULD warn the end user
   that the provided certificate is unchecked, and untrusted.

DeKok                      Expires 6 July 2025                 [Page 11]
Internet-Draft                  eap.arpa                    January 2025

   However, since the device likely is configured with web CAs
   (otherwise, the captive portal would also be unauthenticated), EAP
   peers MAY use the CAs available for the web in order to validate the
   EAP server certificate.  If the presented certificate passes
   validation, the device does not need to warn the end user that the
   provided certificate is untrusted.

   It is possible to also use TLS-PSK with EAP-TLS for this
   provisioning.  In which case, the Pre-Shared Key (PSK) identity MUST
   the same as the EAP Identifier, and the PSK MUST be the provisioning
   identifier.

5.2.  TLS-based EAP methods

   Other TLS-based EAP methods such as TTLS and PEAP can use the same
   method as defined for EAP-TLS above.  The only difference is that the
   inner identity and password is also the provisioning identifier.

   It is RECOMMENDED that provisioning methods use EAP-TLS in preference
   to any other TLS-based EAP methods.  As the credentials for other
   methods are predefined and known in advance, those methods offer
   little benefit over EAP-TLS.

5.3.  EAP-NOOB

   It is RECOMMENDED that server implementations of Nimble out-of-band
   authentication for EAP (EAP-NOOB) accept both identities "noob@eap-
   noob.arpa" and "@noob.eap.arpa" as synonyms.

   It is RECOMMENDED that EAP-NOOB peers use "@noob.eap.arpa" first, and
   if that does not succeed, use "noob@eap-noob.arpa"

6.  IANA Considerations

   Three IANA actions are required.  The first two are registry updates
   for "eap.arpa".  The second is the creation of a new registry.

6.1.  .arpa updates

   IANA is instructed to update the ".ARPA Zone Management" registry
   with the following entry:

   DOMAIN

      eap.arpa

   USAGE

DeKok                      Expires 6 July 2025                 [Page 12]
Internet-Draft                  eap.arpa                    January 2025

      For provisioning within the Extensible Authentication Protocol
      framework.

   REFERENCE

      THIS-DOCUMENT

   IANA is instructed to update the "Special-Use Domain Names" registry
   as follows:

   NAME

      eap.arpa

   REFERENCE

      THIS-DOCUMENT

6.1.1.  Domain Name Reservation Considerations

   This section answers the questions which are required by Section 5 of
   [RFC6761].  At a high level, these new domain names are used in
   certain situations in EAP.  The domain names are never seen by users,
   and they do not appear in any networking protocol other than EAP.

   1.  Users:
       User are not expected to recognize these names as special or use
       them differently from other domain names.  The use of these names
       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 discusses that behavior.
       EAP supplicants should recognize these names as special, and
       should refuse to allow users to enter them in any interface.
       EAP servers and RADIUS servers should recognize the ".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 are not expected to recognize
       these names or treat them differently.

   4.  Caching DNS Servers:
       Writers of caching DNS servers are not expected to recognize
       these names or treat them differently.

DeKok                      Expires 6 July 2025                 [Page 13]
Internet-Draft                  eap.arpa                    January 2025

   5.  Authoritative DNS Servers:
       Writers of authoritative DNS servers are not expected to
       recognize these names or treat them differently.

   6.  DNS Server Operators:
       These domain names have minimal impact on DNS server operators.
       They should never be used in DNS, or in any networking protocol
       outside of EAP.
       Some DNS servers may receive lookups for this domain, if EAP or
       RADIUS servers are configured to do dynamic discovery for realms
       as defined in [RFC7585], and where those servers are not updated
       to ignore the ".arpa" domain.  When queried for the "eap.arpa"
       domain, DNS servers SHOULD return an NXDOMAIN error.
       If they try to configure their authoritative DNS as authoritative
       for this reserved name, compliant name servers do not need to do
       anything special.  They can accept the domain or reject it.
       Either behavior will have no impact on this specification.

   7.  DNS Registries/Registrars:
       DNS Registries/Registrars should deny requests to register this
       reserved domain name.

6.2.  EAP Provisioning Identifiers Registry

   IANA is instructed to add the following new registry to the
   "Extensible Authentication Protocol (EAP) Registry" group.

   Assignments in this registry are done via "Expert Review" as
   described in [RFC8126] Section 4.5.  Guidelines for experts is
   provided in Section 6.3.

   The contents of the registry are as follows.

   Title

      EAP Provisioning Identifiers

   Registration Procedure(s)

      Expert review

   Reference

      THIS-DOCUMENT

   Registry

      NAI

DeKok                      Expires 6 July 2025                 [Page 14]
Internet-Draft                  eap.arpa                    January 2025

         The Network Access Identifier in [RFC7542] format.  Names are
         lowercase, and are listed in sorted order.

      Method Type

         The EAP method name, taken from the "Description" field of the
         EAP "Method Types" registry.

      Reference

         Reference where this identifier was defined.

6.2.1.  Initial Values

   The following table gives the initial values for this table.

   NAI,Method-Type,Description,Reference

   @noob.eap.arpa,EAP-NOOB,[RFC9140] and THIS-DOCUMENT
   portal@tls.eap.arpa,EAP-TLS,[RFC9190] and THIS-DOCUMENT

6.3.  Guidelines for Designated Experts

   The following text gives guidelines for Designated Experts who review
   allocation requests for this registry.

6.3.1.  NAIs

   The intent is for the NAI to contain both a reference to the EAP
   Method Type, and a description of the purpose of the NAI.  For
   example, with an EAP Method Type "name", and a purpose "action", the
   NAI SHOULD be of the form "action@foo.eap.arpa".

   The NAI MUST satisfy the requirements of the [RFC7542], Section 2.2
   format.  The utf8-username portion MAY be empty.  The utf8-username
   portion MUST NOT be "anonymous".  The NAI MUST end with "eap.arpa".

   NAIs in the registry SHOULD 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 correspond to the EAP Method
   Type name.  Care should be taken so that the domain name conventions
   specified in [RFC1034] are followed.

DeKok                      Expires 6 July 2025                 [Page 15]
Internet-Draft                  eap.arpa                    January 2025

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

   Identifiers MUST be unique when compared in a case-insensitive
   fashion.  While [RFC7542] notes that similar identifiers of different
   case can be considered to be different, 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 needs to take those limitations
   into consideration.

   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].

6.4.  Method Type

   Values in "Method Type" field of this registry MUST be taken from the
   IANA EAP Method Types registry or else it MUST be an Expanded Type
   which usually indicates a vendor specific EAP method.

   The EAP Method Type MUST provide an MSK and EMSK as defined in
   [RFC3748].  Failure to provide these keys means that the method will
   not be usable within an authentication framework which requires those
   methods, such as with IEEE 802.1X.

6.5.  Designated Experts

   For registration requests where a Designated Expert should be
   consulted, the responsible IESG area director should appoint the
   Designated Expert.  But in order to allow for the allocation of
   values prior to the RFC being approved for publication, the
   Designated Expert can approve allocations once it seems clear that an
   RFC will be published.

   The Designated Expert will post a request to the EMU WG mailing list
   (or a successor designated by the Area Director) for comment and
   review, including an Internet-Draft or reference to 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 EAP WG mailing list or its

DeKok                      Expires 6 July 2025                 [Page 16]
Internet-Draft                  eap.arpa                    January 2025

   successor, as well as informing IANA.  A denial notice must be
   justified by an explanation, and in the cases where it is possible,
   concrete suggestions on how the request can be modified so as to
   become acceptable should be provided.

6.6.  Organization Self Assignment

   This registry allows organizations to request allocations from this
   registry, but explicit allocations are not always required.  Any NAI
   defined in this registry also implicitly defines a subdomain "v.".
   Organizations can self-allocate in this space, under the "v."
   subdomain, e.g. "local@example.com.v.tls.eap.arpa".

   Any domain name which is registered as a Fully Qualified Domain Name
   (FQDN) within the DNS can use that name within the "v." subdomain.

   Note that the right to use a self-allocated name is tied the
   ownership of the corresponding domain.  If an organization loses the
   right to use a domain name, then it is no longer appropriate for it
   to use that domain name within the "v." self-allocation space.

7.  Privacy Considerations

   The EAP Identity field is generally publicly visible to parties who
   can observe the EAP traffic.  As the names given here are in a public
   specification, there is no privacy implication to exposing those
   names within EAP.  The entire goal of this specification is in fact
   to make those names public, so that unknown (and private) parties can
   publicly (and anonymously) declare what kind of network access they
   desire.

   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 MAC addresses, device location, etc.

   This specification does not change RADIUS or EAP, and as such does
   not change which information is publicly available, or is kept
   private.  Those issues are dealt with in other specifications, such
   as [I-D.ietf-radext-deprecating-radius].

   However, this specification can increase privacy by allowing devices
   to anonymously obtain network access, and then securely obtain
   credentials.

DeKok                      Expires 6 July 2025                 [Page 17]
Internet-Draft                  eap.arpa                    January 2025

8.  Security Considerations

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

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

8.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, the use of public credentials, and/or skipping
   server validation allows "on-path" attacks to succeed where they
   would normally fail

   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 SHOULD only be used to bootstrap initial
   network access.  All subsequent application-layer traffic SHOULD be
   full authenticated and secured with systems such as IPsec or TLS.

8.2.  Provisioning is Unauthenticated

   We note that this specification allows for unauthenticated
   supplicants to obtain network access, however limited.  As with any
   unauthenticated process, it can be abused.  Implementations should
   take care to limit the use of the provisioning network.

8.3.  Privacy Considerations

   The NAIs used here are contained in a public registry, and therefore
   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, and thus
   has no additional positive or negative implications for privacy.

9.  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.

DeKok                      Expires 6 July 2025                 [Page 18]
Internet-Draft                  eap.arpa                    January 2025

10.  Changelog

   *  00 - initial version

11.  References

11.1.  Normative References

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

   [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/rfc/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/rfc/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/rfc/rfc5216>.

   [RFC7542]  DeKok, A., "The Network Access Identifier", RFC 7542,
              DOI 10.17487/RFC7542, May 2015,
              <https://www.rfc-editor.org/rfc/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/rfc/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/rfc/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/rfc/rfc9140>.

11.2.  Informative References

   [HOTSPOT]  Alliance, W.-F., "Passpoint", n.d.,
              <https://www.wi-fi.org/discover-wi-fi/passpoint>.

DeKok                      Expires 6 July 2025                 [Page 19]
Internet-Draft                  eap.arpa                    January 2025

   [I-D.ietf-radext-deprecating-radius]
              DeKok, A., "Deprecating Insecure Practices in RADIUS",
              Work in Progress, Internet-Draft, draft-ietf-radext-
              deprecating-radius-05, 26 November 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-radext-
              deprecating-radius-05>.

   [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/rfc/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/rfc/rfc5931>.

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, DOI 10.17487/RFC6761, February 2013,
              <https://www.rfc-editor.org/rfc/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/rfc/rfc7030>.

   [RFC7170]  Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
              "Tunnel Extensible Authentication Protocol (TEAP) Version
              1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
              <https://www.rfc-editor.org/rfc/rfc7170>.

   [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/rfc/rfc7585>.

   [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
              Kasten, "Automatic Certificate Management Environment
              (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
              <https://www.rfc-editor.org/rfc/rfc8555>.

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

DeKok                      Expires 6 July 2025                 [Page 20]
Internet-Draft                  eap.arpa                    January 2025

   [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/rfc/rfc9190>.

Author's Address

   Alan DeKok
   InkBridge Networks
   Email: aland@inkbridgenetworks.com

DeKok                      Expires 6 July 2025                 [Page 21]