rfc9965.original.xml   rfc9965.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-model href="rfc7991bis.rnc"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 2.6. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
10) --> -ietf-emu-eap-arpa-10" number="9965" category="std" consensus="true" submissionT
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ype="IETF" updates="5216, 9140, 9190" obsoletes="" xml:lang="en" tocInclude="tru
-ietf-emu-eap-arpa-10" category="std" consensus="true" submissionType="IETF" upd e" sortRefs="true" symRefs="true" version="3">
ates="5216, 9140, 9190" tocInclude="true" sortRefs="true" symRefs="true" version
="3">
<!-- xml2rfc v2v3 conversion 3.24.0 -->
<front> <front>
<title abbrev="eap.arpa">The eap.arpa. domain and EAP provisioning</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-emu-eap-arpa-10"/> <!-- [rfced] We had the following questions related to the document's title:
a) Please note that the title of the document has been updated as
follows:
Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
Style Guide"). Please review.
Original:
The eap.arpa. domain and EAP provisioning
Current:
The eap.arpa. Domain and Extensible Authentication Protocol (EAP) Provisioning
b) Please confirm that no period should appear at the end of the
abbreviated title (that appears in the running header of the PDF
output).
Current:
eap.arpa
-->
<title abbrev="eap.arpa">The eap.arpa. Domain and Extensible Authentication
Protocol (EAP) Provisioning</title>
<seriesInfo name="RFC" value="9965"/>
<author initials="A." surname="DeKok" fullname="Alan DeKok"> <author initials="A." surname="DeKok" fullname="Alan DeKok">
<organization>InkBridge Networks</organization> <organization>InkBridge Networks</organization>
<address> <address>
<email>alan.dekok@inkbridge.io</email> <email>alan.dekok@inkbridge.io</email>
</address> </address>
</author> </author>
<date year="2025" month="September" day="04"/> <date year="2026" month="April"/>
<area>Internet</area> <area>SEC</area>
<workgroup>EMU Working Group</workgroup> <workgroup>emu</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 72?>
<t>This document defines the eap.arpa. domain for use only in Network Access Ide <!-- [rfced] Please insert any keywords (beyond those that appear in
ntifiers (NAIs) as a way for Extensible Authentication Protocol (EAP) peers to the title) for use on https://www.rfc-editor.org/search. -->
signal to EAP servers that they wish to obtain limited, and
unauthenticated, network access. EAP peers signal which kind of access is requi <keyword>example</keyword>
red via certain predefined identifiers which use the Network Access Identifier (
NAI) format of RFC 7542. A table of <abstract>
identifiers and meanings is defined, which includes entries for RFC 9140.</t> <t>This document defines the eap.arpa. domain for use only in Network Access
<t>This document updates RFC5216 and RFC9190 to define an unauthenticated Identifiers (NAIs) as a way for Extensible Authentication Protocol (EAP) peers
provisioning method. Those specifications suggested that such a method has poss to signal to EAP servers that they wish to obtain limited, and
ible, but they did not define how it would be done. This document also updates unauthenticated, network access. EAP peers signal which kind of access is
RFC9140 to deprecate "eap-noob.arpa", and replace it with "@noob.eap.arpa"</t> required via certain predefined identifiers that use the NAI format of RFC 7542.
A table of identifiers and meanings is
defined, which includes entries for RFC 9140.</t>
<t>This document updates RFCs 5216 and 9190 to define an
unauthenticated provisioning method. Those specifications suggest
that such a method is possible, but they do not define how it would be
done. This document also updates RFC 9140 to deprecate "eap-noob.arpa"
and replace it with "@noob.eap.arpa".</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-emu-eap-arpa/"/>.
</t>
<t>
Discussion of this document takes place on the
EMU Working Group mailing list (<eref target="mailto:emut@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/emut/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/emut/"/
>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/freeradius/eap-arpa.git"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 81?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<!--[rfced] Would it make sense to update as follows?
Original:
Without credentials, the device cannot obtain network access in order
to be provisioned with credentials.
Perhaps:
Without pre-provisioned credentials, the device cannot obtain network
access in order to be provisioned with credentials.
Or maybe "Without these credentials"?
-->
<t>In most uses, EAP <xref target="RFC3748"/> requires that the EAP peers have <t>In most uses, EAP <xref target="RFC3748"/> requires that the EAP peers have
pre-provisioned credentials. Without credentials, the device cannot pre-provisioned credentials. Without credentials, the device cannot
obtain network access in order to be provisioned with credentials. obtain network access in order to be provisioned with credentials.
This limitation creates a bootstrapping problem.</t> This limitation creates a bootstrapping problem.</t>
<t>This specification addresses that bootstrapping problem. It creates a <t>This specification addresses that bootstrapping problem. It creates a
framework for predefined "well-known" provisioning credentials, and framework for predefined "well-known" provisioning credentials and
instantiates that framework for two mechanisms.</t> instantiates that framework for two mechanisms.</t>
<t>Clients can submit these predefined provisioning credentials to a serve r in order to <t>Clients can submit these predefined provisioning credentials to a serve r in order to
obtain limited network access. At the same time, servers can know in obtain limited network access. At the same time, servers can know in
advance that these credentials are to be used only for provisioning, advance that these credentials are to be used only for provisioning; thus, they
and avoid granting unrestricted network access to peers which submit these crede can
ntials.</t> avoid granting unrestricted network access to peers that submit these credential
s.</t>
<t>The device can either use the EAP channel itself for provisioning, as <t>The device can either use the EAP channel itself for provisioning, as
with TEAP <xref target="RFC7170"/>, or the EAP server can give the device access to with the Tunnel Extensible Authentication Protocol (TEAP) <xref target="RFC9930" />, or the EAP server can give the device access to
a limited captive portal such as with <xref target="RFC8952"/>. Once the device is a limited captive portal such as with <xref target="RFC8952"/>. Once the device is
provisioned, it can use those provisioned credentials to obtain full provisioned, it can use those provisioned credentials to obtain full
network access.</t> network access.</t>
<t>The predefined provisioning credentials use a generic identity format. <t>The predefined provisioning credentials use a generic identity format.
Identifiers in this space are generically referred to as "EAP Identifiers in this space are generically referred to as "EAP
Provisioning Identifiers" (EPI).</t> Provisioning Identifiers" (or "EPIs").</t>
<t>Since the identity is predefined and used only for unauthenticated netw ork access, there is little benefit to specifying <t>Since the identity is predefined and used only for unauthenticated netw ork access, there is little benefit to specifying
predefined passwords. Where supported by the underlying EAP method, predefined passwords. Where supported by the underlying EAP method,
this specification provides for password-less access. Where passwords this specification provides for password-less access. Where passwords
are required, the password is defined to be the same as the identity.</t> are required, the password is defined to be the same as the identity.</t>
<section anchor="background-and-rationale"> <section anchor="background-and-rationale">
<name>Background and Rationale</name> <name>Background and Rationale</name>
<t>In this section, we provide background on the existing functionality, <t>In this section, we provide background on the existing functionality
and describe why it was necessary to define provisioning methods for and describe why it was necessary to define provisioning methods for
EAP.</t> EAP.</t>
<section anchor="review-of-existing-functionality"> <section anchor="review-of-existing-functionality">
<name>Review of Existing Functionality</name> <name>Review of Existing Functionality</name>
<t>For EAP-TLS, both <xref target="RFC5216"/> Section 2.1.1 and <xref target="RFC9190"/> provide <t>For EAP-TLS, both <xref target="RFC5216" section="2.1.1" sectionFor mat="comma"/> and <xref target="RFC9190"/> provide
for "peer unauthenticated access". However, those documents define no for "peer unauthenticated access". However, those documents define no
way for a peer to signal that it is requesting such access. The 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 presumption is that the peer connects with some value for the EAP
Identity, but without using a client certificate. The EAP server is Identity, but does so without using a client certificate. The EAP server is
then supposed to determine that the peer is requesting unauthenticated then supposed to determine that the peer is requesting unauthenticated
access, and take the appropriate steps to limit authorization.</t> access and take the appropriate steps to limit authorization.</t>
<t>There appears to be no EAP peer or server implementations which <t>There appears to be no EAP peer or server implementations that
support such access, since there is no defined way to perform any of 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 the steps required, i.e., to signal that this access is desired and
then limit access.</t> then limit access.</t>
<t>Wi-Fi Alliance has defined an unauthenticated EAP-TLS method, <t>The Wi-Fi Alliance has defined an unauthenticated EAP-TLS method,
using a vendor-specific EAP method as part of HotSpot 2.0r2 <xref target="HOTSPO T"/>. using a vendor-specific EAP method as part of HotSpot 2.0r2 <xref target="HOTSPO T"/>.
However, there appears to be few deployments of this specification.</t> However, there appear to be few deployments of this specification.</t>
<t>EAP-NOOB <xref target="RFC9140"/> takes this process a step further <t>Nimble Out-of-Band Authentication for EAP (EAP-NOOB) <xref target="
. It defines both RFC9140"/> takes this process a step further. It defines both
a way to signal that provisioning is desired, and also a way to a way to signal that provisioning is desired and a way to
exchange provisioning information within EAP-NOOB. That is, there is exchange provisioning information within EAP-NOOB. That is, there is
no need for the device to obtain limited network access, as all of the no need for the device to obtain limited network access as all of the
provisioning is done inside of the EAP-NOOB protocol.</t> provisioning is done inside of the EAP-NOOB protocol.</t>
<t>Tunnel Extensible Authentication Protocol (TEAP) <xref target="RFC7 <t>TEAP <xref target="RFC9930"/> provides for provisioning via an unau
170"/> provides for provisioning via an unauthenticated TLS thenticated TLS
tunnel. That document provides for a server unauthenticated tunnel. It provides for a server unauthenticated
provisioning mode, but the inner TLS exchange requires that both ends provisioning mode, but the inner TLS exchange requires that both ends
authenticate each other. There are ways to provision a certificate, authenticate each other. There are ways to provision a certificate,
but the peer must still authenticate itself to the server with but the peer must still authenticate itself to the server with
pre-existing credentials. As a result, any provisioning method which uses TEAP will have to address this limitation.</t> preexisting credentials. As a result, any provisioning method that uses TEAP wi ll have to address this limitation.</t>
</section> </section>
<section anchor="taxonomy-of-provisioning-types"> <section anchor="taxonomy-of-provisioning-types">
<name>Taxonomy of Provisioning Types</name> <name>Taxonomy of Provisioning Types</name>
<t>There are two scenarios where provisioning can be done. The first is <t>There are two scenarios where provisioning can be done. The first is
where provisioning is done within the EAP method, as with EAP-NOOB where provisioning is done within the EAP method, as with EAP-NOOB
<xref target="RFC9140"/>. The second is where EAP is used to obtain limited <xref target="RFC9140"/>. The second is where EAP is used to obtain limited
network access (e.g. as with a captive portal). That limited network network access (e.g., as with a captive portal). That limited network
access is then used to run IP based provisioning access is then used to run IP-based provisioning
over more complex protocols.</t> over more complex protocols.</t>
</section> </section>
<section anchor="rationale-for-provisioning-over-eap"> <section anchor="rationale-for-provisioning-over-eap">
<name>Rationale for Provisioning over EAP</name> <name>Rationale for Provisioning over EAP</name>
<t>It is often useful to do all provisioning inside of EAP, because th e EAP / AAA <t>It is often useful to do all provisioning inside of EAP because the EAP / Authentication, Authorization, and Accounting (AAA)
admin does not have control over the network. It is not always admin does not have control over the network. It is not always
possible to define a captive portal where provisioning can be done. 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 As a result, we need to be able to perform provisioning via EAP:
not via some IP protocol.</t> not via some IP.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>EAP Provisioning Identifier</t>
<ul empty="true"> <!--[rfced] Please confirm the use of the period in the following
<li> (i.e., outside the quotation marks). Seems to be related to
<t>The EAP Provisioning Identifier is defined to be a strict domain use.
subset of the Network Access Identifier (NAI) <xref target="RFC7542"/>. The EPI
is an Original:
NAI which is a subdomain of "eap.arpa". The "realm" portion of The EPI is an NAI which is a subdomain of "eap.arpa".
the NAI is defined in <xref section="2.2" sectionFormat="comma" target="RFC7542"
/>, which is a more Perhaps:
restrictive subset of the domain name conventions specified in The EPI is an NAI that is a subdomain of "eap.arpa.".
<xref target="STD13"/>.</t> -->
<t>Readers of this document should note that the realm portion of the <dl spacing="normal" newline="true">
NAI is different from a domain name. In addition to the character <dt>EAP Provisioning Identifier</dt>
set being more limited, the realm portion of the NAI does not <dd><t>The EAP Provisioning Identifier (or EPI) is defined to be a strict subs
include a trailing ".".</t> et of
</li> the NAI <xref target="RFC7542"/>. The EPI is an
</ul> NAI that is a subdomain of "eap.arpa". The "realm" portion of the NAI is
<t>eap.arpa</t> defined in <xref section="2.2" sectionFormat="comma" target="RFC7542"/>,
<ul empty="true"> which is a more restrictive subset of the domain name conventions specified
<li> in <xref target="STD13"/>.</t>
<t>The realm portion of the NAI.</t> <t>Readers of this document should note that the realm portion of the NAI is
<t>This document uses the term "eap.arpa realm" when using that name different from a domain name. In addition to the character set being more
within the contect of an NAI.</t> limited, the realm portion of the NAI does not include a trailing period
</li> (".").</t></dd>
</ul> <dt>eap.arpa</dt>
<t>eap.arpa.</t> <dd><t>The realm portion of the NAI.</t>
<ul empty="true"> <t>This document uses the term "eap.arpa realm" when using that name within
<li> the context of an NAI.</t></dd>
<t>The domain name "eap.arpa.".</t> <dt>eap.arpa.</dt>
<t>This document uses the term "eap.arpa. domain " when using that nam <dd><t>The domain name "eap.arpa.".</t>
e <t>This document uses the term "eap.arpa. domain" when using that name
within the contect of the DNS. The trailing "." is added for within the context of the DNS. The trailing period (".") is added for consist
consistency with DNS specifications.</t> ency
</li> with DNS specifications.</t></dd>
</ul> </dl>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"MAY", and "OPTIONAL" in this document are to be interpreted as IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
only when, they RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
appear in all capitals, as shown here. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<?line -6?> be interpreted as
</t> described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="overview"> <section anchor="overview">
<name>Overview</name> <name>Overview</name>
<t>A device which has no device-specific credentials can use a predefined <t>A device that has no device-specific credentials can use a predefined
provisioning identifier in Network Access Identifier (NAI) format <xref target=" provisioning identifier in NAI format <xref target="RFC7542"/>. The
RFC7542"/>. The NAI is composed of two portions: the utf8-username and the utf8-realm
NAI is composed of two portions, the utf8-username, and the utf8-realm domain. For simplicity, we refer to these as the "username" and
domain. For simplicity here, we refer to these as the "username" and
"realm" fields.</t> "realm" fields.</t>
<t>The realm is chosen to be independent of, and unused by, any existing <t>The realm is chosen to be independent of, and unused by, any existing
organization, and thus to be usable by all organizations. The realm organization; thus, it is to be usable by all organizations. The realm
needs to be one which is not automatically proxied by any existing needs to be one that is not automatically proxied by any existing
Authentication, Authorization, and Accounting (AAA) proxy framework as AAA proxy framework as
defined in <xref section="3" sectionFormat="comma" target="RFC7542"/>. The real m also needs to be one defined in <xref section="3" sectionFormat="comma" target="RFC7542"/>. The real m also needs to be one
which does not return results for <xref target="RFC7585"/> dynamic discovery.</t that does not return results for dynamic discovery as described in <xref target=
> "RFC7585"/>.</t>
<t>This specification does not, however, forbid routing of packets for <t>However, this specification does not forbid the routing of packets for
NAIs in the eap.arpa realm. Instead, it leaves such routing up NAIs in the eap.arpa realm. Instead, it leaves such routing up
to individual organizations.</t> to individual organizations.</t>
<t>This specification is fully compatible with all known <t>This specification is fully compatible with all known
EAP implementations, so it is fail-safe. When presented with a peer EAP implementations, so it is fail-safe. When presented with a peer
wishing to use this specification, existing implementations will wishing to use this specification, existing implementations will
return EAP Failure, and will not otherwise misbehave.</t> return EAP Failure and will not otherwise misbehave.</t>
<section anchor="the-eaparpa-realm"> <section anchor="the-eaparpa-realm">
<name>The eap.arpa realm</name> <name>The eap.arpa Realm</name>
<t>This document defines the eap.arpa realm as being used for <t>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 <xref target="RFC9140"/>, as "eap-noob.arpa". This document extend for EAP-NOOB <xref target="RFC9140"/> as "eap-noob.arpa". This document extends
s that concept and standardizes the practices surrounding it.</t>
that concept, and standardizes the practices surrounding it,</t>
<t>NOTE: the "arpa" domain is controlled by the IAB. Allocation of <!-- [rfced] We had a few questions about the following:
the eap.arpa. domain name requires agreement from the IAB.</t>
<t>RFC-EDITOR: This text can be updated on publication to indicate that Original:
the IAB has approved it.</t> NOTE: the "arpa" domain is controlled by the IAB. Allocation of the
eap.arpa. domain name requires agreement from the IAB.
a) We have updated this text as follows as requested in the RFC Editor
Note. Please review and let us know if you have any objections.
Current:
As the controller of the "arpa" domain, the IAB has approved the
allocation of eap.arpa.
b) We were curious if the reader might need a pointer to where this
agreement could be found? Or any further citation needed here?
-->
<t>NOTE: As the controller of the "arpa" domain, the IAB has approved th
e allocation of eap.arpa.</t>
</section> </section>
<section anchor="the-realm-field"> <section anchor="the-realm-field">
<name>The realm field</name> <name>The Realm Field</name>
<t>The NAIs defined by this specification use the <t>The NAIs defined by this specification use the "realm" field defined
<xref target="RFC7542"/> "realm" field to signal the behavior being requested; i in
n <xref target="RFC7542"/> to signal the behavior being requested; in
particular, the subdomain under the eap.arpa. domain allows for different particular, 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 Identifier Registry <xref target="EAP field is assigned via the "EAP Provisioning Identifiers" registry <xref target="
REG"/>, which EAPREG"/>, which
is defined in <xref target="registry"/>. The subdomain MUST follow the syntax de is defined in <xref target="registry"/>. The subdomain <bcp14>MUST</bcp14> follo
fined in <xref section="2.2" sectionFormat="comma" target="RFC7542"/>, which is w the syntax defined in <xref section="2.2" sectionFormat="comma" target="RFC754
a more restrictive subset of the domain name conventions specified in <xref targ 2"/>, which is a more restrictive subset of the domain name conventions specifie
et="STD13"/>.</t> d in <xref target="STD13"/>.</t>
<t>Where possible, the first subdomain of the eap.arpa. domain SHOULD us
e the EAP <!--[rfced] Please clarify the use of "the EAP registry" in this text:
method name, as defined in the IANA Extensible Authentication Protocol Original: ...However, the EAP registry does not follow the domain
(EAP) Registry group, "Method Types" registry. However, the EAP registry does name conventions specified in...
-->
<t>Where possible, the first subdomain of the eap.arpa. domain <bcp14>SHOULD</bc
p14> use the EAP
method name, as defined in the "Extensible Authentication Protocol
(EAP) Registry" registry group, "Method Types" registry. However, the EAP regis
try does
not follow the domain name conventions specified in <xref target="STD13"/>, so i t not follow the domain name conventions specified in <xref target="STD13"/>, so i t
is not always possible to make a "one-to-one" mapping between the Method Type is not always possible to make a one-to-one mapping between the Method-Type
name and a subdomain of the eap.arpa. domain.</t> name and a subdomain of the eap.arpa. domain.</t>
<t>Where it is not possible to make a direct mapping between the EAP <t>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 <xref section= Method-Type name due to the EAP Method-Type name not matching the <xref section=
"2.2" sectionFormat="comma" target="RFC7542"/> format, the NAI which is defined "2.2" sectionFormat="comma" target="RFC7542"/> format, the NAI that is defined i
in the EAP Provisioning Identifiers registry MUST use a realm name n the "EAP Provisioning Identifiers" registry <bcp14>MUST</bcp14> use a realm na
which is similar enough to allow the average reader to understand which EAP me
Method Type is being used.</t> that is similar enough to allow the average reader to understand which EAP
<t>Additional subdomains are permitted in the realm, which permit vendor Method-Type is being used.</t>
s and <t>Additional subdomains are permitted in the realm; these permit vendor
Standards Development organizations (SDOs) the ability to self-assign s and
a delegated range of identifiers which do not conflict with other Standards Development Organizations (SDOs) the ability to self-assign
a delegated range of identifiers that do not conflict with other
identifiers.</t> identifiers.</t>
<t>Any realm defined in this registry (e.g. "tls.eap.arpa") also <t>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 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 or SDOs can self-allocate within the "v." realm using realms that
they own. For example, a company that owns the "example.com." domain 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". could self-allocate and use the realm "example.com.v.tls.eap.arpa".
See <xref target="vendor-assignment"/> for more discussion of this topic.</t> See <xref target="vendor-assignment"/> for more discussion of this topic.</t>
<t>This specification does not make any provisions for private-use <t>This specification does not make any provisions for private-use
realms. The "v." sub-realm is sufficient for all private uses.</t> realms. The "v." sub-realm is sufficient for all private uses.</t>
<t>Experimental provisioning methods MUST be defined within the <t>Experimental provisioning methods <bcp14>MUST</bcp14> be defined with
appropriate vendors name space. For drafts within the IETF, the "ietf.org" vend in the
or space MUST be used. Different uses SHOULD be distinguished appropriate vendor's name space. For documents within the IETF, the "ietf.org"
vendor space <bcp14>MUST</bcp14> be used. Different uses <bcp14>SHOULD</bcp14>
be distinguished
by using the name of a working group or document, such as by using the name of a working group or document, such as
"emu.ietf.org.v.eap.arpa".</t> "emu.ietf.org.v.eap.arpa".</t>
</section> </section>
<section anchor="the-username-field"> <section anchor="the-username-field">
<name>The username field</name> <name>The Username Field</name>
<t>The username field is dependent on the EAP method being used for <t>The username field is dependent on the EAP method being used for
provisioning. For example, <xref target="RFC9140"/> uses the username "noob". Ot her provisioning. For example, <xref target="RFC9140"/> uses the username "noob". Ot her
EAP methods MAY omit the username as recommended in <xref target="RFC7542"/>. T EAP methods <bcp14>MAY</bcp14> omit the username as recommended in <xref target=
he "RFC7542"/>. The
username of "anonymous" is NOT RECOMMENDED for specifications using username "anonymous" is <bcp14>NOT RECOMMENDED</bcp14> for specifications using
this format, even though it is permitted by <xref target="RFC7542"/>. The name this format, even though it is permitted by <xref target="RFC7542"/>. The name
"anonymous" is widely used in NAIs today, and we wish to avoid "anonymous" is widely used in NAIs today, and we wish to avoid
confusion.</t> confusion.</t>
<t>The username field is assigned via the EAP Provisioning Identifier <t>The username field is assigned via the "EAP Provisioning Identifiers"
Registry which is defined in <xref target="registry"/>. The username field MAY registry, which is defined in <xref target="registry"/>. The username field <bc
be p14>MAY</bcp14> be
empty, or else hold a fixed value. While <xref target="RFC7542"/> recommends empty or hold a fixed value. While <xref target="RFC7542"/> recommends
omitting the username portion for user privacy, the names here are defined omitting the username portion for user privacy, the names here are defined
in public specifications. User privacy is therefore not needed for provisioning in public specifications. Therefore, user privacy is not needed for provisionin
identifiers, g identifiers;
and the username field can be publicly visible.</t> the username field can be publicly visible.</t>
</section> </section>
<section anchor="operation"> <section anchor="operation">
<name>Operation</name> <name>Operation</name>
<!--[rfced] In the following, is "EAP peers" intentionally repeated?
Please review and let us know if a rephrase is necessary.
Original:
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 peers to signal provisioning information
Perhaps:
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 to signal provisioning information.
-->
<t>Having described the format and contents of NAIs in the eap.arpa real m <t>Having described the format and contents of NAIs in the eap.arpa real m
to define the EPI, we now describe how to define the EPI, we now describe how
those EPIs are used by EAP peers and EAP peers to signal provisioning those EPIs are used by EAP peers and EAP peers to signal provisioning
information</t> information.</t>
<section anchor="eap-peers"> <section anchor="eap-peers">
<name>EAP Peers</name> <name>EAP Peers</name>
<t>An EAP peer signals that it wishes a certain kind of <t>An EAP peer signals that it wishes a certain kind of
provisioning by using an EPI, along with an associated EAP provisioning by using an EPI along with an associated EAP
method. The meaning of the EPI, and behavior of the peer, are method. The meaning of the EPI, and behavior of the peer, are
defined by a separate specification. That specification will defined by a separate specification. That specification will
typically define both the EPI, and the EAP method or methods which are used for typically define both the EPI and the EAP method or methods that are used for
provisioning.</t> provisioning.</t>
<t>The EPI used by the peer MUST be taken from an entry in the "EAP <t>The EPI used by the peer <bcp14>MUST</bcp14> be taken from an entry in the "EAP
Provisioning Identifiers" registry, and the EAP method used with that Provisioning Identifiers" registry, and the EAP method used with that
NAI MUST match the corresponding EAP method from that same entry.</t> NAI <bcp14>MUST</bcp14> match the corresponding EAP method from that same entry. </t>
<t>Where an EAP peer allows local selection of a provisioning method, the <t>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 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 which lets the EAP user identif EAP peer <bcp14>MUST NOT</bcp14> have a configuration interface that lets the EA
ier field be P user identifier field be
configured directly. Instead the user (or some other process) chooses configured directly. Instead, the user (or some other process) chooses
a provisioning method, and the EAP peer then selects the EPI a provisioning method and the EAP peer then selects the EPI
which matches that provisioning method.</t> that matches that provisioning method.</t>
<t>While EAP peers allow users to enter user identifiers directly for existing EAP <t>While EAP peers allow users to enter user identifiers directly for existing EAP
methods, they MUST NOT check whether those identfiers match any EPI. Any user w methods, they <bcp14>MUST NOT</bcp14> check whether those identifiers match any
ho EPI. Any user who
enters an identifier which matches an EPI will either get rejected because the s enters an identifier that matches an EPI either will get rejected because the se
erver rver
does not support provisioning, or the user will be placed into a does not support provisioning or the user will be placed into a
captive portal. There is no security or privacy issues with a user captive portal. There are no security or privacy issues with a user
manually entering an EPI as the user identifier.</t> manually entering an EPI as the user identifier.</t>
<t>When all goes well, running EAP with the EPI results in <t>When all goes well, running EAP with the EPI results in
new authentication credentials being provisioned. The peer then drops new authentication credentials being provisioned. The peer then drops
its network connection, and re-authenticates using the newly its network connection and re-authenticates using the newly
provisioned credentials. The user MAY be involved in this process, provisioned credentials. The user <bcp14>MAY</bcp14> be involved in this proces
but in general provisioning results in the EAP peer automatically s,
but, in general, provisioning results in the EAP peer automatically
gaining network access using the provisioned credentials.</t> gaining network access using the provisioned credentials.</t>
<t>There are a number of ways in which provisioning can fail. One way is <t>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 when the server does not implement the provisioning method. Therefore, EAP peer
therefore MUST track which provisioning methods have been tried, and s
<bcp14>MUST</bcp14> track which provisioning methods have been tried and
not repeat the same method to the same EAP server when receiving an not repeat the same method to the same EAP server when receiving an
EAP Nak.</t> EAP Nak.</t>
<t>Peers MUST rate limit their provisioning attempts. If provisioning <t>Peers <bcp14>MUST</bcp14> rate limit their provisioning attempts. If provisioning
fails, it is likely because provisioning is not available. Retrying fails, it is likely because provisioning is not available. Retrying
provisioning repeatedly in quick succession is not likely to change provisioning repeatedly and in quick succession is not likely to change
the server behavior. Instead, it is likely to result in the peer the server behavior. Instead, it is likely to result in the peer
being blocked. The peer SHOULD retry provisioning no more than once being blocked. The peer <bcp14>SHOULD</bcp14> retry provisioning no more than o
every few minutes, and SHOULD include jitter and exponential backoff nce
every few minutes and <bcp14>SHOULD</bcp14> include jitter and exponential backo
ff
on its provisioning attempts.</t> on its provisioning attempts.</t>
<t>Since there is no way to signal whether the failed provisioning is due <t>Since there is no way to signal whether the failed provisioning is due
to a transient failure on the EAP server, or whether it is due to the to a transient failure on the EAP server or due to the
EAP server not supporting that provisioning method, EAP peers SHOULD EAP server not supporting that provisioning method, EAP peers <bcp14>SHOULD</bcp
14>
err on the side of long delays between retrying the same provisioning 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 to an EAP server. EAP peers <bcp14>MAY</bcp14> retry a given provisionin g
method after a sufficiently long interval that the EAP server might method after a sufficiently long interval that the EAP server might
have implemented the provisioning method, e.g., at least a day, and have implemented the provisioning method, e.g., at least a day and
perhaps no more than a month.</t> perhaps no more than a month.</t>
<t>Another way for the provisioning method to fail is when the new <t>Another way for the provisioning method to fail is when the new
credentials do not result in network access. It is RECOMMENDED that credentials do not result in network access. It is <bcp14>RECOMMENDED</bcp14> t
when peers are provisioned with credentials, that they immediately try hat
when peers are provisioned with credentials, they immediately try
to gain network access using those credentials. That process allows to gain network access using those credentials. That process allows
errors to be quickly discovered and addressed.</t> errors to be quickly discovered and addressed.</t>
<t>An EAP peer may have been provisioned with temporary credentials or credentials that expire after some period of time (e.g., an X.509 <t>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). certificate with notAfter date set).
It SHOULD therefore attempt to provision new credentials before the Therefore, it <bcp14>SHOULD</bcp14> attempt to provision new credentials before the
current set expires. Unfortunately, any re-provisioning process with current set expires. Unfortunately, any re-provisioning process with
EAP will involve the device dropping off from the "full" network, in EAP will involve the device dropping off from the "full" network in
order to connect to the provisioning network. It is therefore order to connect to the provisioning network. Therefore, it is
RECOMMENDED that re-provisioning methods be provided which can be used <bcp14>RECOMMENDED</bcp14> that re-provisioning methods be provided that can be
used
when the device has full network access. See <xref target="specifications"/> fo r when the device has full network access. See <xref target="specifications"/> fo r
additional discussion on this topic.</t> additional discussion on this topic.</t>
</section> </section>
<section anchor="eap-servers"> <section anchor="eap-servers">
<name>EAP Servers</name> <name>EAP Servers</name>
<!--[rfced] We had a few questions regarding this text:
Original:
An EAP server supporting this
specification MUST examine the identity to see if it uses a realm
located under eap.arpa.
a) Would it make sense to update this text as follows (to clarify the
trailing "." character?
Perhaps A:
An EAP server supporting this
specification MUST examine the identity to see if it uses a realm
located under the eap.arpa. domain.
Perhaps B:
An EAP server supporting this
specification MUST examine the identity to see if it uses a realm
located under the eap.arpa realm.
b) Would it make sense to reword the following?
Perhaps:
An EAP server implementing this specification...
-->
<t>An EAP session begins with the server receiving an initial <t>An EAP session begins with the server receiving an initial
EAP-Request/Identity message. An EAP server supporting this EAP-Request/Identity message. An EAP server supporting this
specification MUST examine the identity to see if it uses a realm located under specification <bcp14>MUST</bcp14> examine the identity to see if it uses a realm located under
eap.arpa. If so, the identity is an EPI. Processing of all other identities is unchanged by this specification.</t> eap.arpa. If so, the identity is an EPI. Processing of all other identities is unchanged by this specification.</t>
<t>If the server receives an EPI which is malformed, it MUST <t>If the server receives an EPI that is malformed, it <bcp14>MUST</bc
reply with an EAP Failure, as per <xref section="4.2" sectionFormat="comma" targ p14>
et="RFC3748"/>. For example, an NAI may end with the eap.arpa realm, but may al reply with an EAP Failure as per <xref section="4.2" sectionFormat="comma" targe
so contain data which is not permitted by the <xref target="RFC7542"/> format. t="RFC3748"/>. For example, an NAI may end with the eap.arpa realm but may also
contain data that is not permitted by the format described in <xref target="RFC
7542"/>.
Otherwise, the EPI is examined to determine which provisioning method Otherwise, the EPI is examined to determine which provisioning method
is being requested by the peer.</t> is being requested by the peer.</t>
<t>If the server does not recognize the EPI requested by the peer, it <t>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 <bcp14>MUST</bcp14> reply with an EAP Nak of type zero (0). This reply indicate s
that the requested provisioning method is not available. The server that the requested provisioning method is not available. The server
also MUST reply with a Nak of type zero (0) as per <xref section="5.3.1" section also <bcp14>MUST</bcp14> reply with a Nak of type zero (0) as per <xref section=
Format="comma" target="RFC3748"/>, if the peer proposes an EAP method which is n "5.3.1" sectionFormat="comma" target="RFC3748"/> if the peer proposes an EAP met
ot supported by hod that is not supported by
the server, or is not recognized as being valid for that provisioning the server or is not recognized as being valid for that provisioning
method. The peer can then take any remedial action which it method. The peer can then take any remedial action that it
determines to be appropriate.</t> determines to be appropriate.</t>
<t>Once the server accepts the provisioning method, it then replies wi th <t>Once the server accepts the provisioning method, it then replies wi th
an EAP method which MUST match the one associated with the EPI. The EAP process then proceeds as per the EAP state machine an EAP method that <bcp14>MUST</bcp14> match the one associated with the EPI. T he EAP process then proceeds as per the EAP state machine
outlined in <xref target="RFC3748"/>.</t> outlined in <xref target="RFC3748"/>.</t>
<t>Implementations MUST treat peers using an EPI as <t>Implementations <bcp14>MUST</bcp14> treat peers using an EPI as
untrusted, and untrustworthy. Once such a peer is authenticated, it MUST untrusted and untrustworthy. Once such a peer is authenticated, it <bcp14>MUST<
be placed into a limited network, such as a captive portal. The /bcp14>
limited network MUST NOT permit unrestricted network access. be placed into a limited network such as a captive portal. The
Implementations should be aware of methods which bypass simple limited network <bcp14>MUST NOT</bcp14> permit unrestricted network access.
blocking, such as tunneling data over DNS.</t> Implementations should be aware of methods that bypass simple
blocking such as tunneling data over DNS.</t>
<t>A secure provisioning network is one where only the expected traffi c <t>A secure provisioning network is one where only the expected traffi c
is allowed, and all other traffic is blocked. The alternative of is allowed and all other traffic is blocked. The alternative of
blocking only selected "bad" traffic results in substantial security blocking only selected "bad" traffic results in substantial security
failures. As most provisioning methods permit unauthenticated devices failures. As most provisioning methods permit unauthenticated devices
to gain network access, these methods have a substantial potential for to gain network access, these methods have a substantial potential for
abuse by malicious actors. As a result, the limited network needs to abuse by malicious actors. As a result, the limited network needs to
be designed assuming that it will be abused by malicious actor.</t> be designed assuming that it will be abused by malicious actors.</t>
<t>A limited network SHOULD also limit the duration of network access <t>A limited network <bcp14>SHOULD</bcp14> also limit the duration of
by network access by
devices being provisioned. The provisioning process should be fairly devices being provisioned. The provisioning process should be fairly
quick, and in the order of seconds to tens of seconds in duration. quick: in the order of seconds to tens of seconds in duration.
Provisioning times longer than this likely indicate an issue, and it Provisioning times longer than this likely indicate an issue; it
may be useful to block the problematic device from the network.</t> may be useful to block the problematic device from the network.</t>
<t>A limited network SHOULD also limit the amount of data being <t>A limited network <bcp14>SHOULD</bcp14> also limit the amount of da
transferred by devices being provisioned, and SHOULD limit the network ta being
services which are available to those devices. The provisioning transferred by devices being provisioned and <bcp14>SHOULD</bcp14> limit the net
process generally does not need to download large amounts of data, and work
similarly does not need access to a large number of services.</t> services that are available to those devices. The provisioning
<t>Servers SHOULD rate limit provisioning attempts. A misbehaving pee process generally does not need to download large amounts of data;
r similarly, it does not need access to a large number of services.</t>
can be blocked temporarily, or even permanently. Implementations <t>Servers <bcp14>SHOULD</bcp14> rate limit provisioning attempts. A
SHOULD limit the total number of peers being provisioned at the same misbehaving peer
can be blocked temporarily or even permanently. Implementations
<bcp14>SHOULD</bcp14> limit the total number of peers being provisioned at the s
ame
time. There is no requirement for RADIUS servers to allow all peers to time. There is no requirement for RADIUS servers to allow all peers to
connect without limit. Instead, peers are provisioned at the connect without limit. Instead, peers are provisioned at the
discretion of the network being accessed, which may permit or deny discretion of the network being accessed, which may permit or deny
those devices based on reasons which are not explained to those those devices based on reasons that are not explained to those
devices.</t> devices.</t>
<t>Implementations SHOULD use functionality such as the RADIUS Filter- Id <t>Implementations <bcp14>SHOULD</bcp14> use functionality such as the RADIUS Filter-Id
attribute (<xref section="5.11" sectionFormat="comma" target="RFC2865"/>) to lim it network access for the attribute (<xref section="5.11" sectionFormat="comma" target="RFC2865"/>) to lim it network access for the
peer being provisioned, as discussed above in <xref target="eap-servers"/>. For peer being provisioned, as discussed in <xref target="eap-servers"/>. For
ease of administration, the Filter-Id name could simply be the EPI, or ease of administration, the Filter-Id name could simply be the EPI or
a similar name. Such consistency aids with operational considerations a similar name. Such consistency aids with operational considerations
when managing complex networks.</t> when managing complex networks.</t>
<t>Implementations MUST prevent peers in the limited network from <t>Implementations <bcp14>MUST</bcp14> prevent peers in the limited ne twork from
communicating with each other. There is no reason for a system that communicating with each other. There is no reason for a system that
is being provisioned to communicate with anything other than the is being provisioned to communicate with anything other than the
provisioning server(s).</t> provisioning server(s).</t>
</section> </section>
</section> </section>
<section anchor="other-considerations"> <section anchor="other-considerations">
<name>Other Considerations</name> <name>Other Considerations</name>
<t>Implementations MUST NOT permit EAP method negotiation with <t>Implementations <bcp14>MUST NOT</bcp14> permit EAP method negotiation with
provisioning credentials. That is, when an EPI is used, provisioning credentials. That is, when an EPI is used,
any EAP Nak sent by a server must contain only EAP method zero (0). any EAP Nak sent by a server must contain only EAP method zero (0).
When an EAP peer uses an EPI and receives an EAP Nak, any When an EAP peer uses an EPI and receives an EAP Nak, any
EAP methods given in that Nak MUST be ignored.</t> EAP methods given in that Nak <bcp14>MUST</bcp14> be ignored.</t>
<t>While a server may support multiple provisioning methods, there is no <t>While a server may support multiple provisioning methods, there is no
way in EAP to negotiate which provisioning method can be used. It is way in EAP to negotiate which provisioning method can be used. It is
also expected that the provisioning methods will be specific to a also expected that the provisioning methods will be specific to a
particular type of peer device. That is, a given peer is likely to support particular type of peer device. That is, a given peer is likely to support
only one provisioning method.</t> only one provisioning method.</t>
<t>As a result, there is no need to require a method for negotiating <t>As a result, there is no need to require a method for negotiating
provisioning methods.</t> provisioning methods.</t>
</section> </section>
<section anchor="specifications"> <section anchor="specifications">
<name>Considerations for Provisioning Specifications</name> <name>Considerations for Provisioning Specifications</name>
<t>The operational considerations discussed above have a number of <t>The operational considerations discussed in this document have a numb
impacts on specifications which define provisioning methods.</t> er of
impacts on specifications that define provisioning methods.</t>
<section anchor="negotiation"> <section anchor="negotiation">
<name>Negotiation</name> <name>Negotiation</name>
<t>Specifications which define provisioning for an EAP method SHOULD <t>Specifications that define provisioning for an EAP method <bcp14>SH OULD</bcp14>
provide a method-specific process by which implementations can provide a method-specific process by which implementations can
negotiate a mutually acceptable provisioning method.</t> negotiate a mutually acceptable provisioning method.</t>
<t>For the reasons noted above, however, we cannot make this suggestio n <t>However, for the reasons noted in this document, we cannot make thi s suggestion
mandatory. If it is not possible for a provisioning method to define mandatory. If it is not possible for a provisioning method to define
any negotiation, then that limitation should not be a barrier to any negotiation, then that limitation should not be a barrier to
publishing the specification.</t> publishing the specification.</t>
</section> </section>
<section anchor="renewal-of-credentials"> <section anchor="renewal-of-credentials">
<name>Renewal of Credentials</name> <name>Renewal of Credentials</name>
<t>Where a provisioning method is expected to create credentials that do <t>Where a provisioning method is expected to create credentials that do
not expire, the specification SHOULD state this explicitly.</t> not expire, the specification <bcp14>SHOULD</bcp14> state this explicitly.</t>
<t>Where credentials expire, it is RECOMMENDED that specifications <t>Where credentials expire, it is <bcp14>RECOMMENDED</bcp14> that spe
cifications
provide guidance on how the credentials are to be updated. For provide guidance on how the credentials are to be updated. For
example, an EAP method could permit re-provisioning to be done as part example, an EAP method could permit re-provisioning to be done as part
of a normal EAP authentication, using the currently provisioned of a normal EAP authentication using the currently provisioned
credentials.</t> credentials.</t>
<t>It is RECOMMENDED that the provisioning methods provide for a metho <t>It is <bcp14>RECOMMENDED</bcp14> that the provisioning methods prov
d ide for a method
which can be used without affecting network access. A specification that can be used without affecting network access. A specification
could define provisioning endpoints such as Enrollment over Secure could define provisioning endpoints such as Enrollment over Secure
Transport (EST) <xref target="RFC7030"/>, or Internet X.509 Public Key Infrastru cture Transport (EST) <xref target="RFC7030"/> or Internet X.509 Public Key Infrastruc ture
Certificate Management Protocol (CMP) <xref target="RFC9810"/>. The provisionin g endpoints could be Certificate Management Protocol (CMP) <xref target="RFC9810"/>. The provisionin g endpoints could be
available both on the provisioning network, and on the provisioned available both on the provisioning network and on the provisioned
(i.e., normal) network. Such an architecture means that devices can be (i.e., normal) network. Such an architecture means that devices can be
re-provisioned without losing network access.</t> re-provisioned without losing network access.</t>
</section> </section>
</section> </section>
<section anchor="notes-on-aaa-routability"> <section anchor="notes-on-aaa-routability">
<name>Notes on AAA Routability</name> <name>Notes on AAA Routability</name>
<t><xref section="3" sectionFormat="comma" target="RFC7542"/> describes how the NAI allows authentication <t><xref section="3" sectionFormat="comma" target="RFC7542"/> describes how the NAI allows authentication
requests to be routable within an AAA proxy system. While the EPI uses the requests to be routable within a AAA proxy system. While the EPI uses the
NAI format, the eap.arpa realm has been chosen because it is not NAI format, the eap.arpa realm has been chosen because it is not
routable within an AAA proxy system.</t> routable within a AAA proxy system.</t>
<t>When we say that the eap.arpa realm is not routable in an AAA proxy <t>When we say that the eap.arpa realm is not routable in a AAA proxy
system, we mean two different things. First, the eap.arpa. domain system, we mean two different things:</t>
<ol>
<li>The eap.arpa. domain
does not exist within the DNS, so it will never be resolvable for does not exist within the DNS, so it will never be resolvable for
<xref target="RFC7585"/> dynamic discovery. Second, that the eap.arpa realm wil dynamic discovery as described in <xref target="RFC7585"/>.</li>
l <li>The eap.arpa realm will
never be used by any administrator, as the administrator is unable to never be used by any administrator; the administrator is unable to
satisfy the requirements of <xref section="2.5" sectionFormat="comma" target="RF C7542"/> by registering satisfy the requirements of <xref section="2.5" sectionFormat="comma" target="RF C7542"/> by registering
the realm within the DNS.</t> the realm within the DNS.</li>
</ol>
<t>In addition, administrators will not have statically configured AAA <t>In addition, administrators will not have statically configured AAA
proxy routes for this domain. Where routes are added for this domain, proxy routes for this domain. Where routes are added for this domain,
they will generally be used to implement this specification.</t> they will generally be used to implement this specification.</t>
<t>In order to avoid spurious DNS lookups, RADIUS servers supporting <t>In order to avoid spurious DNS lookups, RADIUS servers supporting
<xref target="RFC7585"/> SHOULD perform filtering in the domains which are sent <xref target="RFC7585"/> <bcp14>SHOULD</bcp14> perform filtering in the domains
to that are sent to
DNS. Specifically, names in the eap.arpa. domain MUST NOT be DNS. Specifically, names in the eap.arpa. domain <bcp14>MUST NOT</bcp14> be
looked up in DNS.</t> looked up in DNS.</t>
</section> </section>
</section> </section>
<section anchor="interaction-with-eap-methods"> <section anchor="interaction-with-eap-methods">
<name>Interaction with EAP Methods</name> <name>Interaction with EAP Methods</name>
<t>As the provisioning identifier is used within EAP, it necessarily has <t>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.</t> section discusses those effects in more detail.</t>
<!-- [rfced] We had two questions about the following text:
Original:
For example, both EAP-MSCHAPv2 (PEAP) and EAP-PWD [RFC5931]
perform cryptographic exchanges where both parties knowing a shared
password.
a) We see that [RFC5931] uses "EAP-pwd" rather than "EAP-PWD". Please
review and let us know if any updates are necessary.
Current:
For example, both EAP-MSCHAPv2 (PEAP) and EAP-PWD [RFC5931] perform
cryptographic exchanges where both parties knowing a shared password.
b) Should MSCHAPv2 be expanded to Microsoft Challenge Handshake
Authentication Protocol version 2? If so, how does it interact with
the parenthetical (PEAP)?
-->
<t>Some EAP methods require shared credentials such as passwords in order <t>Some EAP methods require shared credentials such as passwords in order
to succeed. For example, both EAP-MSCHAPv2 (PEAP) and EAP-PWD to succeed. For example, both EAP-MSCHAPv2 (Protected Extensible Authentication Protocol aka PEAP) and EAP-PWD
<xref target="RFC5931"/> perform cryptographic exchanges where both parties <xref target="RFC5931"/> perform cryptographic exchanges where both parties
knowing a shared password. Where password-based methods are used, the know a shared password. Where password-based methods are used, the
password SHOULD be the same as the provisioning identifier, as there password <bcp14>SHOULD</bcp14> be the same as the provisioning identifier, as th
ere
are few reasons to define a method-specific password.</t> are few reasons to define a method-specific password.</t>
<t>This requirement also applies to TLS-based EAP methods such as EAP Tunn eled Transport Layer Security (EAP-TTLS) <t>This requirement also applies to TLS-based EAP methods such as EAP Tunn eled Transport Layer Security (EAP-TTLS)
and Protected Extensible Authentication Protocol (PEAP). Where the TLS-based EA P method provides for an inner and PEAP. Where the TLS-based EAP method provides for an inner
identity and inner authentication method, the credentials used there identity and inner authentication method, the credentials used there
SHOULD be the provisioning identifier for both the inner identity, and <bcp14>SHOULD</bcp14> be the provisioning identifier for both the inner identity and
any inner password.</t> any inner password.</t>
<t>It is RECOMMENDED that provisioning be done via a TLS-based EAP methods <t>It is <bcp14>RECOMMENDED</bcp14> that provisioning be done via a TLS-ba
. sed EAP method.
TLS provides for authentication of the EAP server, along with integrity TLS provides for authentication of the EAP server along with integrity
and confidentiality protection for any provisioning data exchanged in the tunnel . and confidentiality protection for any provisioning data exchanged in the tunnel .
Similarly, if provisioning is done in a captive portal outside of EAP, 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 EAP-TLS permits the EAP peer to run a full EAP authentication session
while having nothing more than a few certificate authorities (CAs) while having nothing more than a few Certificate Authorities (CAs)
locally configured.</t> locally configured.</t>
<section anchor="high-level-requirements"> <section anchor="high-level-requirements">
<name>High Level Requirements</name> <name>High Level Requirements</name>
<t>All provisioning methods which are specified within the eap.arpa. <t>All provisioning methods that are specified within the eap.arpa. doma
domain MUST define a way to authenticate the server. This in <bcp14>MUST</bcp14> 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).</t> are provisioned over HTTPS).</t>
<t>Where TLS-based EAP methods are used, implementations MUST still <t>Where TLS-based EAP methods are used, implementations <bcp14>MUST</bc p14> 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 eap.arpa. domain defines
domain defines that provisioning happen via another protocol such as that provisioning happens via another protocol such as
with HTTPS, the EAP peer MAY skip validating the EAP server with HTTPS, the EAP peer <bcp14>MAY</bcp14> skip validating the EAP server
certificate.</t> certificate.</t>
<t>Whether or not the server certificate is ignored, the peer MUST treat <t>Whether or not the server certificate is ignored, the peer <bcp14>MUS T</bcp14> treat
the local network as untrusted. <xref section="6" sectionFormat="comma" target= "RFC8952"/> has more the local network as untrusted. <xref section="6" sectionFormat="comma" target= "RFC8952"/> has more
discussion on this topic.</t> discussion on this topic.</t>
<t>The ability to not validate the EAP server certificates relaxes the <t>The ability to not validate the EAP server certificates relaxes the
requirements of <xref section="5.3" sectionFormat="comma" target="RFC5216"/> whi requirements of <xref section="5.3" sectionFormat="comma" target="RFC5216"/> tha
ch requires that the t the
server certificate is always validated. For the provisioning case, server certificate always be validated. For provisioning,
it is acceptable in some cases to not validate the EAP server it is acceptable in some cases to not validate the EAP server
certificate, but only so long as there are other means to authenticate certificate but only when there are other means to authenticate
the data which is being provisioned.</t> the data that is being provisioned.</t>
<t>However, since the device likely is configured with web CAs <xref tar <t>However, since the device is likely otherwise configured with web CAs
get="CAB"/> <xref target="CAB"/>, the captive portal would also be unauthenticated
otherwise, the captive portal would also be unauthenticated,
provisioning methods could use those CAs within an EAP method in order provisioning methods could use those CAs within an EAP method in order
to allow the peer to authenticate the EAP server. Further discussion to allow the peer to authenticate the EAP server. Further discussion
of this topic is better suited for the specification(s) which define a of this topic is better suited for the specification(s) that define a
particular provisioning method. This issue is not discussed further here, particular provisioning method. This issue is not discussed further here,
other than to say that it is technically possible.</t> other than to say that it is technically possible.</t>
</section> </section>
<section anchor="eap-tls"> <section anchor="eap-tls">
<name>EAP-TLS</name> <name>EAP-TLS</name>
<t>This document defines an NAI "portal@tls.eap.arpa", which <t>This document defines an NAI called "portal@tls.eap.arpa", which
allows EAP peers to use unauthenticated EAP-TLS. The purpose of the allows EAP peers to use unauthenticated EAP-TLS. The purpose of the
identifier is to allow EAP peers to signal EAP servers that they wish identifier is to allow EAP peers to signal to EAP servers that they wish
to obtain a "captive portal" style network access.</t> to obtain "captive portal" network access.</t>
<t>This identifier signals the EAP server that the peer wishes to obtain <t>This identifier signals to the EAP server that the peer wishes to obt
ain
"peer unauthenticated access" as per <xref section="2.1.1" sectionFormat="comma" target="RFC5216"/> and "peer unauthenticated access" as per <xref section="2.1.1" sectionFormat="comma" target="RFC5216"/> and
<xref target="RFC9190"/>. Note that peer unauthenticated access MUST provide fo r <xref target="RFC9190"/>. Note that peer unauthenticated access <bcp14>MUST</bc p14> provide for
authentication of the EAP server, such as with a server certificate. authentication of the EAP server, such as with a server certificate.
Using TLS-PSK with a well-known PSK value is generally not Using TLS-PSK with a well-known Pre-Shared Key (PSK) value is generally not
appropriate, as it would not provide server authentication.</t> appropriate, as it would not provide server authentication.</t>
<t>An EAP server which agrees to authenticate this request MUST ensure <t>An EAP server that agrees to authenticate this request <bcp14>MUST</b cp14> 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 <xref target="eap-servers"/>.</t> access as discussed above in <xref target="eap-servers"/>.</t>
<t>This method is an improvement over existing captive portals, which ar e <t>This method is an improvement over existing captive portals, which ar e
typically completely unsecured and unauthenticated. Using peer 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 ensures that the link
between the EAP peer and EAP authenticator (e.g. access point) is also between the EAP peer and EAP authenticator (e.g., access point) is also
secured.</t> secured.</t>
<!--[rfced] Please review the use of 802.11u in the following. As all
other instances are to 802.11X, is this use intentional? If so,
should a pointer to 802.11u be added?
Original:
The captive portal can advertise support for the eap.arpa. domain via
an 802.11u realm.
-->
<t>Further details of the captive portal architecture can be found in <t>Further details of the captive portal architecture can be found in
<xref target="RFC8952"/>. The captive portal can advertise support for the <xref target="RFC8952"/>. The captive portal can advertise support for the
eap.arpa. domain via an 802.11u realm.</t> eap.arpa. domain via an 802.11u realm.</t>
</section> </section>
<section anchor="eap-noob"> <section anchor="eap-noob">
<name>EAP-NOOB</name> <name>EAP-NOOB</name>
<t>It is RECOMMENDED that server implementations of Nimble out-of-band a uthentication for EAP (EAP-NOOB) accept both <t>It is <bcp14>RECOMMENDED</bcp14> that server implementations of EAP-N OOB accept both
identities "noob@eap-noob.arpa" and "@noob.eap.arpa" as synonyms.</t> identities "noob@eap-noob.arpa" and "@noob.eap.arpa" as synonyms.</t>
<t>It is RECOMMENDED that EAP-NOOB peers use "@noob.eap.arpa" first, and <t>It is <bcp14>RECOMMENDED</bcp14> that EAP-NOOB peers use "@noob.eap.a
if that does not succeed, use "noob@eap-noob.arpa".</t> rpa" first and,
if that does not succeed, then they use "noob@eap-noob.arpa".</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>A number of IANA actions are required. There are two registry updates
in <!--[rfced] We had several questions related to the IANA
order to define the eap.arpa. domain. A new registry is created. The Considerations in this document.
"noob@eap-noob.arpa" registry entry is deprecated.</t>
a) We note that Section 5 (IANA Considerations) describes some of
what's to come in the subsections of Section 5. This pointed out to
us that perhaps Sections 5.3, 5.3.1, 5.4, and 5.5 should actually be
subsections of Section 5.2 (i.e., what registry does "...this
registry" in Section 5.3 refer to?).
Original:
A number of IANA actions are required. There are two registry
updates in order to define the eap.arpa. domain. A new registry is
created. The "noob@eap-noob.arpa" registry entry is deprecated.
Current:
This document describes a number of IANA actions:
- There are two registry updates in order to define the
eap.arpa. domain (see Section 5.1).
- A new registry is created (see Section 5.2).
- The "noob@eap-noob.arpa" registry entry is deprecated (see Section 5.1.1).
Perhaps:
This document describes a number of IANA actions:
-IANA has made two registry updates in order to define the
eap.arpa. domain (see Section 5.1).
-IANA has created a new registry (see Section 5.2).
With the reorganization of the sections as mentioned above? Please
review and advise.
b) Note that we have updated mentions of ".arpa registry" to point
instead to the ".ARPA Zone Management" registry.
Please review and advise if this was not what was intended.
c) For the ease of the reader, we have added some citations as well as
an informative reference to the Special-Use Domain Names registry.
Please let us know any objections.
d) In point 6 of Section 5.1.2.1, we see:
Original:
Either behavior will have no impact on this specification.
Would the behavior have an effect on this document (or the content
therein)? Please review.
e) We see that the "EAP Provisioning Identifiers" registry uses
"Method-Type" while the registry itself uses "Method Type" (with no
hyphen). May we update uses of Method-Type to read as Method Type
throughout? Note that we will communicate this change (as well as any
other changes related to IANA registries) to IANA once AUTH48
completes.
-->
<t>This document describes a number of IANA actions:</t>
<ul>
<li>There are two registry updates in
order to define the eap.arpa. domain (<xref target="arpa-updates"/>).</li>
<li>A new registry is created (see <xref target="registry"/>).</li>
<li>The
"noob@eap-noob.arpa" registry entry is deprecated (see <xref target="deprecating
-eap-noobarpa"/>).</li></ul>
<section anchor="arpa-updates"> <section anchor="arpa-updates">
<name>.arpa updates</name> <name>.arpa Updates</name>
<t>There are two updates to the ".arpa" registry.</t> <t>There are two updates to the ".ARPA Zone Management" registry <xref t
<t>IANA is also instructed to refuse further allocation requests which arget="ARPAREG"/> (detailed in Sections <xref target="deprecating-eap-noobarpa"
are directly within the ".arpa" registry for any functionality related format="counter"/> and <xref target="defining-the-eaparpa-domain" format="counte
to the EAP protocol. Instead, allocations related to EAP are to r"/>).</t>
be made within the new "EAP Provisioning Identifiers" registry.</t> <t>IANA has also been instructed to refuse further allocation requests t
hat
are directly within the ".ARPA Zone Management" registry for any functionality r
elated
to the EAP. Instead, allocations related to EAP are to
be made within the new "EAP Provisioning Identifiers" registry in the "Extensibl
e Authentication Protocol (EAP) Registry" registry group (see <xref target="EAPR
EG"/>).</t>
<section anchor="deprecating-eap-noobarpa"> <section anchor="deprecating-eap-noobarpa">
<name>Deprecating eap-noob.arpa</name> <name>Deprecating eap-noob.arpa</name>
<t>IANA is instructed to update the "eap-noob.arpa" entry as follows.< <t>IANA has updated the "eap-noob.arpa" entry in the ".ARPA Zone Manag
/t> ement" registry <xref target="ARPAREG"/> as follows:</t>
<t>The USAGE field is updated to prefix the text with the word DEPRECA <t>The USAGE/REFERENCE field has been updated to prefix the text with
TED.</t> (DEPRECATED) and to add a reference to this document (RFC 9965).</t>
<t>The REFERENCE field is updated to add a reference to THIS-DOCUMENT.
</t>
</section> </section>
<section anchor="defining-the-eaparpa-domain"> <section anchor="defining-the-eaparpa-domain">
<name>Defining the eap.arpa. Domain</name> <name>Defining the eap.arpa. Domain</name>
<t>IANA is instructed to update the ".ARPA Zone Management" registry < xref target="ARPAREG"/> with <t>IANA has updated the ".ARPA Zone Management" registry <xref target= "ARPAREG"/> to include
the following entry:</t> the following entry:</t>
<t>DOMAIN</t>
<ul empty="true"> <dl spacing="compact" newline="false">
<li> <dt>DOMAIN:</dt><dd>eap.arpa</dd>
<t>eap.arpa</t> <dt>USAGE/REFERENCE:</dt><dd>For provisioning within the Extensible Authentica
</li> tion Protocol framework. RFC 9965</dd>
</ul> </dl>
<t>USAGE</t>
<ul empty="true"> <t>IANA has updated the "Special-Use Domain Names" registry (see <xref
<li> target="SPECIAL-USE"/>) as follows:</t>
<t>For provisioning within the Extensible Authentication Protocol <dl spacing="compact" newline="false">
framework.</t> <dt>Name:</dt><dd>eap.arpa.</dd>
</li> <dt>Reference:</dt> <dd>RFC 9965</dd>
</ul> </dl>
<t>REFERENCE</t>
<ul empty="true">
<li>
<t>THIS-DOCUMENT</t>
</li>
</ul>
<t>IANA is instructed to update the "Special-Use Domain Names" registr
y as follows:</t>
<t>NAME</t>
<ul empty="true">
<li>
<t>eap.arpa.</t>
</li>
</ul>
<t>REFERENCE</t>
<ul empty="true">
<li>
<t>THIS-DOCUMENT</t>
</li>
</ul>
<section anchor="domain-name-reservation-considerations"> <section anchor="domain-name-reservation-considerations">
<name>Domain Name Reservation Considerations</name> <name>Domain Name Reservation Considerations</name>
<t>This section answers the questions which are required by Section <t>This section answers the questions that are required by <xref tar
5 of <xref target="RFC6761"/>. At a high level, these new domain names are used get="RFC6761" section="5"/>. At a high level, these new domain names are used i
in certain situations in EAP. The domain names are never seen by users, and th n certain situations in EAP. The domain names are never seen by users, and they
ey do not appear in any networking protocol other than EAP.</t> do not appear in any networking protocol other than EAP.</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1">
<li>
<t>Users: <t>Users:
User are not expected to recognize these names as special or use them differentl y from other domain names. The use of these names in EAP is invisible to end us ers.</t> Human users are not expected to recognize these names as special or use them dif ferently from other domain names. The use of these names in EAP is invisible to end users.</t>
</li> </li>
<li> <li>
<t>Application Software: <t>Application Software:
EAP servers and clients are expected to make their software recognize these name s as special and treat them differently. This document discusses that behavior. EAP servers and clients are expected to make their software recognize these name s as special and treat them differently. This document discusses that behavior.
EAP peers should recognize these names as special, and should refuse to allow us EAP peers should recognize these names as special and should refuse to allow use
ers to enter them in any interface. rs to enter them in any interface.
EAP servers and RADIUS servers should recognize the eap.arpa. domain as special, EAP servers and RADIUS servers should recognize the eap.arpa. domain as special
and refuse to do dynamic discovery (<xref target="RFC7585"/>) for it.</t> and refuse to do dynamic discovery (<xref target="RFC7585"/>) for it.</t>
</li> </li>
<li> <li>
<t>Name Resolution APIs and Libraries: <t>Name Resolution APIs and Libraries:
Writers of these APIs and libraries are not expected to recognize these names or treat them differently.</t> Writers of these APIs and libraries are not expected to recognize these names or treat them differently.</t>
</li> </li>
<li> <li>
<t>Caching DNS Servers: <t>Caching DNS Servers:
Writers of caching DNS servers are not expected to recognize these names or trea t them differently.</t> Writers of caching DNS servers are not expected to recognize these names or trea t them differently.</t>
</li> </li>
<li> <li>
<t>Authoritative DNS Servers: <t>Authoritative DNS Servers:
Writers of authoritative DNS servers are not expected to recognize these names o r treat them differently.</t> Writers of authoritative DNS servers are not expected to recognize these names o r treat them differently.</t>
</li> </li>
<li> <li>
<t>DNS Server Operators: <t>DNS Server Operators:
These domain names have minimal impact on DNS server operators. They should nev These domain names have minimal impact on DNS server operators. They should nev
er be used in DNS, or in any networking protocol outside of EAP.<br/> er be used in DNS or in any networking protocol outside of EAP.</t>
Some DNS servers may receive lookups for this domain, if EAP or RADIUS servers a <t>Some DNS servers may receive lookups for this domain, if EAP or RADIUS server
re configured to do dynamic discovery for realms as defined in <xref target="RFC s are configured to do dynamic discovery for realms as defined in <xref target="
7585"/>, and where those servers are not updated to ignore the ".arpa" domain. 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 err . When queried for the eap.arpa. domain, DNS servers <bcp14>SHOULD</bcp14> retu
or.<br/> rn an NXDOMAIN error.</t>
If they try to configure their authoritative DNS as authoritative for this reser <t>If they try to configure their authoritative DNS as authoritative for this re
ved name, compliant name servers do not need to do anything special. They can a served name, compliant name servers do not need to do anything special. They ca
ccept the domain or reject it. Either behavior will have no impact on this spec n accept the domain or reject it. Either behavior will have no impact on this s
ification.</t> pecification.</t>
</li> </li>
<li> <li>
<t>DNS Registries/Registrars: <t>DNS Registries/Registrars:
DNS Registries/Registrars should deny requests to register this reserved domain name.</t> DNS Registries/Registrars should deny requests to register this reserved domain name.</t>
</li> </li>
</ol> </ol>
</section> </section>
</section> </section>
</section> </section>
<section anchor="registry"> <section anchor="registry">
<name>EAP Provisioning Identifiers Registry</name> <name>EAP Provisioning Identifiers Registry</name>
<t>IANA is instructed to add the following new registry to the "Extensib <t>IANA has added the following new registry to the "Extensible Authenti
le Authentication Protocol (EAP) Registry" group.</t> cation Protocol (EAP) Registry" registry group (see <xref target="EAPREG"/>).</t
<t>Assignments in this registry are done via "Expert Review" as describe >
d in <xref target="RFC8126"/> Section 4.5. Guidelines for experts is provided i <t>Assignments in this registry are made via "Expert Review" as describe
n <xref target="guidelines"/>.</t> d in <xref target="RFC8126" sectionFormat="comma" section="4.5"/>. Guidelines f
<t>The contents of the registry are as follows.</t> or experts are provided in <xref target="guidelines"/>.</t>
<t>Title</t> <t>The registry format is as follows:</t>
<ul empty="true">
<li> <dl spacing="compact" newline="false">
<t>EAP Provisioning Identifiers</t> <dt>Title:</dt>
</li> <dd>EAP Provisioning Identifiers</dd>
</ul> <dt>Registration Procedure(s):</dt>
<t>Registration Procedure(s)</t> <dd>Expert Review</dd>
<ul empty="true"> <dt>Reference:</dt>
<li> <dd>RFC 9965</dd>
<t>Expert review</t> <dt>NAI:</dt>
</li> <dd>The Network Access Identifier in the format described in <xref target="RFC
</ul> 7542"/>.</dd>
<t>Reference</t> <dt>Method-Type:</dt>
<ul empty="true"> <dd>The EAP method name, taken from the "Description" field of the "Method Typ
<li> es" registry (see <xref target="EAPREG"/>) .</dd>
<t>THIS-DOCUMENT</t> <dt>Reference:</dt>
</li> <dd>Reference where this identifier was defined.</dd>
</ul> </dl>
<t>Registry</t>
<ul empty="true">
<li>
<t>NAI</t>
<ul empty="true">
<li>
<t>The Network Access Identifier in <xref target="RFC7542"/> for
mat.</t>
</li>
</ul>
<t>Method Type</t>
<ul empty="true">
<li>
<t>The EAP method name, taken from the "Description" field of th
e EAP "Method Types" registry.</t>
</li>
</ul>
<t>Reference</t>
<ul empty="true">
<li>
<t>Reference where this identifier was defined.</t>
</li>
</ul>
</li>
</ul>
<section anchor="initial-values"> <section anchor="initial-values">
<name>Initial Values</name> <name>Initial Values of the EAP Provisioning Identifiers Registry</nam
<t>The following table gives the initial values for this table.</t> e>
<table> <table>
<name>Initial Values of the EAP Provisioning Identifiers Registry</n ame>
<thead> <thead>
<tr> <tr>
<th align="left">NAI</th> <th align="left">NAI</th>
<th align="left">Method-Type</th> <th align="left">Method-Type</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">@noob.eap.arpa</td> <td align="left">@noob.eap.arpa</td>
<td align="left">EAP-NOOB</td> <td align="left">EAP-NOOB</td>
<td align="left"> <td align="left">
<xref target="RFC9140"/> and THIS-DOCUMENT</td> <xref target="RFC9140"/> and RFC 9965</td>
</tr> </tr>
<tr> <tr>
<td align="left">portal@tls.eap.arpa</td> <td align="left">portal@tls.eap.arpa</td>
<td align="left">EAP-TLS</td> <td align="left">EAP-TLS</td>
<td align="left"> <td align="left">
<xref target="RFC9190"/> and THIS-DOCUMENT</td> <xref target="RFC9190"/> and RFC 9965</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section anchor="guidelines"> <section anchor="guidelines">
<name>Guidelines for Designated Experts</name> <name>Guidelines for Designated Experts</name>
<t>The following text gives guidelines for Designated Experts who review <t>The following text gives guidelines for designated experts who review
allocation requests for this registry.</t> allocation requests for the "EAP Provisioning Identifiers" registry.</t>
<section anchor="nais"> <section anchor="nais">
<name>NAIs</name> <name>NAIs</name>
<t>The intent is for the NAI to describe both the EAP <t>The intent is for the NAI to describe both the EAP
Method Type, and the purpose of the provisining method. A descriptive format al Method-Type and the purpose of the provisioning method. A descriptive format al
lows administrators who are unfamiliar with a particular NAI to make reasonable lows administrators who are unfamiliar with a particular NAI to make reasonable
deductions about the provisioning method being requested. For deductions about the provisioning method being requested. For
example, with an EAP Method Type "name", and a purpose "action", the example, with an EAP Method-Type "name" and a purpose "action", the
NAI SHOULD be of the form "action@name.eap.arpa".</t> NAI <bcp14>SHOULD</bcp14> be of the form "action@name.eap.arpa".</t>
<t>The NAI MUST satisfy the requirements of the <xref section="2.2" se <t>The NAI <bcp14>MUST</bcp14> satisfy the requirements of the format
ctionFormat="comma" target="RFC7542"/> in <xref section="2.2" sectionFormat="comma" target="RFC7542"/>. The utf8-usern
format. The utf8-username portion MAY be empty. The utf8-username ame portion <bcp14>MAY</bcp14> be empty. The utf8-username
portion MUST NOT be "anonymous". The NAI MUST be a subdomain within the eap.arp portion <bcp14>MUST NOT</bcp14> be "anonymous". The NAI <bcp14>MUST</bcp14> be
a realm. a subdomain within the eap.arpa realm.
NAIs with any "v." subdomain MUST NOT be registered, in order to NAIs with any "v." subdomain <bcp14>MUST NOT</bcp14> be registered in order to
preserve the functionality of that subdomain.</t> preserve the functionality of that subdomain.</t>
<t>NAIs in the registry MUST NOT contain more than one subdomain. NAI <t>NAIs in the registry <bcp14>MUST NOT</bcp14> contain more than one
s subdomain. NAIs
with a leading "v." subdomain MUST NOT be registered. That subdomain with a leading "v." subdomain <bcp14>MUST NOT</bcp14> be registered. That subdo
main
is reserved for vendor and SDO extensions.</t> is reserved for vendor and SDO extensions.</t>
<t>The subdomain of the NAI field should correspond to the EAP Method <t>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 <xref target="STD13"/> are followed.</t> specified in <xref target="STD13"/> are followed.</t>
<t>The NAIs in this registry are case-insensitive. While <xref target ="RFC7542"/> <t>The NAIs in this registry are case-insensitive. While <xref target ="RFC7542"/>
notes that similar identifiers of different case can be considered to notes that similar identifiers of different cases can be considered to
be different, for simplicity this registry requires that all entries be different, this registry requires that all entries
MUST be lowercase.</t> <bcp14>MUST</bcp14> be lowercase for simplicity.</t>
<t>Identifiers MUST be unique when compared in a case-insensitive <t>Identifiers <bcp14>MUST</bcp14> be unique when compared in a case-i
nsensitive
fashion. While <xref target="RFC7542"/> notes that similar identifiers of fashion. While <xref target="RFC7542"/> notes that similar identifiers of
different case can be considered to be different, this registry is different cases can be considered to be different, this registry is
made simpler by requiring case-insensitivity.</t> made simpler by requiring case-insensitivity.</t>
<t>Entries in the registry should be short. NAIs defined here will <t>Entries in the registry should be short. NAIs defined here will
generally be sent in a RADIUS packet in the User-Name attribute generally be sent in a RADIUS packet in the User-Name attribute
(<xref target="RFC2865"/> Section 5.1). That specification recommends that (<xref target="RFC2865" sectionFormat="comma" section="5.1"/>). That specificat ion 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 <xref target="RFC7542"/> Section length considerations are further discussed in <xref target="RFC7542" sectionFor
2.3, and any allocations in this registry needs to take those mat="comma" section="2.3"/>, and any allocations in this registry need to take t
hose
limitations into consideration.</t> limitations into consideration.</t>
<t>Implementations are likely to support a total NAI length of 63 octe ts. <t>Implementations are likely to support a total NAI length of 63 octe ts.
Lengths between 63 and 253 octets may work. Lengths of 254 octets or Lengths between 63 and 253 octets may work. Lengths of 254 octets or
more will not work with RADIUS <xref target="RFC2865"/>.</t> more will not work with RADIUS <xref target="RFC2865"/>.</t>
</section> </section>
</section> </section>
<section anchor="method-type"> <section anchor="method-type">
<name>Method Type</name> <name>Method-Type</name>
<t>Values in "Method Type" field of this registry MUST be taken from the <t>Values in the "Method-Type" field of this registry <bcp14>MUST</bcp14
IANA EAP Method Types registry or else it MUST be an Expanded Type > be taken from the
which usually indicates a vendor specific EAP method.</t> "Method Types" registry (see <xref target="EAPREG"/>); otherwise, a value <bcp14
<t>The EAP Method Type MUST provide an MSK and EMSK as defined in >MUST</bcp14> be an Expanded Type,
<xref target="RFC3748"/>. Failure to provide these keys means that the method w which usually indicates a vendor-specific EAP method.</t>
ill <t>The EAP Method-Type <bcp14>MUST</bcp14> provide a Master Session Key
not be usable within an authentication framework which requires those (MSK) and an Extended MSK (EMSK) as defined in
<xref target="RFC3748"/>. Failure to provide these keys means that the Method-T
ype will
not be usable within an authentication framework that requires those
methods, such as with IEEE 802.1X.</t> methods, such as with IEEE 802.1X.</t>
</section> </section>
<section anchor="designated-experts"> <section anchor="designated-experts">
<name>Designated Experts</name> <name>Designated Experts</name>
<t>The Designated Expert will post a request to the EMU WG mailing list <t>The designated expert will post a request to the EAP Method Update (E MU) WG mailing list
(or a successor designated by the Area Director) for comment and (or a successor designated by the Area Director) for comment and
review, including an Internet-Draft or reference to external review, including an I-D or reference to an external
specification. Before a period of 30 days has passed, the Designated specification. Before a period of 30 days has passed, the designated
Expert will either approve or deny the registration request and expert will either approve or deny the registration request and
publish a notice of the decision to the EAP Method Update (EMU) WG mailing list publish a notice of the decision to the EMU WG mailing list (or its
or its successor) as well as inform IANA. A denial notice must be
successor, as well as informing IANA. A denial notice must be justified by an explanation; in the cases where it is possible,
justified by an explanation, and 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.</t> become acceptable should be provided.</t>
</section> </section>
<section anchor="vendor-assignment"> <section anchor="vendor-assignment">
<name>Organization Self Assignment</name> <name>Organization Self Assignment</name>
<t>This registry allows organizations to request allocations from this <t>The "EAP Provisioning Identifiers" registry allows organizations to r
registry, but explicit allocations are not always required. Any NAI equest allocations from it, but explicit allocations are not always required. A
ny NAI
defined in this registry also implicitly defines a subdomain "v.". defined in this registry also implicitly defines a subdomain "v.".
Organizations can self-allocate in this space, under the "v." Organizations can self-allocate in this space under the "v."
subdomain, e.g. "local@example.com.v.tls.eap.arpa".</t> subdomain, e.g., "local@example.com.v.tls.eap.arpa".</t>
<t>The purpose of self-assigned realms is for testing, and for future <t>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.</t> these realms, but we do not wish to forbid future expansion.</t>
<t>An organization which has registered a Fully Qualified Domain Name <t>An organization that has registered a Fully Qualified Domain Name
(FQDN) within the DNS can use that name within the "v." subdomain.</t> (FQDN) within the DNS can use that name within the "v." subdomain.</t>
<t>As DNS registrations can change over time, an organization may stop <t>As DNS registrations can change over time, an organization may stop
using a domain at some point. This change is reflected in the DNS, using a domain at some point. This change is reflected in the DNS
but is unlikely to be reflected in shipped products which use a but is unlikely to be reflected in shipped products that use a
self-assigned realm. There is no solution to this problem, other than self-assigned realm. There is no solution to this problem other than
suggesting that organizations using self-assigned realms do not allow suggesting that organizations using self-assigned realms do not allow
their DNS registrations to expire.</t> their DNS registrations to expire.</t>
<t>It is therefore RECOMMENDED that organizations avoid the use of <t>Therefore, it is <bcp14>RECOMMENDED</bcp14> that organizations avoid
self-assigned realms. Organizations MAY use self-assigned realms only the use of
when no other alternative exists, and when the organization expects to self-assigned realms. Organizations <bcp14>MAY</bcp14> use self-assigned realms
maintain operation for at least the lifetime of the devices which use 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.</t> these realms.</t>
</section> </section>
</section> </section>
<section anchor="privacy-considerations"> <section anchor="privacy-considerations">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>The EAP Identity field is generally publicly visible to parties who <t>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 can observe the EAP traffic. As the names given here are in a public
specification, there is no privacy implication to exposing those names specification, there is no privacy implication to exposing those names
within EAP. The entire goal of this specification is in fact to make within EAP. In fact, the entire goal of this specification is to make
those names public, so that unknown (and private) parties can publicly those names public so that unknown (and private) parties can publicly
(and anonymously) declare what kind of network access they desire.</t> (and anonymously) declare what kind of network access they desire.</t>
<t>However, there are many additional privacy concerns around this <t>However, there are many additional privacy concerns around this
specification. Most EAP traffic is sent over RADIUS <xref target="RFC2865"/>. The specification. Most EAP traffic is sent over RADIUS <xref target="RFC2865"/>. The
RADIUS Access-Request packets typically contain large amounts of RADIUS Access-Request packets typically contain large amounts of
information such as MAC addresses, device location, etc.</t> information such as Media Access Control (MAC) addresses, device location, etc.<
<t>This specification does not change RADIUS or EAP, and as such does not /t>
change which information is publicly available, or is kept private. <t>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 Those issues are dealt with in other specifications, such as
<xref target="I-D.ietf-radext-deprecating-radius"/>.</t> <xref target="I-D.ietf-radext-deprecating-radius"/>.</t>
<t>However, this specification can increase privacy by allowing devices <t>However, this specification can increase privacy by allowing devices
to anonymously obtain network access, and then securely obtain to anonymously obtain network access and then securely obtain
credentials.</t> credentials.</t>
<t>The NAIs used here are contained in a public registry, and therefore <t>The NAIs used here are contained in a public registry; therefore, they
do not have to follow the username privacy recommendations of do not have to follow the username privacy recommendations of
<xref section="2.4" sectionFormat="comma" target="RFC7542"/>. However, there ma y be other personally <xref section="2.4" sectionFormat="comma" target="RFC7542"/>. However, there ma y be other personally
identifying information contained in EAP or AAA packets. This identifying information contained in EAP or AAA packets. This
situation is no different from normal EAP authentication, and thus situation is no different from normal EAP authentication; thus, it
has no additional positive or negative implications for privacy.</t> has no additional positive or negative implications for privacy.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This specification defines a framework which permits unknown, <t>This specification defines a framework that permits unknown,
anonymous, and unauthenticated devices to request and to obtain anonymous, and unauthenticated devices to request and to obtain
network access. As such, it is critical that network operators network access. As such, it is critical that network operators
provide limited access to those devices.</t> provide limited access to those devices.</t>
<t>Future specifications which define an NAI within this registry, should <t>Future specifications that define an NAI within this registry, should
give detailed descriptions of what kind of network access is to be give detailed descriptions of what kind of network access is to be
provided.</t> provided.</t>
<section anchor="on-path-attackers-and-impersonation"> <section anchor="on-path-attackers-and-impersonation">
<name>On-Path Attackers and Impersonation</name> <name>On-Path Attackers and Impersonation</name>
<t>In most EAP use-cases, the server identity is validated (usually <t>In most EAP use cases, the server identity is validated (usually
through a certificate), or the EAP method allows the TLS tunnel to be through a certificate) or the EAP method allows the TLS tunnel to be
cryptographically bound to the inner application data. For the cryptographically bound to the inner application data. For the
methods outlined here, the use of public credentials, and/or skipping methods outlined here, the use of public credentials and/or skipping
server validation allows "on-path" attacks to succeed where they would server validation allows "on-path" attacks to succeed where they would
normally fail</t> normally fail.</t>
<t>EAP peers and servers MUST assume that all data sent over an EAP <t>EAP peers and servers <bcp14>MUST</bcp14> assume that all data sent o
session is visible to attackers, and can be modified by them.</t> ver an EAP
<t>The methods defined here MUST only be used to bootstrap initial session is visible to attackers and can be modified by them.</t>
<t>The methods defined here <bcp14>MUST</bcp14> only be used to bootstra
p 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.</t> policies can be applied.</t>
</section> </section>
<!--[rfced] Please clarify the antecedent of the pronoun "it" in the
following:
Original:
This specification allows for unauthenticated EAP peers 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."
-->
<section anchor="provisioning-is-unauthenticated"> <section anchor="provisioning-is-unauthenticated">
<name>Provisioning is Unauthenticated</name> <name>Provisioning is Unauthenticated</name>
<t>This specification allows for unauthenticated EAP peers <t>This specification allows unauthenticated EAP peers
to obtain network access, however limited. As with any to obtain network access, however limited. As with any
unauthenticated process, it can be abused. Implementations should unauthenticated process, it can be abused. Implementations should
take care to limit the use of the provisioning network.</t> take care to limit the use of the provisioning network.</t>
<t><xref target="eap-servers"/> describes a number of methods which can be <t><xref target="eap-servers"/> describes a number of methods that can b e
used to secure the provisioning network. In summary:</t> used to secure the provisioning network. In summary:</t>
<!--[rfced] In the following, is "to" missing? Or is there another
way to rephrase?
Original:
for any one device, rate limit its access the provisioning network.
Perhaps:
for any one device, rate limit its access to the provisioning network.
-->
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>allow only traffic which is needed for the current provisioning <t>allow only traffic that is needed for the current provisioning
method. All other traffic should be blocked. Most notable, DNS has method. All other traffic should be blocked. Most notable, DNS has
been used to exfiltrate network traffic, so DNS recursive resolvers SHOULD NOT been used to exfiltrate network traffic, so DNS recursive resolvers <bcp14>SHOUL D NOT</bcp14>
be made available on the provisioning network.</t> be made available on the provisioning network.</t>
</li> </li>
<li> <li>
<t>limit the services available on the provisioning network to only <t>limit the services available on the provisioning network to only
those services which are needed for provisioning.</t> those services that are needed for provisioning.</t>
</li> </li>
<li> <li>
<t>limit the number of devices which can access the provisioning <t>limit the number of devices that can access the provisioning
network at the same time.</t> network at the same time.</t>
</li> </li>
<li> <li>
<t>for any one device, rate limit its access the provisioning networ k.</t> <t>for any one device, rate limit its access the provisioning networ k.</t>
</li> </li>
<li> <li>
<t>for a device which has accessed the provisioning network, limit t <t>for a device that has accessed the provisioning network, limit th
he e
total amount of time which it is allowed to remain on the network</t> total amount of time that it is allowed to remain on the network.</t>
</li> </li>
<li> <li>
<t>for a device which has accessed the provisioning network, limit t <t>for a device that has accessed the provisioning network, limit th
he e
total amount of data which it is allowed to transfer through the network.</t> total amount of data that it is allowed to transfer through the network.</t>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="acknowledgements">
<name>Acknowledgements</name>
<t>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.</t>
<t>The document was further improved with reviews from Ignes Robles and
Ben Kaduk.</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-radext-deprecating-radius" to="INSECURE-R ADIUS"></displayreference>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<referencegroup anchor="STD13" target="https://www.rfc-editor.org/info/s td13"> <referencegroup anchor="STD13" target="https://www.rfc-editor.org/info/s td13">
<reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rf <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
c1034"> .1034.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
<title>Domain names - concepts and facilities</title> .1035.xml"/>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetr
is"/>
<date month="November" year="1987"/>
<abstract>
<t>This RFC is the revised basic definition of The Domain Name S
ystem. It obsoletes RFC-882. This memo describes the domain style names and thei
r used for host address look up and electronic mail forwarding. It discusses the
clients and servers in the domain name system and the protocol used between the
m.</t>
</abstract>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1034"/>
<seriesInfo name="DOI" value="10.17487/RFC1034"/>
</reference>
<reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rf
c1035">
<front>
<title>Domain names - implementation and specification</title>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetr
is"/>
<date month="November" year="1987"/>
<abstract>
<t>This RFC is the revised specification of the protocol and for
mat used in the implementation of the Domain Name System. It obsoletes RFC-883.
This memo documents the details of the domain name client - server communication
.</t>
</abstract>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1035"/>
<seriesInfo name="DOI" value="10.17487/RFC1035"/>
</reference>
</referencegroup> </referencegroup>
<reference anchor="RFC8174"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 174.xml"/>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
tle> 748.xml"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<date month="May" year="2017"/> 216.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<t>RFC 2119 specifies common key words that may be used in protoco 542.xml"/>
l specifications. This document aims to reduce the ambiguity by clarifying that <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
only UPPERCASE usage of the key words have the defined special meanings.</t> 126.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</front> 140.xml"/>
<seriesInfo name="BCP" value="14"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<seriesInfo name="RFC" value="8174"/> 119.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC3748">
<front>
<title>Extensible Authentication Protocol (EAP)</title>
<author fullname="B. Aboba" initials="B." surname="Aboba"/>
<author fullname="L. Blunk" initials="L." surname="Blunk"/>
<author fullname="J. Vollbrecht" initials="J." surname="Vollbrecht"/
>
<author fullname="J. Carlson" initials="J." surname="Carlson"/>
<author fullname="H. Levkowetz" initials="H." role="editor" surname=
"Levkowetz"/>
<date month="June" year="2004"/>
<abstract>
<t>This document defines the Extensible Authentication Protocol (E
AP), an authentication framework which supports multiple authentication methods.
EAP typically runs directly over data link layers such as Point-to-Point Protoc
ol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for dup
licate elimination and retransmission, but is reliant on lower layer ordering gu
arantees. Fragmentation is not supported within EAP itself; however, individual
EAP methods may support this. This document obsoletes RFC 2284. A summary of the
changes between this document and RFC 2284 is available in Appendix A. [STANDAR
DS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3748"/>
<seriesInfo name="DOI" value="10.17487/RFC3748"/>
</reference>
<reference anchor="RFC5216">
<front>
<title>The EAP-TLS Authentication Protocol</title>
<author fullname="D. Simon" initials="D." surname="Simon"/>
<author fullname="B. Aboba" initials="B." surname="Aboba"/>
<author fullname="R. Hurst" initials="R." surname="Hurst"/>
<date month="March" year="2008"/>
<abstract>
<t>The Extensible Authentication Protocol (EAP), defined in RFC 37
48, provides support for multiple authentication methods. Transport Layer Securi
ty (TLS) provides for mutual authentication, integrity-protected ciphersuite neg
otiation, and key exchange between two endpoints. This document defines EAP-TLS,
which includes support for certificate-based mutual authentication and key deri
vation.</t>
<t>This document obsoletes RFC 2716. A summary of the changes betw
een this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5216"/>
<seriesInfo name="DOI" value="10.17487/RFC5216"/>
</reference>
<reference anchor="RFC7542">
<front>
<title>The Network Access Identifier</title>
<author fullname="A. DeKok" initials="A." surname="DeKok"/>
<date month="May" year="2015"/>
<abstract>
<t>In order to provide inter-domain authentication services, it is
necessary to have a standardized method that domains can use to identify each o
ther's users. This document defines the syntax for the Network Access Identifier
(NAI), the user identifier submitted by the client prior to accessing resources
. This document is a revised version of RFC 4282. It addresses issues with inter
national character sets and makes a number of other corrections to RFC 4282.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7542"/>
<seriesInfo name="DOI" value="10.17487/RFC7542"/>
</reference>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations are often coordinated by a central record keeper. For IETF protocols,
that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This document
defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Consideratio
ns is clear and addresses the various issues that are likely in the operation of
a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC9140">
<front>
<title>Nimble Out-of-Band Authentication for EAP (EAP-NOOB)</title>
<author fullname="T. Aura" initials="T." surname="Aura"/>
<author fullname="M. Sethi" initials="M." surname="Sethi"/>
<author fullname="A. Peltonen" initials="A." surname="Peltonen"/>
<date month="December" year="2021"/>
<abstract>
<t>The Extensible Authentication Protocol (EAP) provides support f
or multiple authentication methods. This document defines the EAP-NOOB authentic
ation method for nimble out-of-band (OOB) authentication and key derivation. The
EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT)
devices that have no preconfigured authentication credentials. The method makes
use of a user-assisted, one-directional, out-of-band (OOB) message between the p
eer device and authentication server to authenticate the in-band key exchange. T
he device must have a nonnetwork input or output interface, such as a display, m
icrophone, speaker, or blinking light, that can send or receive dynamically gene
rated messages of tens of bytes in length.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9140"/>
<seriesInfo name="DOI" value="10.17487/RFC9140"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="HOTSPOT" target="https://www.wi-fi.org/discover-wi-fi /passpoint"> <reference anchor="HOTSPOT" target="https://www.wi-fi.org/discover-wi-fi /passpoint">
<front> <front>
<title>Passpoint</title> <title>Passpoint</title>
<author initials="W.-F." surname="Alliance" fullname="Wi-Fi Alliance <author>
"> <organization>Wi-Fi Alliance</organization>
<organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="RFC2865"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 865.xml"/>
<title>Remote Authentication Dial In User Service (RADIUS)</title>
<author fullname="C. Rigney" initials="C." surname="Rigney"/> <!--[rfced] We note that RFC 7170 has been obsoleted by RFC 9930. We
<author fullname="S. Willens" initials="S." surname="Willens"/> have updated to the latter. Please let us know any
<author fullname="A. Rubens" initials="A." surname="Rubens"/> objections. -->
<author fullname="W. Simpson" initials="W." surname="Simpson"/>
<date month="June" year="2000"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<abstract> 930.xml"/>
<t>This document describes a protocol for carrying authentication, <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
authorization, and configuration information between a Network Access Server wh 952.xml"/>
ich desires to authenticate its links and a shared Authentication Server. [STAND <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
ARDS-TRACK]</t> 190.xml"/>
</abstract>
</front>
<seriesInfo name="RFC" value="2865"/>
<seriesInfo name="DOI" value="10.17487/RFC2865"/>
</reference>
<reference anchor="RFC7170">
<front>
<title>Tunnel Extensible Authentication Protocol (TEAP) Version 1</t
itle>
<author fullname="H. Zhou" initials="H." surname="Zhou"/>
<author fullname="N. Cam-Winget" initials="N." surname="Cam-Winget"/
>
<author fullname="J. Salowey" initials="J." surname="Salowey"/>
<author fullname="S. Hanna" initials="S." surname="Hanna"/>
<date month="May" year="2014"/>
<abstract>
<t>This document defines the Tunnel Extensible Authentication Prot
ocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure com
munication between a peer and a server by using the Transport Layer Security (TL
S) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV
objects are used to convey authentication-related data between the EAP peer and
the EAP server.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7170"/>
<seriesInfo name="DOI" value="10.17487/RFC7170"/>
</reference>
<reference anchor="RFC8952">
<front>
<title>Captive Portal Architecture</title>
<author fullname="K. Larose" initials="K." surname="Larose"/>
<author fullname="D. Dolson" initials="D." surname="Dolson"/>
<author fullname="H. Liu" initials="H." surname="Liu"/>
<date month="November" year="2020"/>
<abstract>
<t>This document describes a captive portal architecture. Network
provisioning protocols such as DHCP or Router Advertisements (RAs), an optional
signaling protocol, and an HTTP API are used to provide the solution.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8952"/>
<seriesInfo name="DOI" value="10.17487/RFC8952"/>
</reference>
<reference anchor="RFC9190">
<front>
<title>EAP-TLS 1.3: Using the Extensible Authentication Protocol wit
h TLS 1.3</title>
<author fullname="J. Preuß Mattsson" initials="J." surname="Preuß Ma
ttsson"/>
<author fullname="M. Sethi" initials="M." surname="Sethi"/>
<date month="February" year="2022"/>
<abstract>
<t>The Extensible Authentication Protocol (EAP), defined in RFC 37
48, provides a standard mechanism for support of multiple authentication methods
. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwa
rds compatible with existing implementations of EAP-TLS. TLS 1.3 provides signif
icantly improved security and privacy, and reduced latency when compared to earl
ier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves securit
y and privacy by always providing forward secrecy, never disclosing the peer ide
ntity, and by mandating use of revocation checking when compared to EAP-TLS with
earlier versions of TLS. This document also provides guidance on authentication
, authorization, and resumption for EAP-TLS in general (regardless of the underl
ying TLS version used). This document updates RFC 5216.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9190"/>
<seriesInfo name="DOI" value="10.17487/RFC9190"/>
</reference>
<reference anchor="ARPAREG" target="https://www.iana.org/domains/arpa"> <reference anchor="ARPAREG" target="https://www.iana.org/domains/arpa">
<front> <front>
<title>.ARPA Zone Management</title> <title>.ARPA Zone Management</title>
<author initials="" surname="IANA" fullname="IANA"> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="EAPREG" target="https://www.iana.org/assignments/eap-
numbers/eap-numbers.xhtml"> <reference anchor="EAPREG" target="https://www.iana.org/assignments/eap-
numbers">
<front> <front>
<title>Extensible Authentication Protocol (EAP) Registry</title> <title>Extensible Authentication Protocol (EAP) Registry</title>
<author initials="" surname="IANA" fullname="IANA"> <author>
<organization/> <organization>IANA</organization>
</author>
<date>n.d.</date>
</front>
</reference>
<reference anchor="CAB" target="https://cabforum.org/">
<front>
<title>CA/Browser Forum</title>
<author initials="C." surname="Forum" fullname="CA/Browser Forum">
<organization/>
</author> </author>
<date>n.d.</date>
</front>
</reference>
<reference anchor="RFC7585">
<front>
<title>Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based o
n the Network Access Identifier (NAI)</title>
<author fullname="S. Winter" initials="S." surname="Winter"/>
<author fullname="M. McCauley" initials="M." surname="McCauley"/>
<date month="October" year="2015"/>
<abstract>
<t>This document specifies a means to find authoritative RADIUS se
rvers for a given realm. It is used in conjunction with either RADIUS over Trans
port Layer Security (RADIUS/TLS) or RADIUS over Datagram Transport Layer Securit
y (RADIUS/DTLS).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7585"/>
<seriesInfo name="DOI" value="10.17487/RFC7585"/>
</reference>
<reference anchor="RFC7030">
<front>
<title>Enrollment over Secure Transport</title>
<author fullname="M. Pritikin" initials="M." role="editor" surname="
Pritikin"/>
<author fullname="P. Yee" initials="P." role="editor" surname="Yee"/
>
<author fullname="D. Harkins" initials="D." role="editor" surname="H
arkins"/>
<date month="October" year="2013"/>
<abstract>
<t>This document profiles certificate enrollment for clients using
Certificate Management over CMS (CMC) messages over a secure transport. This pr
ofile, called Enrollment over Secure Transport (EST), describes a simple, yet fu
nctional, certificate management protocol targeting Public Key Infrastructure (P
KI) clients that need to acquire client certificates and associated Certificatio
n Authority (CA) certificates. It also supports client-generated public/private
key pairs as well as key pairs generated by the CA.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7030"/>
<seriesInfo name="DOI" value="10.17487/RFC7030"/>
</reference>
<reference anchor="RFC9810">
<front>
<title>Internet X.509 Public Key Infrastructure -- Certificate Manag
ement Protocol (CMP)</title>
<author fullname="H. Brockhaus" initials="H." surname="Brockhaus"/>
<author fullname="D. von Oheimb" initials="D." surname="von Oheimb"/
>
<author fullname="M. Ounsworth" initials="M." surname="Ounsworth"/>
<author fullname="J. Gray" initials="J." surname="Gray"/>
<date month="July" year="2025"/>
<abstract>
<t>This document describes the Internet X.509 Public Key Infrastru
cture (PKI) Certificate Management Protocol (CMP). Protocol messages are defined
for X.509v3 certificate creation and management. CMP provides interactions betw
een client systems and PKI components such as a Registration Authority (RA) and
a Certification Authority (CA).</t>
<t>This document adds support for management of certificates conta
ining a Key Encapsulation Mechanism (KEM) public key and uses EnvelopedData inst
ead of EncryptedValue. This document also includes the updates specified in Sect
ion 2 and Appendix A.2 of RFC 9480.</t>
<t>This document obsoletes RFC 4210, and together with RFC 9811, i
t also obsoletes RFC 9480. Appendix F of this document updates Section 9 of RFC
5912.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="9810"/>
<seriesInfo name="DOI" value="10.17487/RFC9810"/>
</reference> </reference>
<reference anchor="RFC5931">
<front> <reference anchor="SPECIAL-USE" target="https://www.iana.org/ass
<title>Extensible Authentication Protocol (EAP) Authentication Using ignments/special-use-domain-names">
Only a Password</title>
<author fullname="D. Harkins" initials="D." surname="Harkins"/>
<author fullname="G. Zorn" initials="G." surname="Zorn"/>
<date month="August" year="2010"/>
<abstract>
<t>This memo describes an Extensible Authentication Protocol (EAP)
method, EAP-pwd, which uses a shared password for authentication. The password
may be a low-entropy one and may be drawn from some set of possible passwords, l
ike a dictionary, which is available to an attacker. The underlying key exchange
is resistant to active attack, passive attack, and dictionary attack. This docu
ment is not an Internet Standards Track specification; it is published for infor
mational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5931"/>
<seriesInfo name="DOI" value="10.17487/RFC5931"/>
</reference>
<reference anchor="RFC6761">
<front> <front>
<title>Special-Use Domain Names</title> <title>Special-Use Domain Names</title>
<author fullname="S. Cheshire" initials="S." surname="Cheshire"/> <author>
<author fullname="M. Krochmal" initials="M." surname="Krochmal"/> <organization>IANA</organization>
<date month="February" year="2013"/> </author>
<abstract>
<t>This document describes what it means to say that a Domain Name
(DNS name) is reserved for special use, when reserving such a name is appropria
te, and the procedure for doing so. It establishes an IANA registry for such dom
ain names, and seeds it with entries for some of the already established special
domain names.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="6761"/>
<seriesInfo name="DOI" value="10.17487/RFC6761"/>
</reference> </reference>
<reference anchor="I-D.ietf-radext-deprecating-radius">
<reference anchor="CAB" target="https://cabforum.org/">
<front> <front>
<title>Deprecating Insecure Practices in RADIUS</title> <title>CA/Browser Forum</title>
<author fullname="Alan DeKok" initials="A." surname="DeKok"> <author>
<organization>InkBridge Networks</organization> <organization>CA/Browser Forum</organization>
</author> </author>
<date day="27" month="August" year="2025"/>
<abstract>
<t> RADIUS crypto-agility was first mandated as future work by R
FC 6421.
The outcome of that work was the publication of RADIUS over TLS (RFC
6614) and RADIUS over DTLS (RFC 7360) as experimental documents.
Those transport protocols have been in wide-spread use for many years
in a wide range of networks. They have proven their utility as
replacements for the previous UDP (RFC 2865) and TCP (RFC 6613)
transports. With that knowledge, the continued use of insecure
transports for RADIUS has serious and negative implications for
privacy and security.
The publication of the "BlastRADIUS" exploit has also shown that
RADIUS security needs to be updated. It is no longer acceptable for
RADIUS to rely on MD5 for security. It is no longer acceptable to
send device or location information in clear text across the wider
Internet. This document therefore deprecates many insecure practices
in RADIUS, and mandates support for secure TLS-based transport
layers. We also discuss related security issues with RADIUS, and
give recommendations for practices which increase both security and
privacy.
</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-radext-deprecating -radius-07"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
585.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
030.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
810.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
931.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
761.xml"/>
<!-- [I-D.ietf-radext-deprecating-radius]
draft-ietf-radext-deprecating-radius-08
IESG State: I-D Exists as of 12/12/25
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-radext-deprecating-radius.xml"/>
</references> </references>
</references> </references>
</back>
<!-- ##markdown-source:
H4sIAC/RuWgAA7V96XLbSJrg/3wKLOuPtEHSdx3ejepiWXJZUbastuSpnt3Z
2ACJJIUWCHBwiGa7/S77LPNk8515AKDs3u11RHeJJJDHl9995Ww2M23eFvZl
cnNrE5vu5mm9S+dJVm3TvEzSMkvOF1fJrq7u8yavyrzcmHS5rO39S/e0yapV
mW5hjKxO1+0st+16ZrfdDB6Y4QOzJ49Nt8vS1jYvkxdPn3w/TX568vwx/v9P
j41pWpjmf6dFVcIQbd1Zk+9q+qtpnz5+/NPjpyatbfoyuShbW5e2NfvNy+T8
3cfkj6q+gxUlv9VVtzN3e//I7AyXYlZp+zJp2sw03XKbN7iDm8MOprk4v3lt
zC5/mcC/75JVWiZdY5O0rtNDcpKvk7QokoNtTpOqTm7T5ja5tbU1SdJWq5f4
A/zZVHVb23XzkobI7DrtiraBJ/T3w5Z/xo8m7drbqn5pzCzJS/hyMU/O7O/V
HTzIwFsUsAj9qqo3uJm7X+s829jk0rZ72CuOauFgipewvrScZ/auuvslL++W
9Ng8r4wpq3qbtvm9fQkPX9+cPXmGf3x4/erHJz88lz+f/fD8R/kTj0P+/OHF
86fu2af6LZ4UrDov1+HAb97fXF+9v8E/4Z+g0OQqbZpdlZfthL/XPSf8j/f5
Rz57ncNuizwtV5Z/47Hdgzd/uXmZ3Lbtrnn56NF+v5/v89k6nwNQHmV5s6ru
bT2jrx7tdEZe7NMfv3+hu3nyw2PdzU8vnrrd/ETfLj5cLT6c/9Zb/xy/Tv4H
IGLyLi3Tjd3ah/dysbhcfNsOYLMpb4Aoq3lElJMgdQ3Xcf6ptWWTLwubLGBa
WEQOmAzIm1zVFWBgVSQn8OJp8sFu8qatD//kNQJQ802Jm28eIRGX3XZp6+jv
+afbdlvAUK8Wv/ZW/2rx6Ne62je2Tl5Xdbd9aHH9Z7++0FW6XOOTtFB44uL8
/PzHx0/nT550gKb3tuwIQTfIEohLwAcmGWBJ7S/InPBVfCRvb7vly2RdW1un
Wd7xBokBwm9AqbNZki4BvukKPt3c5g3wxVWHcEFyz0sL1D7GNmGBxE6qsjgA
tSv5JovVyjZNcpHhia5zAGNycrm4AC6TNkma7IH34KvffPw7i0O0lcHjSgtk
PcitAZr39MNt2uICD8k+Bw4Gv1bLFtdX5Nu8tdkU+bvpytRPgl+WstqUVjtP
WALQVDLP/jZf3SbAerOkWstzCUCntv/e5bXNkvs8TVa2psl28AUBK0vyYOM8
BkIJQXgUQgSgU8EInA2IOEFOBetaJG2KQKrWJhwZhdbWpiiraFUy+1SmzMtV
0WVwdPBGncN/EeQ4KnK6ef+cRW4pq6TBhY8gQHnsBMVHDMZIZMJyAPczWPLN
bQU7bnZ2BYvlQwWodpuNbfAlOrGmg1Wm8g4Kn2RXNYQO02TZyYlmeZaUleJh
clvtk7xN9lVXZMnSwvpLS9OFe0mLpgo3hBvmTcAZ4aqTCVF4VS0JnyeEIHCq
uyJdWRofSCaZ/EJPKNZPmFC2eZYV1pjvUAbXVdatcHPGXJTJtmpaPOlmSqj0
+bOIoC9fFGM8rgbIdpveWwMrmzlQAoRWiE0AZNgL7O8PWE8FIAm+ndIomb3P
Yckg1wFIRtA+RmwkzKrOAMUABACycBbaZzgVYwXRDVMi/EhgTJNlVbXII3Y7
PGkYBQ5qq3gUnXSSZhnstdHtjr8JLK31w5t1DYySlo14GhDTZG+LYnZXVvty
EmNbBA0kcZA3oGPBF61OHY8KYAF0W90CzTRb2Kx5VeTI/EkvItWJzqax4fzH
pkRwpsKDQhibmPkM2cyCEaCBlYEs2QK2KyPDZeBGYTiTZveoNziEgUWFk4Om
KOcJCJcxB2bA+dVODaJ1el8BDW1qBAzsoCvhaIAhrIZrwwEZJZmDRBCJsMTc
RLiXWMAjWzsuh7iNUC5tAdTU2GI9XBuIAkPod+NoBVWZL1+mqIrqKAJenGMD
KlmI827NJnWwXqU71NyAkQBPLoTDNIzmNAWqSF++wCG8Z9i60fLGBIQxRSag
ynJLvOwIcQbSZt0VhemdNkPqW7CJ1PJkY0sLZyMSpD2IQJibUJbCXC0THbIr
xAR5DZT5A7Cata1ROCF+NqBkLa7MVThrMNQEBOzVxSks8zpXgLipYYZg4YhK
Mar1JUG8deJPNQIWTqcFjQlwtYSxWlwXs4sDWlkhbEAfgxEy4nj0ctPt8Cjh
t+WBFteVQGQFvkjowbJjatohDyJAZyL2dORZgSjjKJEncdOi+eVkO/NX/S2Q
r0J2joTTJgIbwPK775Jf09UdqmYlA+4DrSlFuXGhh2dJcIC0trrWZOnfqkpW
uT6B3ou7XXfliseAOZiwYXOrOoel7G8PJLRgJaXFraX1IRDaIxKaoGIAgrTa
70C/vs/tHtWOc53wdTihMa9RX1tczW7eXoN0rpSeUFcA8XbNm0lAPZ0/oR3T
r6g9wK+yPYMnMUEGM0AdPpEJHMmbam+B4qdCdSrTFfqgCxhVH1NiVoROohYi
qwRAiIZmeSPMBPTIgRwR5Zpuu6MV54FIpuFWFbCtVStMo6nghO/TorMsQJgt
CTXCQZCishfp3DU4H2iEJFVIMWR8ZBUl4mjAbxAAjOENY1Vmwajf4i7jJcX7
6cHOKLkh1Nv0jjETZG1d7WqUhAloXDviU8QlxT7J/0YoyQyqphdsSko2IndZ
Of0EubGuebsryFQUfY6khBEaDeEMEk3ZCXOAsnLUg6dHcqZG1garPqBeS9RE
6/T0l8/tfNo/XqIdr4kDDfDDKP4JoLJJZb+xFU5apudoAzwUDHd8RU8UzK2s
qmfKYQLeg+S/S2tS2d9U7fUOdNWn88f1U6AAcR6AvDEBWg+hvQbSA920qA6M
6jDUkKHBXnB1l+/f/6rE9RyJC4+84efhyAkuKYESWEaNs7GipXYckq5J9RRC
yEZsogdaVqn1NWM/oXTf9FiLc50AWSFJgJjSFRP+I3EGYsEAUpQWgK6EJZJ4
YL4NBAsakUXBYLJmsG50a4AmiAyVH3HLwPWSXYlo35F68i026A0ZoYGK0hMu
4QLQIhxBLEAq09KMCgpnrURjOYWyT+UxE68ybyPBXkH44wyJO5fY3CB2DRjc
mHBMMOeBYCtBEeEC8D84Y9YEdcYkDVnZ1Oi8xB22Hdg8wJjgPKLBRe2DcYi0
eVOIFWTpOLEWmzkLxF1kzkU7Jc4wIrq8Qd2w6rjHudGGIoWHLQ+mB2/GiJi7
ST9VZbVFjpNEKhE6SxvHClG1BkuhWdkyrfMKGR3pCZHqBocc2p9AxXndIIab
kacVLYUsVLsVNuNUVMVTExC4jA7qQlWSGsLD4+t5wxrZgGJ6WmhyYuebuZsl
7anJp4qSPXozns0SZ9W56q5MLq5AWWl6+qxBhyUgJyxvVaGs+OQIrlFFQxUh
wvboDOhlFK7mgkR4tW55UtCrSTpWRPU9lqNkDi8CRYB1H9ogj5LFYgGWFMhU
eN025EkgVAFggvFe8KT4uOyZmWXOT6YF0oJRr0ToB+lbGl/BEBNh9t4y42Pu
n8rQKhEH7IS2hvIN14RfkFJycRVyM8BtUh2qotocSFIkR3R+Y352usiRR4bK
LkoUNBnhXTAKG9sqZ/2aP4uZ5ovnTx0ig72B46cljAWPqLOKpFa3FMcijD5x
fhd5cVLbtNhOCOLIlUBr+JnXsLgIVwyvu1mngWb6FE3LYDbEUxhBrWE8zHhv
shZ04CK+3OPWyI3FYpmmggE+f6boA0r5n+HjB5tmaKSpEHd8vrklpxUcYqDf
0Z6CLZFE+9ltKV+DLYcvr+sKdKVwSYip5GnJ6VVhtMD/0YsLxwwnBVtZWpYX
gJzOGXpsXppVyQTeFwciTNvWaV7gQJP5BJDNBcQElY4NxgDp+RkbcSajqusP
OZHD3TOjwbkIRrhTGCPgm0i5cKbkkC15Fregua4oPDo3B679mxfkfNz/4Jrw
49nlteBsCDjCuixjhQfeh5cakIK2XB2YL8NrPY8p7If8B3fo2kYLNZm8+3h9
M5nyf5PL9/T3h/M/f7z4cH6Gf1+/Wbx96/4w8sT1m/cf3575v/ybr96/e3d+
ecYvw7dJ9JWZvFv8q7hHJ++vbi7eXy7eTpwDwntcnTcqx8AkiHiy6hqjNiqR
5a+vrv7j/zx5DhTzXzCG9eTJT6BK8QcM2sEHBDXPRl4G/oh+YMMaM46CQgC4
L0j2gnVBIKx9SXHLufnvfyqQP8++/9PPBrnie+DvaNoas1D9klkAGgJkleB3
XrEPPTIuWBq4QXraZsAyH4h+xL79AUs0Qu0oM8kURDQC/UMISjy9Xbv+cQbL
qRH9xNrTr4l4DCMsjIm2eoPGWr5CPw5ChoQOeYaEUzTOcTHRQSckZJTNwsKL
TB1YTOG4RrTKS3fWYLWAXokYUK15TV1JasLywAqcKnqmqjdpKUanrr5rnAuT
hODywHp98KiY7LwAg1JT3yF1Srk5SeuurdD6YC8YnNOnnP1G0TpiJX9KSr+z
hnlhcH5Vx87SE9AfTmmsQ+BKJrx+SNg8c9KOAUfWU2/xhhfv1BIgma4uRUdg
Y+Dz5z/R0D++ANLIDnBGgKEaGD6Mu951vCmGStjkhKGWeZbUVUd7Auzapas7
y5Mg8olH0Qf4eNkkYYBBpewOLSwoTg2b+TpWtzOwIcCDHEyYLu2f3egK4Qv0
lB4I3+ErPHnWS+Hsyc1P6kvP2TAFrUd8O2vgqbMmXVv24FHkDZCy1XgG+4UM
xgKJZ1fixe2vZOq9awPPBtgURk4EF/MapuxqITsyOPDIyHaCaWyyzZulRcWS
vX83A1h+S1hVkaURqU2EhEcU8RxvWVNkEOg8L4AxirSiKFoNTK3qGgDx0ore
Tr63Mf8BcdBeOGwQULNoJGfosQL+BXJrZXctw4JyWtI6y/8mm9mh+gEsFRGl
JlcmwbedGpRF5y+Z5dA0umZifaSOF97Re7FAp8GiKCpBG3ESDeQzyXhn76ab
2tJBssakIxkDG56dn13cvP/wkjfXwqZUR+dYITldd92yUEwV1CZ7FrduZDiC
MnnY7pEFtP7Q+QSJdTLjJOpSZkFbG9CDGCwmkAtJxIQjRw260QHRcjhOxhLx
DNrsv6E6iq6ofNUBRrDU8Co1ec7Hw/hAeNWeWY7TOI0b17mMmXVlTDIdUJfN
1Dh1swgjYZzn1aPaQ3kWEi9X4+yY8aG5HoClnDTi9HYTa/n/83+dfFfLw2DD
xgsh/Whd4c4YEAcg7k//V0bC/6OJEBoIRiIOLs7dOsdBZPyMHpOoboGBa8Ql
IipBBB3G1cvFN3i4TJxkwzklqGPy6OQcmSQK6thJz2epv5H4ITs1AP0/BiRh
9CaywZPQBt+ikztNJiBEZ201g/9M4DsOLi9BB0Oeh/MGyzc0OTkyvw5od0y5
8wSMTJ8BvwGVf2xiPJlgct551lk10hBig99xGlBfViyz4Klj+Cl65NSZbA5d
e6f/AJE1/sSIUFjNZe5F5o0bU+WLLatuQ7k1qTtYkHd1St7GVNILiMmQTJBV
9UGRh8INAL0Q+5WCtXIuHNzeoT+jbf12aHVKnPyr+OUpFcZciyhqkjNAzqLa
kRiIFJLk5PrsfXPKi1/mGNki5mqL9Yx5lIGDtYXdkDioyZcKWDLM58kqOjBA
5zWIC0kYIX0gTNHBDZYHgWt0OnlwAuydm7RF43NNTklnNKrEgyhXjYEQmDX+
ZHIPZqW8fj+PBwAy/ReGDujeCe6bsxxoryxWI38kjSUwZmOXPjRO8h0SUM3E
urCfUtSYpugIQy2uPLBpDE+IUSFPzOHnuUp6syIPSLwEiSsHXono3d625uba
WuL8EpLxKXxkYDHDRh25oyxY54Zpq12+elhlFsoO3c7q4M/vYalofRkGirqk
EGb+OHDkbg3jUviP3PnksKS3ydGAQZxPgLs56ZrFeGiWKBIlrUbM3CGZMKyn
uE/cg1IB5HAoO7kJzxazgJlfTDQvcCLvSxKBzklkmSRnzvFE7hGRPH3pb0Ch
Ub+IcDH0yqCrgtKVSY5g/FAVyalmZJiJ3XZzXQsccnDAqkupWRqqU/F3zPOc
Bdr3qz+kRs9jNA4Das4h5CaboGoMWvF7om8/ARzV4l+TSnJk/PMpEjcg7xZX
FusazuZ3D6OrMy2r8rAFlZ2cRD0vDCFSL5OOoM5ZDyoNgOchAIhLs+DyHHR5
GHHEEp/vTb0H5lUcGGR5ydprW2XpQSwf6zIsKavIIP/rGhdHHjmff0T1M04D
GRNpPXVvBEfoOJbW2O0OQ/N4wEWDOYMFyv11/gmXgbH8OdiNeWFDoPgTA36J
YFO0dlOof1OSXoUtrA5Th/1N4uJH6i7K1aLoe/aS5GMwhsRYartG9oW8CL0F
Ehs94nJqOAukHYJBrBqeGI4T3wblhUnrPaBFyimLb8COgCG9j460UfZS4dDk
1pSA9HE3gfFhkZb9+xzhqPY+Q+W22htO6ICfWb6LmyjIg3RFGJLtq0ZPFGIK
gswcUSJ8wjdQ1vqsBX63cTkhiLckPTVdV7J6Y+PaMTSAIG0EqzU24lYoEZmr
Va6ZAibIdrWaietCzvR2mXlzTX7A1U0RAiYwCzHsC6YbZWtEQX+JzMUCi7wT
7WEnri4BPkV5o6l77BClo/Atpi93DAPuyNSMoRo9JhfwVUmBeQelxCVKyjE+
KH58JeVMiXh0kTQfwZv0DtRvaUZSjcXZXoNBtqvYsxC8KhY/ggtpgZbkdPk0
wA2xd1EBKVAbEe2aZNeIRCYCNxK3imz50dwq2hWSsDxiWcGp+/FtCiuMTui1
ZF6c1SXoBtT5z7HMlNTQfNPV4mBDF/w6da7uAl19CmbiXIHfmjkGME0dA/bG
pk1x8A5Ax2WSExRGGH8kZVdTTk7RMQzk3ZgjEAxPmrO2KPmJttco1orVQUet
uQtj6eV4psi+A9ZBNgkukBgHOgPr/lYbty/iqs735ymZPe0HD15YxuoOD4r2
ygyMBuTxGCdRYYTF4/GWB550f1sZWgMytRDa8QaZybA/UTJoNxY9wX+lQ4/C
2ZxBYZyuqllXcU6tZNLwInBYFAOY1I4SFKW2iePWLvGDc7Qau+pqNIqqUDI1
nXWZAziy2aZlR5yH9ujZpUYUeoBnGuTAzQbXjwndU0wjKJWCheCZ5agLHAyG
0u7DtBJJSHcRGiaSIDNXeLHHsAzU5cbkbeOSiCS/z3n7azsLE1eaUKO1++IQ
pgX30lVUAxG9AxZ8XxX3gYkn1MEpM/Alpen21X6/3ZhConiG2YDMwqd7mR1+
sceWGWa1pAlXNSGrI7cKzCn2dD9zAZ3slCZNCUGS1lKGyTwOFZ3z/BhHDEtr
jFdziMyw6OhubBEqqojFkR8bq1gynwlRg+afBqn0wjs14wi/CvItafVA/ja/
Z4QlbnqZ3gGASH3g5ZAI5hRCGCXvKV8paNOgW+LZX6xjvQTh1UxF8y7yO0ve
d6bffioQ+bXu4QWMesFYHyxIKs6FjvAC92czLq369y4HOIH5hMcuYRQcR6aC
XXPqlwlOSFWPXiDHLxCTeQj7FPkocMJUtQTxeBdTlJiBNS433hTwDjK8gWWD
HMVyR/QPHiizcZuXXWslQVWG0NSCv6J9UtMv9hOIdEZayoOu1muD22ybI2cQ
5Kw7BhanNXrGbQmf++n3KM47a6iOA/CwbNhu51hPaE8yPIm96pgMR+/UMwGu
BfzZJQ2MSkUvwBguxta1zquJTaSAglWG5KpOxloQxmN6hIueEkTr4XVFFW7I
svggU6qsKEeHSNd0PIFbA7CGVkRKxr3Pyo2IbZtvbltDlOuYg5gXo3BADxbg
B8UYmxadq2JxGjBWbtNdEyMYuuXL9pa8a6yGaEr4MZUMQIHHKulzpXJ3EwoT
cel5ghgU7nBmWGiak45KI4oeUseMuF9fNU18rWIO1maGxgQSYn1ANNyMVG8p
h696NThiGbicX9JpEYEql1dMPAMNBAkZSxWHVmeR/zVQi7cARM9tB9tAsqtq
LC0IoQZAj6phcE1AyjlKG0IeUhbR5VVxYkMOH0/kwMvkL/MXj38yQXopzwUH
saC3MzKJbHs6x6xA4R5ehAgziNNVUWmItYQ1ow4ouV1NXi0M4fAqyRJHm7Lt
SjoLzlsIq/FExyAwUwaryzoVgc9RDs4uQYVjx3bg2scgJxjxnujRTlG1cSV5
opCo4Ir5ai8r0e3c9LFwsGKVn1rxh94EFrMa9MSwsKMGWT5GNnGtQ+RXv2vs
xyCnq0m9Fz90vZax61Wt9Wupdvv8HYadpfbti8PFRgTcEszEsvGqofCWUIYD
HHM8Y8qM/8ABy0damwEQaJp0Y0kxD7lTxJpBsYmNa1ID0DGoDg1XD0WRAvi8
RuZPXkINmbArO+Pwh89GIy2hqabxMLkq/vD7FaOV+A0o+YWlCz+MVbuY5Fuy
bD8SQQbQXqyHIAoMDPWmbdMCvSdS34Y7NVj0enAOjjjXgVyIvozVx6Gez9mN
GIcCyF9IXMSWmT+32FvEaev4ECXFoIsJmR7QeRqn80Teyyge5kJgc0MeWczA
mDrrAV6X0+vV1BzVMY0zt33MO/B4DMAbpOysqk2Z/805vsYHQGAb1i4HwAYF
lLgixsb+ZusqOXl8qukX/LRmIEj2BYdJdJYjzoO+gnnjDUiC+mAxo+s4jgDm
xfzZ/AnGanPv1MLFYP5ao3uL8vXzyGwlAAWqKqlWeQ+qmU+FAUUj10KRnjIV
e+G4hCst2fprNaBTW5K1RZIyAsuaWuPQQ2VmEGGBg3dVonL0yA13bTNk1KrJ
sN1QEnBzMZvNGDx6Ti3MZgu8i6E9HNSOqRRqOesJPmBKmRyT08FalJnbFCPJ
1lRdW0QZD1yQjkjdy3kScwxtKlZmQk8oxmy6klrVaEmQfAQp0d4etKJWavq1
bK3XcUGZTt8r0a88cHGiQaK9RE/6lUHOYyNx4QeKnOeDjUtiNh7+HhU4oIPY
T7o8YBkop1RaQ4YReVt0kVzYQ650ZGNUU4A5wJh0Si6VcalORQ7EmGwtPTSI
X37asfsHTBLUupE9kXbna7FUTMgT5C+MzLW0wPZA1MUGfdy6ZJ5EnYrJZJlm
EzdI4IfAJBcupC+cT8iIXSR1OtTrYFThcEcQV0CxgtEcUXOJfzc2tvrTaCG7
qhXzkFSOJVrWwGVBpoFlUnVYFdiC7tt3syJI++iiqZiGoqwSoIIj7rbOXqOQ
ATvQaKpsZC464P7YoqMSn3WOBDAUa01j6yv4wAgFNsf9WWOqqEdbOJm6OBhS
9xlFxJxnHROm5Ooh4nGYDBR+hcJXFjePnfaoqjdk7RF3SUWdE9+By4xDNQx9
hDJza1C4s34plTuEfsozsfcDerVU43Q6suq63w7UdIt5urgZojuCniFDXirg
l4fkKGgjf4QfU2ufkOHTiz5U4iQqq+pUnsyjjxyT0WMSn19x8HqDFv9k1b4s
qjRLirTe6HYa3Q8bwJJ/M3jdd2xI5XXv2tO1o4tEdG113Xj31jHH1sIlsxLA
0CEkBoOwGGcI5oUEWcl7AFSfluQgmCc9DmsGUG4rzH7wK2aBMzijJPDvGUTH
nr9a0j63mm7xYXF28fHa9wXSZCVKw9AeQmpvadU2rSp0kY2b8rwUg/ZNbcNC
F8VRXj2fi+/Cg8QgHBETIWx5MBHqSBldhSpD2riqapoeDxukQZGqMktvKrcY
EeFBhmDUL8BLKlivAOl1jjJidpEZOPw6B60c7HLSELC5mNf1X8yfgKZ36uvH
e+xL3C6GRP4YlTVqEyIQlxX6hDiYH1h/p2xMgOnUcA4JluxhkFAStXHdbsGa
SUi5RCiTD9qPgSKfKBxc2ppUSl3j/sOCmzTPxLSsNB4OCElPZPJZPN5bbJBG
XnEpaZT9j8Gf1BBMv6a6Xut6dQwlEHI9gwkHXUlWnAaZR2pyFdURO7RG+ADb
4FinN15CZCW3gg6u6fXloaXkQtEdmKH36qf5PE6aU0kWoEdfxWAZ33agfQXK
bmk3FfbjyaUmPJ5txJ+FFeIcGS3VnEPpi7kOB2cxYba/hs3Z4YhVyGpLkpIT
rMHZVRKGClxeXeOtZA4GBZYzT0b+oCjph92ldLCwYFyPxsRBkahq6wOUfn3p
wUXstqCW5ADAUe0p6JoinS441x9PVGH5gCkb+nbUacQmn9cqXWuJMeVNdR5X
EEVBQ59VzhaicGzhYeHROWeyGAA+0CDbN3Q61XhbEpT9Pd3NEYAKTeH5vnEY
koRDs34QRfbF2Bzj8bAC+TpOsvrc83V94ayI4wxjwOhEi3VyDvM5Uwx4AzX0
MrokrfR4xxZxoF16ggLp/q1jENuIrFAJOGjnGYWmr4RT/WXpsrF6VA+oZjxK
wgBdy1FhNpJJURo/49fiqVeJhyWxArKgbGmvbc04L5P9XtxBDje/xWxfUMIP
7GYbydWWHjHj4QCGEnGVgEdNxW/gquGZc/nSXS6GXqZ1nXOzL0qyalzSdt8x
x811SrtPqV/FK8/wXGLKMSeOp9hK2qQNPe1ZZURJyGvxgcXeTNEI2CdAIESF
glOKXW5MOKwOlY/GOnpY69Bn0+UZ9VeBKW8lO/xItzIutVF5HzgPA+Rk2S7S
pO/YljIU9phQ7xVDmTvUELagYdJekZ+PkksAoDiE4tLE8fLxMM9xnqlAYHwT
n+LA1e70TbC2UbUaxPK5nCuEr+RLjxG0LTNqB9s41e68xAIqznlHkXNNjgdz
g+YQyZ2T8+ubU60pfPxMO61pJ2EOxSRXnK34uz3AL+s6BR2sW7U40qsgSOO7
xgZtUl69u9Lxf/rxiW9dcWThKzFfjberKIVN4p9jHhMtDe4nPJgT7hXEKHAa
hE1I8cOQYb26zbFGG50xmKqnBCRaOB+U6TVhdCZC1YycF8mUywpzRmBJi8Ui
+QAPS12BMeN1oS4nsnGEgl5zSUmLEVdrsNQ3WdPwhUvbT3lWLk9lnZBKIlH1
UI+0ZjNTJl1YOdKrOrwlXyvwPqnw1dwFx1fNt8wumT57NNkOnmx6c6mjVwfs
DWZ4MJIAeFRUDO1bIZASi9TyGuum4s1oCY/Pk6I0rzAX/uzyWmtJuZDTcqoE
Kh1VcZ+K5DBfKb7FgBg6UKZHd0lZmm50dSGhwAmsm6qeql0WfcthH3E2mAbQ
oVkfnPNfbF5yFYyWCeGalwfJtKQULdO6+ooYGHNqSacRvGm8jMYXu5Iug3JE
sk6DfEFsssJogEdq1SakClIpSWdBIz+TM0U7IYQPTrnOhOb0fhOFHpZjBqlG
Y2GwoNMpt71sdl1NDjtsrlBU1V23Ay215yfwAcH41EV4amOWNRmglDgiMVMp
V/IWOxkmcGDcAcKpZwV6SjhDvJdC7Yr7nA0FXAjXidHEHT7NR/Qd82kNX0iz
IKkia0htHjDNsDtB42UQGxQk4bVbYF5g5L8xuZ+DrWNmuJYkFnI5prb7lGEa
GEUSszLS1dBpwo04ynSIvJQKHdtighmosNU2zP91/d9A50rrXqtNFXWuYaNr
u2rIwFhhPKQfliSZgvHhd9ev3iyu7p8mJ1dU7ijp5rOrP87k2F/89OwJNveS
817Vh11bbep0B+fremtpAyYalwwj2xgsWyfvjy5blzhoMjljf4/uVlOwOcHX
dZv0BTcuwyd98ISVi4CcxiEx70q167Br0UDJ12VKYVToUOOWbzuOY8EgN2+v
ZfHhcTn1A77jlmrY7cwpHW/Tg+oi6Ic6oQZ7MNIp1S6g7sA67re0YaNjcwBF
YIwtqddPreT2aMaF39k9XnKCZThRkOzdb8yaCWjjYzlGbDivS8bnqXR29umi
DODvA/gf0Trj8gTRe6nJ3PiBzA02gothEO/T98RzwdegygFZwIbiPVIBss4F
Egi8HR9Yrp6ofos28sMrpbgwhDS+M9fqy6a48WiDtLwc9tYCoRF2+TLapJHt
A5/art1AsT9ZylksQ2NA00tQQS/IQuf8RXaNhTlmSENhYpL0zaSkjJNXi+bU
UAFBJApZJ3yTb26Tt1iEmnwIpDVw6X7/smE9hi+KDsS0728USgtH1ZL1GPXf
80FrZc39POoUu0XsdtZ1bw7y+Aoi2xPtGOcwLfSDnZL5wElePZ+wUyap6zTs
BW8aCWjK9J3rZLG8ubm5uj51Vuk4v/EMs++PIJhQJ0JD6QIIhbCFtD/KRtsI
NXnbydveKdqrEwzYzZihPtJWQQ/J9/jo07HAnXtFukIKZnNaIUmAJ5BMYwzH
zM3mLt8lsks1bf1ew3w6BidNUXFmapDOEKI3UKC4L6c+pcPnBJD+yBUz7rCb
xKUEAJxcf22viGJrYMQFarX2QGYYhax9PTb1udMjjLcWH2Nti/ST2DejejFf
wuNDGc+oxxTS2qAhvxmHifQf0OWoejFAhxVg6tSwtRQ4wDCYjhoO/tx8ZW/h
sXGaFIfrK864VQFPJMBII4ZsTPp0UnE+1TCubHxHWteqVyOyGuBtQh2f0HFv
lwlwPoDtq8WvX74Y1wBHpGavJyIZ+KRGoArfu35j1E8rTgHfdR1n8/ZmIOVD
zc93JFARMGCFURb0a26MG+QqmqhMnEFGmelNR2EbzS2ODI6T5jR2uUaO8vE6
CNKyKFyuVrD3GUu/Xu7XZcIoTeXNacYwEMK3pXa6En8nyx4Rjsf6DUmS3oSP
6Jeotl67rIgvIirFxBM50ixZvTxdjdlf2sMwNj7cIY3Vd/qz6V/lYnxn0zSZ
xOg1AV5/KOzQKcMg9tP7StCIkcQttqU81M1nHuxTHmXGxTyGOqADl0E9L+iB
DkC6dI0fHxhaQ4jOo9gX2yPaW3TLQTrCKOfmI/mvUKJeXf+uD/p7NRL8lruc
52HGArp9goQ4MjLc7Svka5eFanpctNZ5kNIrNTik5WCLpgHXSlq1P2zTShJu
2aDf0R2Uu6mhlzzWZzu4uyOtbL8xGC1I5H3xaEZsqd+Td7D6HsbR/M3Ua3NB
kS5HjynZvys5KUzuVIjxgArDXebFSBtpiXdF+hZDqne5jG80TwvXpn1uQF/A
hkhFV0v9ZThSkZd3ptfcRurTpFw7WCGsTFoN87rI03vKYrSpjGwbI0DKgckN
0ChW904yctqKK31NtyMAgcbXedwM38YX0uweyaBxN0m4dIWBA0Yad8sVW9IB
z7FU6sp8zEY70h4fq+bzLV3c1LWzag3aLGbvxfQsfdnYMsZZTkV94E7tQSI4
daH4Je7Uxo05e/cUUU/MA/V1eCCc4XuiS7KnHQ60Zg8rXa2z1oiTK0Ald8uU
3xxZG3utsANVP39gEWT+0APqcgrv34h6kqMH2PXL0ZudwiKKoAHBoJ0TxlVK
cojIAKjZUEBNJjGjoHWPS2174++PEjuPvb2ynH73cF2llHVMeqPiweDWhTaw
kzVFWjTIveYkHiaT1LfBcyEBkdXU7UbKmsNuPv1NqLke5wWhAo39woPGVGqI
hBlRfv5GX9E72Diyh4mU2zSLGgohyCcP9aCKgIGB0jOBL8WJwsPwsIrBxDDm
DfdOjw8Nq1moEZk2Mv14vfjt3Hcn0cZ/VD8EKPSJ/RXYGtClYJND7uz8Ciho
cXN+JgN9OH99/uH88tX4YGmWURoDhSz4ToObNxfXs7P3rz4CEd64Da+5qjfG
2zOOYXzDpscvcvSn/vmzXACJdg+m3+BbDBEOxsFDL405e/9ucXGJzZN9a2eC
FH71ut+CJGxi/3W3nWubik0YFWjUpzkEyLdsltzpaTH7CJTBIEou0ace7Nef
N+zqcvHuPNzTVxbwHZ2IHzf5YJGx83b6LOwmuMIH6KrZs/KKNXecnxD6dNx1
gcuDt0XZRkW38/c/fP+EhNgCSx9v0XlUoPNIc6KRkIIeekH7FPhG25kErgzX
HfTm1g5f5IhUg+J8ye0KGtee4aBFkEG3ZUqQaLWlk3NTBObJOV0j9GROHW0A
8NTYJshftJ6rBfUyjfbMSSWOQ91jtRXY1gf8sF8D5gjzjOF+Yg0mHFOSpgid
pPsN94XgVhzIDZ7OkwU6tzVRolq3mP3/0oTmCPlA5Y443FG4G8lKwSLxRl7+
+g4J0LXUrUebHDRdDUMoeImHFnMbb0NJXsrXZpVWrfowiRZnkfWaZtCy5Nxd
I5H5ACj9CNrIQkb6jPZW5JcCaDcIsWI2qg/GcXc36rX6bO7osyo6Or0FdRWC
Id/mS8xMtoCGf9R56xrxI1jcQ4U+9A9gKaqN4+dmzPN58irlxo0YZpSc62gF
q+B3B8d/yuQv5trDuuV6j2NLSAdP/XMX8j32jXNzS5+pChdxQyNEnIiiyRho
xpQdzopDr6BflaTZcUHHDbImTcKKIuocIOXysQeYVRRBmP/bv3HYMYQBZmhK
9qfGiQfRaYxaICEMM81TuvLEOcuOYTQOKF0V096FFR7TpdWaeJ3pGtXeOQWK
BrtsI5UvjLlj3wiLbTOcB6tPlNMICr7DA3a+RmfRX1g3SKiwHCHHtZBUsi7V
y7xrYYVDLEub3pcOrDUJWKv9a8lEztOylZaGsiYRSb5owmcyCzdRDCGLj42n
1os+gjl21Ekozf+cgx2uLZe/PqisAkwczS/4YU47kjZ1wEAeyZ8povnRnxR1
Mfs/CXN6ND+jB47wlg+1QI93cvX9kl17vC/H1CnUS2MVMDKM1Fb5x+/l5l6P
lL/rrtQedjola0UDmBPqhNnK3YMTpojgtgg28J88De8XfD4Hdpf81mGbQvJn
cicnHKfh+yql0l28Ohv35Kno7WFPu5ZSYoK1xeYCXvONeuJD0Dfas9CBZ2Uz
oIaT5pRe5S3Wlu+g+KAGwYj6qaA0fP0L3lTCd5kcv1YibizpiqLxjpOw97Eb
KczLJ4oLerjRuZ8R/OliRO09Hvgbj/WDlmtvdGs0nfvoGFnslN17/ie20AWX
8if/gm5ItqYDNOVoyoZy81sKq/PT5LQMODU9h9em/J383P1/fxfAzKgZ8d+D
Zf4d3pgN/yXRt+EneiN2mOgczrVCn8LeosjZo3OnUUac8TIK+vuiUX46Ngqy
iR5dnFFlI7vqhUQ+BxTxZQBjNHsZxJuvjrS/rRStx7wTAY+PTHxsI8nz5kSH
Se4qiOjAyJUjTSN9Q8O4ibTvJhfHHNRKjSMuCxlwp7KHultKumUv1w32RLZV
uQbBDaKodhdK+LiOrJK0f06xIdQEptOpF2tZdUfThfudBvqJ0GFzgLBx9oRu
aJECYLfxCXvOJpw+hEvzKSoCFEplkud+IZES9tq9Ebhz8PyBNEP87lhHciOc
R8yx8KIa1zVVWqRRa9axB4170CfChY1x5R231qWNWrmPJEuoC5c6l2oFlGvZ
PEy7c9KYkguC+7x3IpgZnJH/rBKvqBtwbqILVeIu69RSUIqUwnZZwb0FGCdC
EhG8K2xKXS6/adWuWag+Z0KlAqlMWj5T4evZe77Wg9pcCyYMWuNT0jDJAVFh
fPPNYTN745rZw0peUTKLK1FmSdNUPrBw5FYAM34rANElsyqbzYO7NUZ1DIy2
z0Dzwd0h2bus6EBcYuGE2tZaLRg2i8QqXJdzjANqBEJrfkijogpyfWzKrZr9
zUvxyuKUA8w/Qf8bpg8qRuPuapwLvcPBWlx37jIHtsH1cdR3vWYwpYMdm3Xa
3OZVObbz5Ks7N9+w8yTeebzVvDHkDuaWCTXnIuPuNVUiWCvfmX3OoBgQjkch
+KtuhT6c7UTKBWVaR/nClIdLgBFDjW880tHRQzUjH4KrfTW+9jXQN1/Mn7jb
MePCGt8uOuEyzPGmEhp2cjOyKa6dzr5/llSgm1PhNSp9hS037W2/rIxwP85Z
sP224q41y9P5M5ES5SFy3A8oxV1IJbdGY22xL3pqOLwaLWWk5DWt7bDID/vp
UYU38g/ZE2zb79a8pS99Rzv4Cdf89IU+Qga5FHHowzDE0xfP9QGQmsREXYY6
acnEOOXQgxNlOyrUig0rmgiWULGN9N68f09G3PcYZS5fsRIL6+At7UEunU9I
bJWoRKXUGp5WohfacvWc6/fjrp32xZhegdcOzT0tIcoegIneXf/OcVr6I3Q5
mLAZTKJNn1wjtUz9Pnf20IQFM0g+2siGChy4Jk5ucPOpOv0wp7s8bZB+hWjn
ql+jXIaL8/NzCUzz+Q31UAbD4HtGil1FzQQ1qUAF1ruPyR+/AX7xzYwFHJQ5
4bJq7q5JdfpuQGnktABtIjmjSFtVszOSGQC1SjesCk+lsaX0zdHSqtkZ3sjA
joggIoTiF3SfwvRbfv8qze2CtnnPHmNPRM6sxKRhzdLzOzfhzjWjk++o0s4D
IWeN9HVutciVjFRJhzd4uTuOYHGUtTe8veYjR2dOAKSnfZiSSw4OyAGVrzm2
eFF0I3eFkzENBCRqeokWnUxOFd1La/4K/2V1gIpnuB9CGdzWJyydE+z2wb09
7pIl7PiAPRtsUD7ahJWKCgURc9sq4xkx/13axKzQXxjk9XmxpC4HKZgPrpsB
llysE+8QAetrcGnJF5d4r+oLWybxtTVS9kwnFXB0YUIgbH1LdUwb1BLP6GF1
HkpCYxBmx7bVKHyOXlDDAeojV9HoNan3eL3q+2jZw/tmcudYS1dg7PjkWXzd
uNG4I2gyoXzTXx68DoboP7ADg7t8bKbOVjUyLSXsMN7gF+uOKhstsuMml3b7
GsT3paIl5b/NGMXYfrOly13GJC3mlTwbn8HequNSb8yQaxh5zsTPSVlS4XkH
N5R65R6A/ZpuTfwziAlGzyBWaU5e//ns8rRX2uVuMHXX1g4u/AkNlwVXSYUM
gs9QLpXnu7Jzvn00XjH1N2irnZGeYS7i00r/T0wE0giXDEcYtpZWVEFxHjfL
xtxir1eQnRM8C7rtbsf979Ds1mArXWNlRlCg3+dc40bE0thviH2JpmEauDIL
7QgVkyRvdBTbNIaKlGzYKz6EK/F/LLV2GTqt62o6yNWJp+bKttZFPsc2jApl
TIxogHcUTBhZMiYac7sTgE4lOSe+hRilujUuMKHNpQIE4NARMUs8eO7DoY0S
OPlEdV7OKltb6gTrZEzYbAnvWQopijKJrqQf/TASzyLJtf10+RjeIujfhEJq
DpduUa9+RPJq6Y18arjBbdG4nRjls5D2zu0tHJMgG4OHj8V43LzCNdPf7sLb
JbHnddDel2Yw0QWfuDvcF4y0qbiHwMgVkuTnT9Ypd5FF15QJRpT1TZ353ZWc
9XmC5ynXU506gCAwFGDmhC0J8cIUh1NUBwrc+R5HkktU+vmInEoAqgmhd3hb
oIBty2WwrmuswofuFq1JWlGe37A/K8DkHap1wRHRvVsuLXNE9+ckL/mB3eja
LdZdhRtmajL69ptyhVfPOD313eKV66cMBKIZ9JW7Ybb92qVjwg1ldZwNKAac
VNe5K9nlUUnrD1aTNx7FXTW99tS8w3iYnPIclkKXWPClDnxTEVC61n4J7cdd
HvytXZ8//+lidkb3ds1qsO8/tbPM52zhV3nXkLEVnPlg6ysqysMMPOqNzye/
FNWHqsh8q8AA9TQTvN84UJzBpbRadA+awS0I7DqguLGX8nza6keRy5oGV9RI
12Vh7RQuJJHuKg+8w1M25BwELht0rCPA0/lzQtAejUgLPSkNsjV6mfEWCHHT
HLgI2SNAtAsJUVM9PWO3q87VJCFhS97NQ6rkAx009MJuI/emh7Rbscsp4T48
LDECRhfcobeiMIAvBx3PqorpxOmafRNSy/+Em2GHKMEV7U862oAyUqbZjSn4
MmzHwQSozVBWWPy30pb3+rTLU3DNUDT33Lfoi5sFYvoz6YAPtQCSQg2nrwX6
+FSsD4OySFKoaX8ueEeukocYdC4tJUzPeilnVykwgkXbIuJIrs/FVjCQmw5d
lNz8U24TYrVYes9IInTQ6toVTiUn4uEA0VTTLXVpWKNw6i6vCaKUYgy1XOor
daSy8qg6m/1+LDIqCRCWbAA7eYslUb56S10OiWuQS2U3gVqlvCBq3w/weIQe
mbucurxr0ZiW4lXuMuVJVc52AMsJuhgBmFzwwjnTLiaKZS50kkx5mOkGZ2mC
DC9K3JJECHLuUJdS613IVOjlpR9Hjoz2UMcD8CpPqsfKBNI3d9nTsRVeqfCJ
PK20BKpKC5oyLKuqRcV259qxDyiJegOnYZP5/h0DRGQbaqfQq9nQiwOPXHDj
nZ3xrGZXob3qertIKbtg+lWv+PhjzCxGWVFwTfZIKZReb1Mdk1PS2ErZA/MX
jUsNKj2k/RaBRTew1LZuo75mQ27clbRa8r02u0GANL5bwJh+/UvQoya8MSgu
VpaOOYoE0uf46CyYTQ74v92mlHH8XyX7kLseix7nO4X7yw/JtyO3NkT9VZMg
xDtoiOzdM74vMqmNIL1ZN0KLDFteJIyJug37Cbt8UJtUPT8Zk9RntuNgPQ2y
Xu4YE+RNXb6/oQE5F973NXqgpdEcYeEPy7Wd/aaXSXih6ZYEmWK9rrVHLpLs
zetPOTbFNKWqGXafgEkdigfXMFGbVhxcKw4wvsmDTsP+syi6j4wcwYa7agnn
8J4R7bN69OWp3x2Ch8IRvmEwGZ/aBT7xHbZZO+AQqJYxMDf6/7aUsFS3vxRt
ZpyozAxWRKrUYoXKD4j/jfYYeFfdwjDXQBu5T4fCNBmpR27wbh6xA9mH4e/d
3qda+ErdHyi84tTMe4lXs+2fb3JU/rRphjPcM9fI3IwnAvjIsggal/C8p7tH
OMwl1XZSd8zedXF4XmxQH/yADhu++PtXoN/f06xDiGBiDt4eZf4T75DBJPKl
AAA=
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t><contact fullname="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.</t>
<t>The document was further improved with reviews from <contact
fullname="Ignes Robles"/> and <contact fullname="Ben Kaduk"/>.</t>
</section>
<!--[rfced] We had the following questions related to terminology use
throughout the document:
a) We see that eap.arpa. domain is used consistently throughout.
However, we see the following with regard to .arpa:
"arpa" domain
".arpa" domain
Should these be made consistent between themselves or more similar to
eap.arpa. (i.e., no double quotes and trailing period)?
Further, please review the following with regard to the trailing period:
Original:
...the NAI SHOULD be of the form "action@name.eap.arpa".
--> -->
<!--[rfced] FYI - We see that an extra space is being inserted after
"eap.arp." in some places (e.g., titles). We will dig into to
see if there is some formatting we can implement to remove the
added space. -->
</back>
</rfc> </rfc>
 End of changes. 190 change blocks. 
1267 lines changed or deleted 820 lines changed or added

This html diff was produced by rfcdiff 1.48.