<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>
<?xml-model href="rfc7991bis.rnc"?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!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.10) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-emu-eap-arpa-10" number="9965" category="std" consensus="true" submissionType="IETF" updates="5216, 9140, 9190" obsoletes="" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <front>

 <!-- xml2rfc v2v3 conversion 3.24.0 [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
-->
  <front>
    <title abbrev="eap.arpa">The eap.arpa. domain Domain and EAP provisioning</title> Extensible Authentication Protocol (EAP) Provisioning</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-emu-eap-arpa-10"/> name="RFC" value="9965"/>
    <author initials="A." surname="DeKok" fullname="Alan DeKok">
      <organization>InkBridge Networks</organization>
      <address>
        <email>alan.dekok@inkbridge.io</email>
      </address>
    </author>
    <date year="2025" month="September" day="04"/>
    <area>Internet</area>
    <workgroup>EMU Working Group</workgroup>
    <keyword>Internet-Draft</keyword> year="2026" month="April"/>
    <area>SEC</area>
    <workgroup>emu</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <?line 72?>
<t>This document defines the eap.arpa. domain for use only in Network Access
Identifiers (NAIs) as a way for Extensible Authentication Protocol (EAP) peers
to signal to EAP servers that they wish to obtain limited, and
unauthenticated, network access.  EAP peers signal which kind of access is
required via certain predefined identifiers which that use the Network Access Identifier (NAI) NAI format of RFC 7542.  A table of identifiers and meanings is
defined, which includes entries for RFC 9140.</t>
      <t>This document updates RFC5216 RFCs 5216 and RFC9190 9190 to define an
      unauthenticated provisioning method.  Those specifications suggested suggest
      that such a method has is possible, but they did do not define how it would be
      done.  This document also updates RFC9140 RFC 9140 to deprecate "eap-noob.arpa", "eap-noob.arpa"
      and replace it with "@noob.eap.arpa"</t> "@noob.eap.arpa".</t>
    </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/browse/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>
  <middle>
    <?line 81?>

    <section anchor="introduction">
      <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
pre-provisioned credentials.  Without credentials, the device cannot
obtain network access in order to be provisioned with credentials.
This limitation creates a bootstrapping problem.</t>
      <t>This specification addresses that bootstrapping problem.  It creates a
framework for predefined "well-known" provisioning credentials, credentials and
instantiates that framework for two mechanisms.</t>
      <t>Clients can submit these predefined provisioning credentials to a server in order to
obtain limited network access.  At the same time, servers can know in
advance that these credentials are to be used only for provisioning,
and provisioning; thus, they can
avoid granting unrestricted network access to peers which that submit these credentials.</t>
      <t>The device can either use the EAP channel itself for provisioning, as
with TEAP the Tunnel Extensible Authentication Protocol (TEAP) <xref target="RFC7170"/>, 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
provisioned, it can use those provisioned credentials to obtain full
network access.</t>
      <t>The predefined provisioning credentials use a generic identity format.
Identifiers in this space are generically referred to as "EAP
Provisioning Identifiers" (EPI).</t> (or "EPIs").</t>
      <t>Since the identity is predefined and used only for unauthenticated network access, there is little benefit to specifying
predefined passwords.  Where supported by the underlying EAP method,
this specification provides for password-less access.  Where passwords
are required, the password is defined to be the same as the identity.</t>
      <section anchor="background-and-rationale">
        <name>Background and Rationale</name>
        <t>In this section, we provide background on the existing functionality, functionality
and describe why it was necessary to define provisioning methods for
EAP.</t>
        <section anchor="review-of-existing-functionality">
          <name>Review of Existing Functionality</name>
          <t>For EAP-TLS, both <xref target="RFC5216"/> Section 2.1.1 target="RFC5216" section="2.1.1" sectionFormat="comma"/> and <xref target="RFC9190"/> provide
for "peer unauthenticated access".  However, those documents define no
way for a peer to signal that it is requesting such access.  The
presumption is that the peer connects with some value for the EAP
Identity, but does so without using a client certificate.  The EAP server is
then supposed to determine that the peer is requesting unauthenticated
access,
access and take the appropriate steps to limit authorization.</t>
          <t>There appears to be no EAP peer or server implementations which that
support such access, access since there is no defined way to perform any of
the steps required, i.e., to signal that this access is desired, desired and
then limit access.</t>
          <t>Wi-Fi
          <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="HOTSPOT"/>.
However, there appears appear to be few deployments of this specification.</t>
          <t>EAP-NOOB
          <t>Nimble Out-of-Band Authentication for EAP (EAP-NOOB) <xref target="RFC9140"/> takes this process a step further.  It defines both
a way to signal that provisioning is desired, desired and also a way to
exchange provisioning information within EAP-NOOB.  That is, there is
no need for the device to obtain limited network access, access as all of the
provisioning is done inside of the EAP-NOOB protocol.</t>
          <t>Tunnel Extensible Authentication Protocol (TEAP)
          <t>TEAP <xref target="RFC7170"/> target="RFC9930"/> provides for provisioning via an unauthenticated TLS
tunnel.  That document  It provides for a server unauthenticated
provisioning mode, but the inner TLS exchange requires that both ends
authenticate each other.  There are ways to provision a certificate,
but the peer must still authenticate itself to the server with
pre-existing
preexisting credentials.  As a result, any provisioning method which that uses TEAP will have to address this limitation.</t>
        </section>
        <section anchor="taxonomy-of-provisioning-types">
          <name>Taxonomy of Provisioning Types</name>
          <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
<xref target="RFC9140"/>.  The second is where EAP is used to obtain limited
network access (e.g. (e.g., as with a captive portal).  That limited network
access is then used to run IP based IP-based provisioning
over more complex protocols.</t>
        </section>
        <section anchor="rationale-for-provisioning-over-eap">
          <name>Rationale for Provisioning over EAP</name>
          <t>It is often useful to do all provisioning inside of EAP, EAP because the EAP / AAA Authentication, Authorization, and Accounting (AAA)
admin does not have control over the network.  It is not always
possible to define a captive portal where provisioning can be done.
As a result, we need to be able to perform provisioning via EAP, and EAP:
not via some IP protocol.</t> IP.</t>
        </section>
      </section>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <t>EAP

<!--[rfced] Please confirm the use of the period in the following
     (i.e., outside the quotation marks).  Seems to be related to
     domain use.

Original:
The EPI is an NAI which is a subdomain of "eap.arpa".

Perhaps:
The EPI is an NAI that is a subdomain of "eap.arpa.".
-->
<dl spacing="normal" newline="true">
  <dt>EAP Provisioning Identifier</t>
      <ul empty="true">
        <li>
          <t>The Identifier</dt>
  <dd><t>The EAP Provisioning Identifier (or EPI) is defined to be a strict subset of
  the Network Access Identifier (NAI) NAI <xref target="RFC7542"/>.  The EPI is an
  NAI which that is a subdomain of "eap.arpa".  The "realm" portion of the NAI is
  defined in <xref section="2.2" sectionFormat="comma" target="RFC7542"/>,
  which is a more restrictive subset of the domain name conventions specified
  in <xref target="STD13"/>.</t>
  <t>Readers of this document should note that the realm portion of the NAI is
  different from a domain name.  In addition to the character set being more
  limited, the realm portion of the NAI does not include a trailing ".".</t>
        </li>
      </ul>
      <t>eap.arpa</t>
      <ul empty="true">
        <li>
          <t>The period
  (".").</t></dd>
  <dt>eap.arpa</dt>
  <dd><t>The realm portion of the NAI.</t>
  <t>This document uses the term "eap.arpa realm" when using that name within
  the contect context of an NAI.</t>
        </li>
      </ul>
      <t>eap.arpa.</t>
      <ul empty="true">
        <li>
          <t>The NAI.</t></dd>
  <dt>eap.arpa.</dt>
  <dd><t>The domain name "eap.arpa.".</t>
  <t>This document uses the term "eap.arpa. domain " domain" when using that name
  within the contect context of the DNS.  The trailing "." period (".") is added for consistency
  with DNS specifications.</t>
        </li>
      </ul>
      <t>The specifications.</t></dd>
</dl>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
<?line -6?>
        </t>
    </section>
    <section anchor="overview">
      <name>Overview</name>
      <t>A device which that has no device-specific credentials can use a predefined
provisioning identifier in Network Access Identifier (NAI) NAI format <xref target="RFC7542"/>.  The
NAI is composed of two portions, portions: the utf8-username, utf8-username and the utf8-realm
domain.  For simplicity here, simplicity, we refer to these as the "username" and
"realm" fields.</t>
      <t>The realm is chosen to be independent of, and unused by, any existing
organization, and thus
organization; thus, it is to be usable by all organizations.  The realm
needs to be one which that is not automatically proxied by any existing
Authentication, Authorization, and Accounting (AAA)
AAA proxy framework as
defined in <xref section="3" sectionFormat="comma" target="RFC7542"/>.  The realm also needs to be one
which
that does not return results for <xref target="RFC7585"/> dynamic discovery.</t>
      <t>This discovery as described in <xref target="RFC7585"/>.</t>
      <t>However, this specification does not, however, not forbid the routing of packets for
NAIs in the eap.arpa realm.  Instead, it leaves such routing up
to individual organizations.</t>
      <t>This specification is fully compatible with all known
EAP implementations, so it is fail-safe.  When presented with a peer
wishing to use this specification, existing implementations will
return EAP Failure, Failure and will not otherwise misbehave.</t>
      <section anchor="the-eaparpa-realm">
        <name>The eap.arpa realm</name> Realm</name>
        <t>This document defines the eap.arpa realm as being used for
provisioning within EAP.  A similar domain has previously been used
for EAP-NOOB <xref target="RFC9140"/>, target="RFC9140"/> as "eap-noob.arpa".  This document extends
that concept, concept and standardizes the practices surrounding it,</t>
        <t>NOTE: it.</t>

<!-- [rfced] We had a few questions about the following:

Original:
   NOTE: the "arpa" domain is controlled by the IAB.  Allocation of the
   eap.arpa. domain name requires agreement from the IAB.</t>
        <t>RFC-EDITOR: This text can be IAB.

a) We have updated on publication 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 indicate that 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 it.</t> the allocation of eap.arpa.</t>
      </section>
      <section anchor="the-realm-field">
        <name>The realm field</name> Realm Field</name>
        <t>The NAIs defined by this specification use the
<xref target="RFC7542"/> "realm" field defined in
<xref target="RFC7542"/> to signal the behavior being requested; in
particular, the subdomain under the eap.arpa. domain allows for different
requested methods to be distinguished.  The subdomain in the realm
field is assigned via the EAP "EAP Provisioning Identifier Registry Identifiers" registry <xref target="EAPREG"/>, which
is defined in <xref target="registry"/>. The subdomain MUST <bcp14>MUST</bcp14> follow the syntax defined in <xref section="2.2" sectionFormat="comma" target="RFC7542"/>, which is a more restrictive subset of the domain name conventions specified in <xref target="STD13"/>.</t>

<!--[rfced] Please clarify the use of "the EAP registry" in this text:
     Original: ...However, the EAP registry does not follow the domain
     name conventions specified in...
-->
<t>Where possible, the first subdomain of the eap.arpa. domain SHOULD <bcp14>SHOULD</bcp14> use the EAP
method name, as defined in the IANA Extensible "Extensible Authentication Protocol
(EAP) Registry Registry" registry group, "Method Types" registry.  However, the EAP registry does
not follow the domain name conventions specified in <xref target="STD13"/>, so it
is not always possible to make a "one-to-one" one-to-one mapping between the Method Type Method-Type
name and a subdomain of the eap.arpa. domain.</t>
        <t>Where it is not possible to make a direct mapping between the EAP
Method Type
Method-Type name due to the EAP Method Type Method-Type name not matching the <xref section="2.2" sectionFormat="comma" target="RFC7542"/> format, the NAI which that is defined in the EAP "EAP Provisioning Identifiers Identifiers" registry MUST <bcp14>MUST</bcp14> use a realm name
which
that is similar enough to allow the average reader to understand which EAP
Method Type
Method-Type is being used.</t>
        <t>Additional subdomains are permitted in the realm, which realm; these permit vendors and
Standards Development organizations Organizations (SDOs) the ability to self-assign
a delegated range of identifiers which that do not conflict with other
identifiers.</t>
        <t>Any realm defined in this registry (e.g. (e.g., "tls.eap.arpa") also
implicitly defines a sub-realm "v." (e.g. (e.g., "v.tls.eap.arpa").  Vendors
or SDOs can self-allocate within the "v." realm, realm using realms that
they own.  For example, a company that owns the "example.com." domain
could self-allocate and use the realm "example.com.v.tls.eap.arpa".
See <xref target="vendor-assignment"/> for more discussion of this topic.</t>
        <t>This specification does not make any provisions for private-use
realms.  The "v." sub-realm is sufficient for all private uses.</t>
        <t>Experimental provisioning methods MUST <bcp14>MUST</bcp14> be defined within the
appropriate vendors vendor's name space.  For drafts documents within the IETF, the "ietf.org" vendor space MUST <bcp14>MUST</bcp14> be used.  Different uses SHOULD <bcp14>SHOULD</bcp14> be distinguished
by using the name of a working group or document, such as
"emu.ietf.org.v.eap.arpa".</t>
      </section>
      <section anchor="the-username-field">
        <name>The username field</name> Username Field</name>
        <t>The username field is dependent on the EAP method being used for
provisioning. For example, <xref target="RFC9140"/> uses the username "noob". Other
EAP methods MAY <bcp14>MAY</bcp14> omit the username as recommended in <xref target="RFC7542"/>.  The
username of "anonymous" is NOT RECOMMENDED <bcp14>NOT RECOMMENDED</bcp14> for specifications using
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
confusion.</t>
        <t>The username field is assigned via the EAP "EAP Provisioning Identifier
Registry Identifiers"
registry, which is defined in <xref target="registry"/>.  The username field MAY <bcp14>MAY</bcp14> be
empty,
empty or else hold a fixed value. While <xref target="RFC7542"/> recommends
omitting the username portion for user privacy, the names here are defined
in public specifications.  User  Therefore, user privacy is therefore not needed for provisioning identifiers,
and identifiers;
the username field can be publicly visible.</t>
      </section>
      <section anchor="operation">
        <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 realm
to define the EPI, we now describe how
those EPIs are used by EAP peers and EAP peers to signal provisioning
information</t>
information.</t>
        <section anchor="eap-peers">
          <name>EAP Peers</name>
          <t>An EAP peer signals that it wishes a certain kind of
provisioning by using an EPI, EPI along with an associated EAP
method.  The meaning of the EPI, and behavior of the peer, are
defined by a separate specification.  That specification will
typically define both the EPI, EPI and the EAP method or methods which that are used for
provisioning.</t>
          <t>The EPI used by the peer MUST <bcp14>MUST</bcp14> be taken from an entry in the "EAP
Provisioning Identifiers" registry, and the EAP method used with that
NAI MUST <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
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 <bcp14>MUST NOT</bcp14> have a configuration interface which that lets the EAP user identifier field be
configured directly.  Instead  Instead, the user (or some other process) chooses
a provisioning method, method and the EAP peer then selects the EPI
which
that matches that provisioning method.</t>
          <t>While EAP peers allow users to enter user identifiers directly for existing EAP
methods, they MUST NOT <bcp14>MUST NOT</bcp14> check whether those identfiers identifiers match any EPI.  Any user who
enters an identifier which that matches an EPI will either will get rejected because the server
does not support provisioning, provisioning or the user will be placed into a
captive portal.  There is are no security or privacy issues with a user
manually entering an EPI as the user identifier.</t>

          <t>When all goes well, running EAP with the EPI results in
new authentication credentials being provisioned.  The peer then drops
its network connection, connection and re-authenticates using the newly
provisioned credentials.  The user MAY <bcp14>MAY</bcp14> be involved in this process,
but
but, in general general, provisioning results in the EAP peer automatically
gaining network access using the provisioned credentials.</t>
          <t>There are a number of ways in which provisioning can fail.  One way is
when the server does not implement the provisioning method.  Therefore, EAP peers
therefore MUST
<bcp14>MUST</bcp14> track which provisioning methods have been tried, tried and
not repeat the same method to the same EAP server when receiving an
EAP Nak.</t>
          <t>Peers MUST <bcp14>MUST</bcp14> rate limit their provisioning attempts.  If provisioning
fails, it is likely because provisioning is not available.  Retrying
provisioning repeatedly and in quick succession is not likely to change
the server behavior.  Instead, it is likely to result in the peer
being blocked.  The peer SHOULD <bcp14>SHOULD</bcp14> retry provisioning no more than once
every few minutes, minutes and SHOULD <bcp14>SHOULD</bcp14> include jitter and exponential backoff
on its provisioning attempts.</t>
          <t>Since there is no way to signal whether the failed provisioning is due
to a transient failure on the EAP server, server or whether it is due to the
EAP server not supporting that provisioning method, EAP peers SHOULD <bcp14>SHOULD</bcp14>
err on the side of long delays between retrying the same provisioning
method to an EAP server.  EAP peers MAY <bcp14>MAY</bcp14> retry a given provisioning
method after a sufficiently long interval that the EAP server might
have implemented the provisioning method, e.g., at least a day, day and
perhaps no more than a month.</t>
          <t>Another way for the provisioning method to fail is when the new
credentials do not result in network access.  It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that
when peers are provisioned with credentials, that they immediately try
to gain network access using those credentials.  That process allows
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
certificate with notAfter date set).
It SHOULD therefore
Therefore, it <bcp14>SHOULD</bcp14> attempt to provision new credentials before the
current set expires.  Unfortunately, any re-provisioning process with
EAP will involve the device dropping off from the "full" network, network in
order to connect to the provisioning network.  It  Therefore, it is therefore
RECOMMENDED
<bcp14>RECOMMENDED</bcp14> that re-provisioning methods be provided which that can be used
when the device has full network access.  See <xref target="specifications"/> for
additional discussion on this topic.</t>
        </section>
        <section anchor="eap-servers">
          <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
EAP-Request/Identity message.  An EAP server supporting this
specification MUST <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>
          <t>If the server receives an EPI which that is malformed, it MUST <bcp14>MUST</bcp14>
reply with an EAP Failure, Failure as per <xref section="4.2" sectionFormat="comma" target="RFC3748"/>.  For example, an NAI may end with the eap.arpa realm, realm but may also contain data which that is not permitted by the format described in <xref target="RFC7542"/> format. target="RFC7542"/>.
Otherwise, the EPI is examined to determine which provisioning method
is being requested by the peer.</t>
          <t>If the server does not recognize the EPI requested by the peer, it
MUST
<bcp14>MUST</bcp14> reply with an EAP Nak of type zero (0).  This reply indicates
that the requested provisioning method is not available.  The server
also MUST <bcp14>MUST</bcp14> reply with a Nak of type zero (0) as per <xref section="5.3.1" sectionFormat="comma" target="RFC3748"/>, target="RFC3748"/> if the peer proposes an EAP method which that is not supported by
the server, server or is not recognized as being valid for that provisioning
method.  The peer can then take any remedial action which that it
determines to be appropriate.</t>
          <t>Once the server accepts the provisioning method, it then replies with
an EAP method which MUST that <bcp14>MUST</bcp14> match the one associated with the EPI.  The EAP process then proceeds as per the EAP state machine
outlined in <xref target="RFC3748"/>.</t>
          <t>Implementations MUST <bcp14>MUST</bcp14> treat peers using an EPI as
untrusted,
untrusted and untrustworthy.  Once such a peer is authenticated, it MUST <bcp14>MUST</bcp14>
be placed into a limited network, network such as a captive portal.  The
limited network MUST NOT <bcp14>MUST NOT</bcp14> permit unrestricted network access.
Implementations should be aware of methods which that bypass simple
blocking,
blocking such as tunneling data over DNS.</t>
          <t>A secure provisioning network is one where only the expected traffic
is allowed, allowed and all other traffic is blocked.  The alternative of
blocking only selected "bad" traffic results in substantial security
failures.  As most provisioning methods permit unauthenticated devices
to gain network access, these methods have a substantial potential for
abuse by malicious actors.  As a result, the limited network needs to
be designed assuming that it will be abused by malicious actor.</t> actors.</t>
          <t>A limited network SHOULD <bcp14>SHOULD</bcp14> also limit the duration of network access by
devices being provisioned.  The provisioning process should be fairly
quick, and
quick: in the order of seconds to tens of seconds in duration.
Provisioning times longer than this likely indicate an issue, and issue; it
may be useful to block the problematic device from the network.</t>
          <t>A limited network SHOULD <bcp14>SHOULD</bcp14> also limit the amount of data being
transferred by devices being provisioned, provisioned and SHOULD <bcp14>SHOULD</bcp14> limit the network
services which that are available to those devices.  The provisioning
process generally does not need to download large amounts of data, and
similarly data;
similarly, it does not need access to a large number of services.</t>
          <t>Servers SHOULD <bcp14>SHOULD</bcp14> rate limit provisioning attempts.  A misbehaving peer
can be blocked temporarily, temporarily or even permanently. Implementations
SHOULD
<bcp14>SHOULD</bcp14> limit the total number of peers being provisioned at the same
time.  There is no requirement for RADIUS servers to allow all peers to
connect without limit.  Instead, peers are provisioned at the
discretion of the network being accessed, which may permit or deny
those devices based on reasons which that are not explained to those
devices.</t>
          <t>Implementations SHOULD <bcp14>SHOULD</bcp14> use functionality such as the RADIUS Filter-Id
attribute (<xref section="5.11" sectionFormat="comma" target="RFC2865"/>) to limit network access for the
peer being provisioned, as discussed above in <xref target="eap-servers"/>.  For
ease of administration, the Filter-Id name could simply be the EPI, EPI or
a similar name.  Such consistency aids with operational considerations
when managing complex networks.</t>
          <t>Implementations MUST <bcp14>MUST</bcp14> prevent peers in the limited network from
communicating with each other.  There is no reason for a system that
is being provisioned to communicate with anything other than the
provisioning server(s).</t>
        </section>
      </section>
      <section anchor="other-considerations">
        <name>Other Considerations</name>
        <t>Implementations MUST NOT <bcp14>MUST NOT</bcp14> permit EAP method negotiation with
provisioning credentials.  That is, when an EPI is used,
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
EAP methods given in that Nak MUST <bcp14>MUST</bcp14> be ignored.</t>
        <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
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
only one provisioning method.</t>
        <t>As a result, there is no need to require a method for negotiating
provisioning methods.</t>
      </section>
      <section anchor="specifications">
        <name>Considerations for Provisioning Specifications</name>
        <t>The operational considerations discussed above in this document have a number of
impacts on specifications which that define provisioning methods.</t>
        <section anchor="negotiation">
          <name>Negotiation</name>
          <t>Specifications which that define provisioning for an EAP method SHOULD <bcp14>SHOULD</bcp14>
provide a method-specific process by which implementations can
negotiate a mutually acceptable provisioning method.</t>
          <t>For
          <t>However, for the reasons noted above, however, in this document, we cannot make this suggestion
mandatory.  If it is not possible for a provisioning method to define
any negotiation, then that limitation should not be a barrier to
publishing the specification.</t>
        </section>
        <section anchor="renewal-of-credentials">
          <name>Renewal of Credentials</name>
          <t>Where a provisioning method is expected to create credentials that do
not expire, the specification SHOULD <bcp14>SHOULD</bcp14> state this explicitly.</t>
          <t>Where credentials expire, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that specifications
provide guidance on how the credentials are to be updated.  For
example, an EAP method could permit re-provisioning to be done as part
of a normal EAP authentication, authentication using the currently provisioned
credentials.</t>
          <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the provisioning methods provide for a method
which
that can be used without affecting network access.  A specification
could define provisioning endpoints such as Enrollment over Secure
Transport (EST) <xref target="RFC7030"/>, target="RFC7030"/> or Internet X.509 Public Key Infrastructure
Certificate Management Protocol (CMP) <xref target="RFC9810"/>.  The provisioning endpoints could be
available both on the provisioning network, network and on the provisioned
(i.e., normal) network.  Such an architecture means that devices can be
re-provisioned without losing network access.</t>
        </section>
      </section>
      <section anchor="notes-on-aaa-routability">
        <name>Notes on AAA Routability</name>
        <t><xref section="3" sectionFormat="comma" target="RFC7542"/> describes how the NAI allows authentication
requests to be routable within an a AAA proxy system.  While the EPI uses the
NAI format, the eap.arpa realm has been chosen because it is not
routable within an a AAA proxy system.</t>
        <t>When we say that the eap.arpa realm is not routable in an a AAA proxy
system, we mean two different things.  First, the things:</t>
<ol>
<li>The eap.arpa. domain
does not exist within the DNS, so it will never be resolvable for
<xref target="RFC7585"/>
dynamic discovery.  Second, that the discovery as described in <xref target="RFC7585"/>.</li>
<li>The eap.arpa realm will
never be used by any administrator, as administrator; the administrator is unable to
satisfy the requirements of <xref section="2.5" sectionFormat="comma" target="RFC7542"/> by registering
the realm within the DNS.</t> DNS.</li>
</ol>
        <t>In addition, administrators will not have statically configured AAA
proxy routes for this domain.  Where routes are added for this domain,
they will generally be used to implement this specification.</t>
        <t>In order to avoid spurious DNS lookups, RADIUS servers supporting
<xref target="RFC7585"/> SHOULD <bcp14>SHOULD</bcp14> perform filtering in the domains which that are sent to
DNS.  Specifically, names in the eap.arpa. domain MUST NOT <bcp14>MUST NOT</bcp14> be
looked up in DNS.</t>
      </section>
    </section>
    <section anchor="interaction-with-eap-methods">
      <name>Interaction with EAP Methods</name>
      <t>As the provisioning identifier is used within EAP, it necessarily has
interactions with, and effects on, the various EAP methods.  This
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
to succeed.  For example, both EAP-MSCHAPv2 (PEAP) (Protected Extensible Authentication Protocol aka PEAP) and EAP-PWD
<xref target="RFC5931"/> perform cryptographic exchanges where both parties
knowing
know a shared password.  Where password-based methods are used, the
password SHOULD <bcp14>SHOULD</bcp14> be the same as the provisioning identifier, as there
are few reasons to define a method-specific password.</t>
      <t>This requirement also applies to TLS-based EAP methods such as EAP Tunneled Transport Layer Security (EAP-TTLS)
and Protected Extensible Authentication Protocol (PEAP). PEAP.  Where the TLS-based EAP method provides for an inner
identity and inner authentication method, the credentials used there
SHOULD
<bcp14>SHOULD</bcp14> be the provisioning identifier for both the inner identity, identity and
any inner password.</t>
      <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that provisioning be done via a TLS-based EAP methods. method.
TLS provides for authentication of the EAP server, server along with integrity
and confidentiality protection for any provisioning data exchanged in the tunnel.
Similarly, if provisioning is done in a captive portal outside of EAP,
EAP-TLS permits the EAP peer to run a full EAP authentication session
while having nothing more than a few certificate authorities Certificate Authorities (CAs)
locally configured.</t>
      <section anchor="high-level-requirements">
        <name>High Level Requirements</name>
        <t>All provisioning methods which that are specified within the eap.arpa. domain MUST <bcp14>MUST</bcp14> define a way to authenticate the server.  This
authentication can happen either at the EAP layer (as with TLS-based
EAP methods), methods) or after network access has been granted (if credentials
are provisioned over HTTPS).</t>
        <t>Where TLS-based EAP methods are used, implementations MUST <bcp14>MUST</bcp14> still
validate EAP server certificates in all situations other than
provisioning.  Where the provisioning method under the eap.arpa. domain defines that provisioning happen happens via another protocol such as
with HTTPS, the EAP peer MAY <bcp14>MAY</bcp14> skip validating the EAP server
certificate.</t>
        <t>Whether or not the server certificate is ignored, the peer MUST <bcp14>MUST</bcp14> treat
the local network as untrusted.  <xref section="6" sectionFormat="comma" target="RFC8952"/> has more
discussion on this topic.</t>
        <t>The ability to not validate the EAP server certificates relaxes the
requirements of <xref section="5.3" sectionFormat="comma" target="RFC5216"/> which requires that the
server certificate is always be validated.  For the provisioning case, provisioning,
it is acceptable in some cases to not validate the EAP server
certificate,
certificate but only so long as when there are other means to authenticate
the data which that is being provisioned.</t>
        <t>However, since the device likely is likely otherwise configured with web CAs <xref target="CAB"/>
otherwise, target="CAB"/>, the captive portal would also be unauthenticated, unauthenticated
provisioning methods could use those CAs within an EAP method in order
to allow the peer to authenticate the EAP server.  Further discussion
of this topic is better suited for the specification(s) which that define a
particular provisioning method.  This issue is not discussed further here,
other than to say that it is technically possible.</t>
      </section>
      <section anchor="eap-tls">
        <name>EAP-TLS</name>
        <t>This document defines an NAI called "portal@tls.eap.arpa", which
allows EAP peers to use unauthenticated EAP-TLS.  The purpose of the
identifier is to allow EAP peers to signal to EAP servers that they wish
to obtain a "captive portal" style network access.</t>
        <t>This identifier signals to the EAP server that the peer wishes to obtain
"peer unauthenticated access" as per <xref section="2.1.1" sectionFormat="comma" target="RFC5216"/> and
<xref target="RFC9190"/>.  Note that peer unauthenticated access MUST <bcp14>MUST</bcp14> provide for
authentication of the EAP server, such as with a server certificate.
Using TLS-PSK with a well-known PSK Pre-Shared Key (PSK) value is generally not
appropriate, as it would not provide server authentication.</t>
        <t>An EAP server which that agrees to authenticate this request MUST <bcp14>MUST</bcp14> ensure
that the device is placed into a captive portal with limited network
access as discussed above in <xref target="eap-servers"/>.</t>
        <t>This method is an improvement over existing captive portals, which are
typically completely unsecured and unauthenticated.  Using peer
unauthenticated TLS for network access ensures that the EAP server is
proven to be authentic.  The use of 802.1X ensures that the link
between the EAP peer and EAP authenticator (e.g. (e.g., access point) is also
	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
<xref target="RFC8952"/>.  The captive portal can advertise support for the
eap.arpa. domain via an 802.11u realm.</t>
      </section>
      <section anchor="eap-noob">
        <name>EAP-NOOB</name>
        <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that server implementations of Nimble out-of-band authentication for EAP (EAP-NOOB) EAP-NOOB accept both
identities "noob@eap-noob.arpa" and "@noob.eap.arpa" as synonyms.</t>
        <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that EAP-NOOB peers use "@noob.eap.arpa" first, and first and,
if that does not succeed, then they use "noob@eap-noob.arpa".</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>A

<!--[rfced] We had several questions related to the IANA
     Considerations in this document.

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.</t> 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">
        <name>.arpa updates</name> Updates</name>
        <t>There are two updates to the ".arpa" registry.</t> ".ARPA Zone Management" registry <xref target="ARPAREG"/> (detailed in Sections <xref target="deprecating-eap-noobarpa" format="counter"/> and <xref target="defining-the-eaparpa-domain" format="counter"/>).</t>
        <t>IANA is has also been instructed to refuse further allocation requests which that
are directly within the ".arpa" ".ARPA Zone Management" registry for any functionality related
to the EAP protocol. EAP.  Instead, allocations related to EAP are to
be made within the new "EAP Provisioning Identifiers" registry.</t> registry in the "Extensible Authentication Protocol (EAP) Registry" registry group (see <xref target="EAPREG"/>).</t>
        <section anchor="deprecating-eap-noobarpa">
          <name>Deprecating eap-noob.arpa</name>
          <t>IANA is instructed to update has updated the "eap-noob.arpa" entry in the ".ARPA Zone Management" registry <xref target="ARPAREG"/> as follows.</t> follows:</t>
          <t>The USAGE USAGE/REFERENCE field is has been updated to prefix the text with the word DEPRECATED.</t>
          <t>The REFERENCE field is updated (DEPRECATED) and to add a reference to THIS-DOCUMENT.</t> this document (RFC 9965).</t>
        </section>
        <section anchor="defining-the-eaparpa-domain">
          <name>Defining the eap.arpa. Domain</name>
          <t>IANA is instructed to update has updated the ".ARPA Zone Management" registry <xref target="ARPAREG"/> with to include
the following entry:</t>
          <t>DOMAIN</t>
          <ul empty="true">
            <li>
              <t>eap.arpa</t>
            </li>
          </ul>
          <t>USAGE</t>
          <ul empty="true">
            <li>
              <t>For

<dl spacing="compact" newline="false">
  <dt>DOMAIN:</dt><dd>eap.arpa</dd>
  <dt>USAGE/REFERENCE:</dt><dd>For provisioning within the Extensible Authentication Protocol framework.</t>
            </li>
          </ul>
          <t>REFERENCE</t>
          <ul empty="true">
            <li>
              <t>THIS-DOCUMENT</t>
            </li>
          </ul> framework.  RFC 9965</dd>
</dl>

          <t>IANA is instructed to update has updated the "Special-Use Domain Names" registry (see <xref target="SPECIAL-USE"/>) 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>
<dl spacing="compact" newline="false">
  <dt>Name:</dt><dd>eap.arpa.</dd>
  <dt>Reference:</dt> <dd>RFC 9965</dd>
</dl>
          <section anchor="domain-name-reservation-considerations">
            <name>Domain Name Reservation Considerations</name>
            <t>This section answers the questions which that are required by Section 5 of <xref target="RFC6761"/>. target="RFC6761" section="5"/>.  At a high level, these new domain names are used in certain situations in EAP.  The domain names are never seen by users, and they do not appear in any networking protocol other than EAP.</t>
            <ol spacing="normal" type="1"><li> type="1">
     <li>
                <t>Users:
User
Human users are not expected to recognize these names as special or use them differently from other domain names.  The use of these names in EAP is invisible to end users.</t>
              </li>
              <li>
                <t>Application Software:
EAP servers and clients are expected to make their software recognize these names as special and treat them differently.  This document discusses that behavior.
EAP peers should recognize these names as special, special and should refuse to allow users to enter them in any interface.
EAP servers and RADIUS servers should recognize the eap.arpa. domain as special, special and refuse to do dynamic discovery (<xref target="RFC7585"/>) for it.</t>
              </li>
              <li>
                <t>Name Resolution APIs and Libraries:
Writers of these APIs and libraries are not expected to recognize these names or treat them differently.</t>
              </li>
              <li>
                <t>Caching DNS Servers:
Writers of caching DNS servers are not expected to recognize these names or treat them differently.</t>
              </li>
              <li>
                <t>Authoritative DNS Servers:
Writers of authoritative DNS servers are not expected to recognize these names or treat them differently.</t>
              </li>
              <li>
                <t>DNS Server Operators:
These domain names have minimal impact on DNS server operators.  They should never be used in DNS, DNS or in any networking protocol outside of EAP.<br/>
Some EAP.</t>
<t>Some DNS servers may receive lookups for this domain, if EAP or RADIUS servers are configured to do dynamic discovery for realms as defined in <xref target="RFC7585"/>, and where those servers are not updated to ignore the ".arpa" domain.  When queried for the eap.arpa. domain, DNS servers SHOULD <bcp14>SHOULD</bcp14> return an NXDOMAIN error.<br/>
If error.</t>
<t>If they try to configure their authoritative DNS as authoritative for this reserved name, compliant name servers do not need to do anything special.  They can accept the domain or reject it.  Either behavior will have no impact on this specification.</t>
              </li>
              <li>
                <t>DNS Registries/Registrars:
DNS Registries/Registrars should deny requests to register this reserved domain name.</t>
              </li>
            </ol>
          </section>
        </section>
      </section>
      <section anchor="registry">
        <name>EAP Provisioning Identifiers Registry</name>
        <t>IANA is instructed to add has added the following new registry to the "Extensible Authentication Protocol (EAP) Registry" group.</t> registry group (see <xref target="EAPREG"/>).</t>
        <t>Assignments in this registry are done made via "Expert Review" as described in <xref target="RFC8126"/> Section 4.5. target="RFC8126" sectionFormat="comma" section="4.5"/>.  Guidelines for experts is are provided in <xref target="guidelines"/>.</t>
        <t>The contents of the registry are format is as follows.</t>
        <t>Title</t>
        <ul empty="true">
          <li>
            <t>EAP follows:</t>

<dl spacing="compact" newline="false">
  <dt>Title:</dt>
  <dd>EAP Provisioning Identifiers</t>
          </li>
        </ul>
        <t>Registration Procedure(s)</t>
        <ul empty="true">
          <li>
            <t>Expert review</t>
          </li>
        </ul>
        <t>Reference</t>
        <ul empty="true">
          <li>
            <t>THIS-DOCUMENT</t>
          </li>
        </ul>
        <t>Registry</t>
        <ul empty="true">
          <li>
            <t>NAI</t>
            <ul empty="true">
              <li>
                <t>The Identifiers</dd>
  <dt>Registration Procedure(s):</dt>
  <dd>Expert Review</dd>
  <dt>Reference:</dt>
  <dd>RFC 9965</dd>
   <dt>NAI:</dt>
  <dd>The Network Access Identifier in the format described in <xref target="RFC7542"/> format.</t>
              </li>
            </ul>
            <t>Method Type</t>
            <ul empty="true">
              <li>
                <t>The target="RFC7542"/>.</dd>
  <dt>Method-Type:</dt>
  <dd>The EAP method name, taken from the "Description" field of the EAP "Method Types" registry.</t>
              </li>
            </ul>
            <t>Reference</t>
            <ul empty="true">
              <li>
                <t>Reference registry (see <xref target="EAPREG"/>) .</dd>
  <dt>Reference:</dt>
  <dd>Reference where this identifier was defined.</t>
              </li>
            </ul>
          </li>
        </ul> defined.</dd>
  </dl>
        <section anchor="initial-values">
          <name>Initial Values</name>
          <t>The following table gives Values of the initial values for this table.</t> EAP Provisioning Identifiers Registry</name>
          <table>
            <name>Initial Values of the EAP Provisioning Identifiers Registry</name>
            <thead>
              <tr>
                <th align="left">NAI</th>
                <th align="left">Method-Type</th>
                <th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">@noob.eap.arpa</td>
                <td align="left">EAP-NOOB</td>
                <td align="left">
                  <xref target="RFC9140"/> and THIS-DOCUMENT</td> RFC 9965</td>
              </tr>
              <tr>
                <td align="left">portal@tls.eap.arpa</td>
                <td align="left">EAP-TLS</td>
                <td align="left">
                  <xref target="RFC9190"/> and THIS-DOCUMENT</td> RFC 9965</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
      <section anchor="guidelines">
        <name>Guidelines for Designated Experts</name>
        <t>The following text gives guidelines for Designated Experts designated experts who review
allocation requests for this the "EAP Provisioning Identifiers" registry.</t>
        <section anchor="nais">
          <name>NAIs</name>
          <t>The intent is for the NAI to describe both the EAP
Method Type,
Method-Type and the purpose of the provisining provisioning method.  A descriptive format allows administrators who are unfamiliar with a particular NAI to make reasonable deductions about the provisioning method being requested.  For
example, with an EAP Method Type "name", Method-Type "name" and a purpose "action", the
NAI SHOULD <bcp14>SHOULD</bcp14> be of the form "action@name.eap.arpa".</t>
          <t>The NAI MUST <bcp14>MUST</bcp14> satisfy the requirements of the format in <xref section="2.2" sectionFormat="comma" target="RFC7542"/>
format. target="RFC7542"/>.  The utf8-username portion MAY <bcp14>MAY</bcp14> be empty.  The utf8-username
portion MUST NOT <bcp14>MUST NOT</bcp14> be "anonymous".  The NAI MUST <bcp14>MUST</bcp14> be a subdomain within the eap.arpa realm.
NAIs with any "v." subdomain MUST NOT <bcp14>MUST NOT</bcp14> be registered, registered in order to
preserve the functionality of that subdomain.</t>
          <t>NAIs in the registry MUST NOT <bcp14>MUST NOT</bcp14> contain more than one subdomain.  NAIs
with a leading "v." subdomain MUST NOT <bcp14>MUST NOT</bcp14> be registered.  That subdomain
is reserved for vendor and SDO extensions.</t>
          <t>The subdomain of the NAI field should correspond to the EAP Method
Type Method-Type name.  Care should be taken so that the domain name conventions
specified in <xref target="STD13"/> are followed.</t>
          <t>The NAIs in this registry are case-insensitive.  While <xref target="RFC7542"/>
notes that similar identifiers of different case cases can be considered to
be different, for simplicity this registry requires that all entries
MUST
<bcp14>MUST</bcp14> be lowercase.</t> lowercase for simplicity.</t>
          <t>Identifiers MUST <bcp14>MUST</bcp14> be unique when compared in a case-insensitive
fashion.  While <xref target="RFC7542"/> notes that similar identifiers of
different case cases can be considered to be different, this registry is
made simpler by requiring case-insensitivity.</t>
          <t>Entries in the registry should be short.  NAIs defined here will
generally be sent in a RADIUS packet in the User-Name attribute
(<xref target="RFC2865"/> Section 5.1). target="RFC2865" sectionFormat="comma" section="5.1"/>).  That specification recommends that
implementations should support User-Names of at least 63 octets.  NAI
length considerations are further discussed in <xref target="RFC7542"/> Section
2.3, target="RFC7542" sectionFormat="comma" section="2.3"/>, and any allocations in this registry needs need to take those
limitations into consideration.</t>
          <t>Implementations are likely to support a total NAI length of 63 octets.
Lengths between 63 and 253 octets may work.  Lengths of 254 octets or
more will not work with RADIUS <xref target="RFC2865"/>.</t>
        </section>
      </section>
      <section anchor="method-type">
        <name>Method Type</name>
        <name>Method-Type</name>
        <t>Values in "Method Type" the "Method-Type" field of this registry MUST <bcp14>MUST</bcp14> be taken from the
IANA EAP Method Types
"Method Types" registry or else it MUST (see <xref target="EAPREG"/>); otherwise, a value <bcp14>MUST</bcp14> be an Expanded Type Type,
which usually indicates a vendor specific vendor-specific EAP method.</t>
        <t>The EAP Method Type MUST Method-Type <bcp14>MUST</bcp14> provide a Master Session Key (MSK) and an Extended MSK and EMSK (EMSK) as defined in
<xref target="RFC3748"/>.  Failure to provide these keys means that the method Method-Type will
not be usable within an authentication framework which that requires those
methods, such as with IEEE 802.1X.</t>
      </section>
      <section anchor="designated-experts">
        <name>Designated Experts</name>
        <t>The Designated Expert designated expert will post a request to the EMU EAP Method Update (EMU) WG mailing list
(or a successor designated by the Area Director) for comment and
review, including an Internet-Draft I-D or reference to an external
specification.  Before a period of 30 days has passed, the Designated
Expert designated
expert will either approve or deny the registration request and
publish a notice of the decision to the EAP Method Update (EMU) EMU WG mailing list or (or its
successor,
successor) as well as informing inform IANA.  A denial notice must be
justified by an explanation, and explanation; in the cases where it is possible,
concrete suggestions on how the request can be modified so as to
become acceptable should be provided.</t>
      </section>
      <section anchor="vendor-assignment">
        <name>Organization Self Assignment</name>
        <t>This
        <t>The "EAP Provisioning Identifiers" registry allows organizations to request allocations from this
registry, it, but explicit allocations are not always required.  Any NAI
defined in this registry also implicitly defines a subdomain "v.".
Organizations can self-allocate in this space, space under the "v."
subdomain, e.g. e.g., "local@example.com.v.tls.eap.arpa".</t>
        <t>The purpose of self-assigned realms is for testing, testing and for future
expansion.  There are currently no use-cases use cases being envisioned for
these realms, but we do not wish to forbid future expansion.</t>
        <t>An organization which that has registered a Fully Qualified Domain Name
(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
using a domain at some point.  This change is reflected in the DNS, DNS
but is unlikely to be reflected in shipped products which that use a
self-assigned realm.  There is no solution to this problem, problem other than
suggesting that organizations using self-assigned realms do not allow
their DNS registrations to expire.</t>
        <t>It
        <t>Therefore, it is therefore RECOMMENDED <bcp14>RECOMMENDED</bcp14> that organizations avoid the use of
self-assigned realms.  Organizations MAY <bcp14>MAY</bcp14> use self-assigned realms only
when no other alternative exists, exists and when the organization expects to
maintain operation for at least the lifetime of the devices which that use
these realms.</t>
      </section>
    </section>
    <section anchor="privacy-considerations">
      <name>Privacy Considerations</name>
      <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
specification, there is no privacy implication to exposing those names
within EAP.  The  In fact, the entire goal of this specification is in fact to make
those names public, public so that unknown (and private) parties can publicly
(and anonymously) declare what kind of network access they desire.</t>
      <t>However, there are many additional privacy concerns around this
specification.  Most EAP traffic is sent over RADIUS <xref target="RFC2865"/>.  The
RADIUS Access-Request packets typically contain large amounts of
information such as MAC Media Access Control (MAC) addresses, device location, etc.</t>
      <t>This specification does not change RADIUS or EAP, and EAP and, as such such, does not
change which information is publicly available, available or is kept private.
Those issues are dealt with in other specifications, such as
<xref target="I-D.ietf-radext-deprecating-radius"/>.</t>
      <t>However, this specification can increase privacy by allowing devices
to anonymously obtain network access, access and then securely obtain
credentials.</t>
      <t>The NAIs used here are contained in a public registry, and therefore registry; therefore, they
do not have to follow the username privacy recommendations of
<xref section="2.4" sectionFormat="comma" target="RFC7542"/>.  However, there may be other personally
identifying information contained in EAP or AAA packets.  This
situation is no different from normal EAP authentication, and thus authentication; thus, it
has no additional positive or negative implications for privacy.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This specification defines a framework which that permits unknown,
anonymous, and unauthenticated devices to request and to obtain
network access.  As such, it is critical that network operators
provide limited access to those devices.</t>
      <t>Future specifications which that define an NAI within this registry, should
give detailed descriptions of what kind of network access is to be
provided.</t>
      <section anchor="on-path-attackers-and-impersonation">
        <name>On-Path Attackers and Impersonation</name>
        <t>In most EAP use-cases, use cases, the server identity is validated (usually
through a certificate), certificate) or the EAP method allows the TLS tunnel to be
cryptographically bound to the inner application data.  For the
methods outlined here, the use of public credentials, credentials and/or skipping
server validation allows "on-path" attacks to succeed where they would
normally fail</t> fail.</t>
        <t>EAP peers and servers MUST <bcp14>MUST</bcp14> assume that all data sent over an EAP
session is visible to attackers, attackers and can be modified by them.</t>
        <t>The methods defined here MUST <bcp14>MUST</bcp14> only be used to bootstrap initial
network access.  Once a device has been provisioned, it gains network
access via the provisioned credentials, credentials and any network access
policies can be applied.</t>
      </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">
        <name>Provisioning is Unauthenticated</name>
        <t>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.</t>
        <t><xref target="eap-servers"/> describes a number of methods which that can be
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">
          <li>
            <t>allow only traffic which that is needed for the current provisioning
method.  All other traffic should be blocked.  Most notable, DNS has
been used to exfiltrate network traffic, so DNS recursive resolvers SHOULD NOT <bcp14>SHOULD NOT</bcp14>
be made available on the provisioning network.</t>
          </li>
          <li>
            <t>limit the services available on the provisioning network to only
those services which that are needed for provisioning.</t>
          </li>
          <li>
            <t>limit the number of devices which that can access the provisioning
network at the same time.</t>
          </li>
          <li>
            <t>for any one device, rate limit its access the provisioning network.</t>
          </li>
          <li>
            <t>for a device which that has accessed the provisioning network, limit the
total amount of time which that it is allowed to remain on the network</t> network.</t>
          </li>
          <li>
            <t>for a device which that has accessed the provisioning network, limit the
total amount of data which that it is allowed to transfer through the network.</t>
          </li>
        </ul>
      </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>
  <back>
    <displayreference target="I-D.ietf-radext-deprecating-radius" to="INSECURE-RADIUS"></displayreference>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <referencegroup anchor="STD13" target="https://www.rfc-editor.org/info/std13">
          <reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034">
            <front>
              <title>Domain names - concepts and facilities</title>
              <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
              <date month="November" year="1987"/>
              <abstract>
                <t>This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their 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 them.</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/rfc1035">
            <front>
              <title>Domain names - implementation and specification</title>
              <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
              <date month="November" year="1987"/>
              <abstract>
                <t>This RFC is the revised specification of the protocol and format 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>
          <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
          <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
        </referencegroup>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <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 (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. 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. [STANDARDS-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 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.</t>
              <t>This document obsoletes RFC 2716. A summary of the changes between 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 other'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 international 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 constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations 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 describing the conditions under which new values should be assigned, as well as when 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 Considerations 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 5226.</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 for multiple authentication methods. This document defines the EAP-NOOB authentication 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 peer device and authentication server to authenticate the in-band key exchange. The device must have a nonnetwork input or output interface, such as a display, microphone, speaker, or blinking light, that can send or receive dynamically generated 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</title>
            <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 signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, 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>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3748.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5216.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7542.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9140.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="HOTSPOT" target="https://www.wi-fi.org/discover-wi-fi/passpoint">
          <front>
            <title>Passpoint</title>
            <author initials="W.-F." surname="Alliance" fullname="Wi-Fi Alliance">
              <organization/>
            <author>
              <organization>Wi-Fi Alliance</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="RFC2865">
          <front>
            <title>Remote Authentication Dial In User Service (RADIUS)</title>
            <author fullname="C. Rigney" initials="C." surname="Rigney"/>
            <author fullname="S. Willens" initials="S." surname="Willens"/>
            <author fullname="A. Rubens" initials="A." surname="Rubens"/>
            <author fullname="W. Simpson" initials="W." surname="Simpson"/>
            <date month="June" year="2000"/>
            <abstract>
              <t>This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]</t>
            </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</title>
            <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 Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2865.xml"/>

<!--[rfced] We note that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) 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 with TLS 1.3</title>
            <author fullname="J. Preuß Mattsson" initials="J." surname="Preuß Mattsson"/>
            <author fullname="M. Sethi" initials="M." surname="Sethi"/>
            <date month="February" year="2022"/>
            <abstract>
              <t>The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and 7170 has been obsoleted by mandating use of revocation checking when compared RFC 9930.  We
     have updated 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 underlying TLS version used). This document updates RFC 5216.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9190"/>
          <seriesInfo name="DOI" value="10.17487/RFC9190"/>
        </reference> latter.  Please let us know any
     objections. -->

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9930.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8952.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9190.xml"/>
        <reference anchor="ARPAREG" target="https://www.iana.org/domains/arpa">
          <front>
            <title>.ARPA Zone Management</title>
            <author initials="" surname="IANA" fullname="IANA">
              <organization/>
            <author>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>

        <reference anchor="EAPREG" target="https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml"> target="https://www.iana.org/assignments/eap-numbers">
          <front>
            <title>Extensible Authentication Protocol (EAP) Registry</title>
            <author initials="" surname="IANA" fullname="IANA">
              <organization/>
            <author>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>

                <reference anchor="CAB" target="https://cabforum.org/"> anchor="SPECIAL-USE" target="https://www.iana.org/assignments/special-use-domain-names">
          <front>
            <title>CA/Browser Forum</title>
            <author initials="C." surname="Forum" fullname="CA/Browser Forum">
              <organization/>
            <title>Special-Use Domain Names</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>

        <reference anchor="RFC7585"> anchor="CAB" target="https://cabforum.org/">
          <front>
            <title>Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on 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 servers for a given realm. It is used in conjunction with either RADIUS over Transport Layer Security (RADIUS/TLS) or RADIUS over Datagram Transport Layer Security (RADIUS/DTLS).</t>
            </abstract>
            <title>CA/Browser Forum</title>
            <author>
              <organization>CA/Browser Forum</organization>
            </author>
          </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="Harkins"/>
            <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 profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7585.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7030.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9810.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5931.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6761.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>

    <section anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t><contact fullname="Mohit Sethi"/> provided valuable insight that need to acquire client certificates
      using subdomains was better and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by more informative than 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 Management 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 original
      method, which used only the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides interactions between 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 containing a Key Encapsulation Mechanism (KEM) public key and uses EnvelopedData instead utf8-username portion of EncryptedValue. This document also includes the updates specified in Section 2 and Appendix A.2 of RFC 9480.</t>
              <t>This NAI.</t>
      <t>The document obsoletes RFC 4210, and together was further improved with RFC 9811, it also obsoletes RFC 9480. Appendix F of this document updates Section 9 of RFC 5912.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9810"/>
          <seriesInfo name="DOI" value="10.17487/RFC9810"/>
        </reference>
        <reference anchor="RFC5931">
          <front>
            <title>Extensible Authentication Protocol (EAP) Authentication Using 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 reviews from some set of possible passwords, like a dictionary, which is available to an attacker. The underlying key exchange is resistant to active attack, passive attack, and dictionary attack. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5931"/>
          <seriesInfo name="DOI" value="10.17487/RFC5931"/>
        </reference>
        <reference anchor="RFC6761">
          <front>
            <title>Special-Use Domain Names</title>
            <author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
            <author fullname="M. Krochmal" initials="M." surname="Krochmal"/>
            <date month="February" year="2013"/>
            <abstract>
              <t>This document describes what it means <contact
      fullname="Ignes Robles"/> and <contact fullname="Ben Kaduk"/>.</t>
    </section>

<!--[rfced] We had the following questions related to say terminology use
     throughout the document:

a) We see that a Domain Name (DNS name) is reserved for special use, when reserving such a name eap.arpa. domain is appropriate, and used consistently throughout.

However, we see the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it following with entries for some of the already established special regard to .arpa:

"arpa" domain names.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6761"/>
          <seriesInfo name="DOI" value="10.17487/RFC6761"/>
        </reference>
        <reference anchor="I-D.ietf-radext-deprecating-radius">
          <front>
            <title>Deprecating Insecure Practices in RADIUS</title>
            <author fullname="Alan DeKok" initials="A." surname="DeKok">
              <organization>InkBridge Networks</organization>
            </author>
            <date day="27" month="August" year="2025"/>
            <abstract>
              <t>   RADIUS crypto-agility was first mandated as future work by RFC 6421.
   The outcome of that work was the publication of RADIUS over TLS (RFC
   6614)
".arpa" domain

Should these be made consistent between themselves or more similar to
eap.arpa. (i.e., no double quotes 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 trailing period)?

Further, please review the previous UDP (RFC 2865) and TCP (RFC 6613)
   transports.  With that knowledge, following with regard to the continued use of insecure
   transports for RADIUS has serious and negative implications for
   privacy and security.

   The publication trailing period:

Original:
...the NAI SHOULD be of the "BlastRADIUS" exploit has also shown form "action@name.eap.arpa".
-->

<!--[rfced] FYI - We see that
   RADIUS security needs to be updated.  It an extra space is no longer acceptable for
   RADIUS being inserted after
     "eap.arp." in some places (e.g., titles).  We will dig into to rely on MD5 for security.  It
     see if there is no longer acceptable some formatting we can implement to
   send device or location information in clear text across remove 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>
          <seriesInfo name="Internet-Draft" value="draft-ietf-radext-deprecating-radius-07"/>
        </reference>
      </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=
     added space. -->

  </back>
</rfc>