<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="utf-8"?>

<!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.4 (Ruby 2.6.8) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-radext-radiusv11-11" number="9765" category="exp" submissionType="IETF" updates="2865, 2866, 5176, 6613, 6614, 7360" obsoletes="" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.13.0 --> version="3" xml:lang="en">

  <front>
    <title abbrev="RADIUSv11">RADIUS/1.1, abbrev="RADIUS/1.1">RADIUS/1.1: Leveraging ALPN Application-Layer Protocol Negotiation (ALPN) to remove Remove MD5</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-radext-radiusv11-11"/> name="RFC" value="9765"/>
    <author initials="A." surname="DeKok" fullname="Alan DeKok">
      <organization>FreeRADIUS</organization>
      <address>
        <email>aland@freeradius.org</email>
      </address>
    </author>
    <date year="2024" month="October" day="18"/>
    <area>Internet</area>
    <workgroup>RADEXT Working Group</workgroup>
    <keyword>Internet-Draft</keyword> year="2025" month="April"/>
    <area>SEC</area>
    <workgroup>radext</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 75?>
      <t>This document defines Application-Layer Protocol Negotiation Extensions (ALPN)
      extensions for use with RADIUS/TLS and RADIUS/DTLS.  These extensions
      permit the negotiation of an application protocol variant of RADIUS, RADIUS
      called "RADIUS/1.1".  No changes are made to RADIUS/UDP or RADIUS/TCP.
      The extensions allow the negotiation of a transport profile where the
      RADIUS shared secret is no longer used, and all MD5-based packet
      authentication and attribute obfuscation methods are removed.</t>

      <t>This document updates RFC2865, RFC2866, RFC5176, RFC6613, RFC6614, RFCs 2865, 2866, 5176, 6613, 6614, and RFC 7360.</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-radext-radiusv11/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        RADEXT Working Group mailing list (<eref target="mailto:radext@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/radext/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/radext/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/radext-wg/draft-ietf-radext-radiusv11.git"/>.</t>
    </note>

  </front>
  <middle>
    <?line 81?>

<section anchor="introduction">
      <name>Introduction</name>

      <t>The RADIUS protocol <xref target="RFC2865"/> uses MD5 <xref
      target="RFC1321"/> to authenticate packets, packets and to obfuscate certain
      attributes.  Additional transport protocols were defined for TCP (<xref target="RFC6613"/>), <xref
      target="RFC6613"/>, TLS (<xref target="RFC6614"/>), <xref target="RFC6614"/>, and DTLS (<xref target="RFC7360"/>). <xref
      target="RFC7360"/>.  However, those transport protocols still use MD5
      to authenticate individual packets.  That is, the shared secret was used
      along with MD5, even when the RADIUS packets were being transported in
      (D)TLS.  At the time, the consensus of the RADEXT working group Working Group was that
      this continued use of MD5 was acceptable.  TLS was seen as a simple
      "wrapper" around RADIUS, while using a fixed shared secret.  The
      intention at the time was to allow the use of (D)TLS while making
      essentially no changes to the basic RADIUS encoding, decoding,
      authentication, and packet validation.</t>

      <t>Issues of MD5 security have been known for decades, most most notably in
      <xref target="RFC6151"/>, target="RFC6151"/> and in <xref section="3" sectionFormat="comma" sectionFormat="of"
      target="RFC6421"/>, among others.  The reliance on MD5 for security
      makes it impossible to use RADIUS in secure systems which that forbid the use
      of digest algorithms with known vunerabilities. vulnerabilities.  For example, FIPS-140 FIPS 140
      forbids systems from relying on insecure cryptographic methods for security.</t>
      security <xref target="FIPS-140-3"/>.</t>

     <t>While the use of MD5 in RADIUS/TLS is has not known been proven to be insecure,
     it can has not been proven to be secure.  This gap means that it is
     difficult for individual organizations to perform cryprographic analyses of use RADIUS in organizations that require the protocols use of systems
     that they use.  It is much simpler and more practical have proven security.  Those organizations tend to simply verify that there ban the
     use of insecure digests such as MD5 are not used anywhere in entirely, even if the system.  Then by definition, use of MD5 has
     no known security impact.  While the systems are resulting system might still not be
     secure, it at least does not contain any known to be insecure.</t> insecurities.</t>

      <t>In addition, the use of MD5 in RADIUS/TLS and RADIUS/DLTS adds no
      security or privacy over that provided by TLS.  In hindsight, the
      decision of the RADEXT working group Working Group to retain MD5 for historic
      RADIUS/TLS was likely wrong.  It was an easy decision to make in the
      short term, but it has caused ongoing problems which that this document
      addresses.  The author of this document played a part in that original
      decision, which is now be being corrected by this document.</t>

      <t>This document defines an Application-Layer Protocol Negotiation
      (ALPN) <xref target="RFC7301"/> extension for RADIUS over (D)TLS which that
      removes the need to use MD5 for (D)TLS, which we call RADIUS/1.1.  This
      specification makes no changes to UDP or TCP transport.  The RADIUS/1.1
      protocol can best be best understood as a transport profile for RADIUS over
      TLS, rather than a whole-sale wholesale revision of the RADIUS protocol.</t>

      <t>Systems which that implement this transport profile can be more easily
      verified to be FIPS-140 FIPS 140 compliant.  A preliminary implementation has
      shown that only minor code changes are required to support RADIUS/1.1 on
      top of an existing RADIUS/TLS server implementation, which are:</t> implementation. These include:</t>

      <ul spacing="normal">
        <li>A method to set the list of supported ALPN protocols before the TLS handshake starts</li>
        <li>After the TLS handshake has completed, a starts.</li>
        <li>A method to query if ALPN has chosen a protocol, and protocol (and if yes, which
        protocol was chosen.</li> chosen) after the TLS handshake has completed.</li>
        <li>Changes to the packet encoder and decoder, so that the individual
        packets are not authenticated, and no attribute is encoded with the
        historic obfuscation methods.</li>
      </ul>

      <t>That is, the bulk of the ALPN protocol can be left to the underlying
      TLS implementation.  This document discusses the ALPN exchange in detail
      in order to give simplified descriptions for the reader, and so that the
      reader does not have to read or understand all of <xref
      target="RFC7301"/>.</t>

      <t>The detailed list of changes from historic TLS-based transports to
      RADIUS/1.1 is as follows:</t>

      <ul spacing="normal">
        <li>ALPN is used for negotiation of this extension,</li> extension.</li>
        <li>TLS 1.3 or later is required,</li> required.</li>
        <li>All uses of the RADIUS shared secret have been removed,</li> removed.</li>
        <li>The now-unused now unused Request and Response Authenticator fields have been
        repurposed to carry an opaque Token which that identifies requests and responses,</li>
        responses.</li>
        <li>The functionality of the Identifier field has been replaced by the
        Token field, and the space previously taken by the Identifier field is
        now reserved and unused,</li> unused.</li>
        <li>The Message-Authenticator attribute (<xref section="3.2"
        sectionFormat="comma" target="RFC3579"/>) is not sent in any packet,
        and if received is ignored,</li> ignored if received.</li>
        <li>Attributes such as User-Password, Tunnel-Password, and MS-MPPE keys are sent encoded as "text" (<xref section="3.4"
        sectionFormat="comma" target="RFC8044"/>) or "octets" (<xref
        section="3.5" sectionFormat="comma" target="RFC8044"/>), without the
        previous MD5-based obfuscation.  This obfuscation is no longer
        necessary, as the data is secured and kept private through the use of TLS,</li>
        TLS.</li>
        <li>The conclusion of the efforts stemming from <xref
        target="RFC6421"/> is that crypto-agility in RADIUS is best done via a
        TLS wrapper, and not by extending the RADIUS protocol.</li>
        <li>
          <xref target="RFC5176"/> is updated to allow the Error-Cause
          attribute to appear in Access-Reject packets.</li>
      </ul>

      <t>The following items are left unchanged from traditional historic TLS-based
      transports for RADIUS:</t>

      <ul spacing="normal">
        <li>The RADIUS packet header is the same size, and the Code and Length
        fields (<xref section="3" sectionFormat="comma" target="RFC2865"/>)
        have the same meaning as before,</li> before.</li>

        <li>The default 4K 4096-octet packet size from <xref target="RFC2865"
        sectionFormat="comma" section="3"/> is unchanged, although <xref
        target="RFC7930"/> can still be leveraged to use larger packets,</li> packets.</li>

        <li>All attributes which that have simple encodings (that is, attributes which
        that do not use MD5 obfuscation) have the same encoding and meaning
        as before,</li> before.</li>

        <li>As this extension is a transport profile for one "hop" (client to server
        (client-to-server connection), it does not impact any other connection
        used by a client or server.  The only systems which that are aware that this
        transport profile is in use are the client and server who have
        negotiated the use of this extension on a particular shared connection,</li>
        connection.</li>

        <li>This extension uses the same ports (2083/tcp and 2083/udp) which that
        are defined for RADIUS/TLS <xref target="RFC6614"/> and RADIUS/DTLS
        <xref target="RFC7360"/>.</li>
      </ul>

      <t>A major benefit of this extension is that a server which that implements it
      can also be more easily verified for FIPS-140 FIPS 140 compliance.  That is, a
      server can remove all uses of MD5, which means that those algorithms are
      provably not used for security purposes.  In that case, however, the
      server will not support CHAP, the Challenge Handshake Authentication Protocol
      (CHAP) or any authentication method which that uses MD5.  The choice of which
      authentication method to accept is always left to the server.  This
      specification does not change any authentication method carried in
      RADIUS, and does not mandate (or forbid) the use of any authentication
      method for any system.</t>

      <t>As for proxies, there was never a requirement that proxies implement
      CHAP or MS-CHAP Microsoft CHAP (MS-CHAP) authentication.  So far as a proxy is concerned, attributes relating to
      CHAP and MS-CHAP are simply opaque data that is transported unchanged to
      the next hop.  It  Therefore, it is therefore possible for a FIPS-140 FIPS 140 compliant proxy
      to transport authentication methods which that depend on MD5, so long as that
      data is forwarded to a server which that supports those methods.</t>

      <t>We reiterate that the decision to support (or not) not support) any authentication
      method is entirely site local, and is not a requirement of this
      specification.  The contents or meaning of any RADIUS attribute other
      than the Message-Authenticator (and similar attributes) are not modified.
      The only change to the Message-Authenticator attribute is that it is no
      longer used in RADIUS/1.1.</t>

      <t>Unless otherwise described in this document, all RADIUS requirements
      apply to this extension.  That is, this specification defines a
      transport profile for RADIUS.  It is not an entirely new protocol, and
      it defines only minor changes to the existing RADIUS protocol.  It does
      not change the RADIUS packet format, attribute format, etc.  This
      specification is compatible with all RADIUS attributes, attributes of the past, present,
      and future.</t>

      <t>This specification is compatible with existing implementations of
      RADIUS/TLS and RADIUS/DTLS.  Systems which that implement this standard specification can
      fall back to historic RADIUS/TLS if no ALPN signaling is performed, and
      the local configuration permits such fallback.</t>

      <t>This specification is compatible with all existing RADIUS
      specifications.  There is no need for any RADIUS specification to
      mention this transport profile by name, name or to make provisions for this
      specification.  This document defines how to transform RADIUS into
      RADIUS/1.1, and no further discussion of that transformation is
      necessary.</t>

      <t>We note that this document makes no changes to previous RADIUS
      specifications.  Existing RADIUS implementations can continue to be used
      without modification.  Where previous specifications are explicitly
      mentioned and updated, those updates or changes apply only when the
      RADIUS/1.1 transport profile is being used.</t>

      <t>In short, when negotiated on a connection, the RADIUS/1.1 transport
      profile permits implementations to avoid MD5 when authenticating packets,
      packets or when obfuscating certain attributes.</t>
    </section>

    <section anchor="terminology">
      <name>Terminology</name>
      <t>The
        <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&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
<?line -6?>
        </t>

      <t>The following list describes the terminology and abbreviations which that are used in this document.</t>
      <ul spacing="normal">
        <li>ALPN</li>
      </ul>
      <ul empty="true">
        <li>
          <t>Application-Layer

<dl spacing="normal" newline="true">
        <dt>ALPN</dt>
        <dd>Application-Layer Protocol Negotiation, as Negotiation (as defined in <xref target="RFC7301"/>.</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>RADIUS</li>
      </ul>
      <ul empty="true">
        <li>
          <t>The Remote target="RFC7301"/>).</dd>

        <dt>RADIUS</dt>
        <dd>
	  <t>Remote Authentication Dial-In User Service protocol, as (as defined in <xref target="RFC2865"/>, <xref target="RFC2866"/>, and
	  <xref target="RFC5176"/> target="RFC5176"/>, among others.</t> others).</t>
          <t>While this protocol can be viewed as "RADIUS/1.0", for simplicity
          and historical compatibility, we keep the name "RADIUS".</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>RADIUS/UDP</li>
      </ul>
      <ul empty="true">
        <li>
          <t>RADIUS
        </dd>

        <dt>RADIUS/UDP</dt>
          <dd>RADIUS over the User Datagram Protocol (see <xref target="RFC2865"/>,
          <xref target="RFC2866"/>, and <xref target="RFC5176"/>, among others.</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>RADIUS/TCP</li>
      </ul>
      <ul empty="true">
        <li>
          <t>RADIUS others).</dd>

        <dt>RADIUS/TCP</dt>
          <dd>RADIUS over the Transmission Control Protocol <xref target="RFC6613"/>.</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>RADIUS/TLS</li>
      </ul>
      <ul empty="true">
        <li>
          <t>RADIUS target="RFC6613"/>.</dd>

        <dt>RADIUS/TLS</dt>
          <dd>RADIUS over the Transport Layer Security protocol <xref target="RFC6614"/>.</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>RADIUS/DTLS</li>
      </ul>
      <ul empty="true">
        <li>
          <t>RADIUS target="RFC6614"/>.</dd>

        <dt>RADIUS/DTLS</dt>
          <dd>RADIUS over the Datagram Transport Layer Security protocol <xref target="RFC7360"/>.</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>RADIUS target="RFC7360"/>.</dd>

        <dt>RADIUS over TLS</li>
      </ul>
      <ul empty="true">
        <li>
          <t>Any TLS</dt>
          <dd>Refers to any RADIUS packets transported over TLS or DTLS.  This
          terminology is used instead of alternatives such as "RADIUS/(D)TLS", "RADIUS/(D)TLS"
          or "either RADIUS/TLS or RADIUS/DTLS".  This term is generally used
          when referring to TLS-layer requirements for RADIUS packet transport.</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>historic RADIUS/TLS</li>
      </ul>
      <ul empty="true">
        <li>
          <t>RADIUS
          transport.</dd>

        <dt>historic RADIUS/TLS</dt>
          <dd>Refers to RADIUS over (D)TLS as (as defined in <xref target="RFC6614"/> and
          <xref target="RFC7360"/>. target="RFC7360"/>).  This term does not include the protocol
          defined in this specification.</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>RADIUS/1.1</li>
      </ul>
      <ul empty="true">
        <li>
          <t>The specification.</dd>

        <dt>RADIUS/1.1</dt>
          <dd>
	    <t>RADIUS version 1.1, i.e.,
	    the transport profile defined in this document, which stands for "RADIUS version 1.1". document.  We use
	    RADIUS/1.1 to refer interchangeably to TLS and DTLS
	    transport.</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>TLS</li>
      </ul>
      <ul empty="true">
        <li>
          <t>The Transport
	  </dd>

        <dt>TLS</dt>
          <dd>
	    <t>Transport Layer Security protocol.  Generally Security.
	    Generally, when we refer to TLS in this document, we are
	    referring interchangeably to TLS or DTLS transport.</t>
        </li>
      </ul>
	  </dd>
      </dl>
    </section>

    <section anchor="the-radius11-transport-profile-for-radius">
      <name>The RADIUS/1.1 Transport profile Profile for RADIUS</name>
      <t>This section describes the ALPN transport profile in detail.  It
      first gives the name used for ALPN, and then describes how ALPN is
      configured and negotiated by the client and server.  It then concludes by
      discussing TLS issues such as what to do for ALPN during session
      resumption.</t>

      <section anchor="alpn-name-for-radius11">
        <name>ALPN Name for RADIUS/1.1</name>

        <t>The ALPN name defined for RADIUS/1.1 is as follows:</t>
        <ul empty="true">
          <li>
            <t>"radius/1.1"</t>
            <ul empty="true">
              <li>
                <t>The

        <dl spacing="normal" newline="true">
            <dt>"radius/1.1"</dt>
            <dd>The protocol defined by this specification.</t>
              </li>
            </ul>
          </li>
        </ul> specification.</dd>
        </dl>

        <t>Where ALPN is not configured or is not received in a TLS
        connection, systems supporting ALPN MUST NOT <bcp14>MUST NOT</bcp14> use
        RADIUS/1.1.</t>

        <t>Where ALPN is configured, the client signals support by sending
        ALPN strings listing which protocols it supports.  The server can
        accept one of these proposals and reply with a matching ALPN string,
        or reject this proposal, proposal and not reply with any ALPN string.  A full walk-through
        walkthrough of the protocol negotiation is given below.</t>

        <t>Implementations MUST <bcp14>MUST</bcp14> signal ALPN "radius/1.1" in
        order for it to be used in a connection.</t>

        <t>The next step in defining RADIUS/1.1 is to review how ALPN
        works.</t>
      </section>

      <section anchor="operation-of-alpn">
        <name>Operation of ALPN</name>

        <t>In order to provide a high-level description of ALPN for readers
        who are not familiar with the details of <xref target="RFC7301"/>, we
        provide a brief overview here.</t>

        <t>Once a system has been configured to support ALPN, it is negotiated
        on a per-connection basis as per <xref target="RFC7301"/>.  The
        negotiation proceeds as follows:</t>
        <t>1) The

	<ol spacing="normal" type="%d)">
          <li>The client sends an ALPN extension in the ClientHello.  This
          extension lists one or more application protocols by name.  These
          names are the protocols which that the client is claiming to support.</t>
        <t>2) The support.</li>
          <li>
	    <t>The server receives the extension, extension and validates the
	    application protocol name(s) against the list it has
	    configured.</t>
        <ul empty="true">
          <li>
            <t>If the server finds no acceptable common protocols (ALPN or
            otherwise), it closes the connection.</t>
          </li>
        </ul>
        <t>3) Otherwise,
          <li>
	    <t>Otherwise, the server returns a ServerHello with either no ALPN extension,
	    extension or an ALPN extension containing only one named
	    application protocol, which needs to be one of the names proposed
	    by the client.</t>
        <ul empty="true">
          <li>
            <t>If the client did not signal ALPN, or the server does not
            accept the ALPN proposal, the server does not reply with any ALPN
            name.</t>
          </li>
        </ul>
        <t>4) The
          <li>
	    <t>The client receives the ServerHello, validates the received
	    application protocol (if any) against the name(s) it sent, and
	    records which application protocol was chosen.</t>
        <ul empty="true">
          <li>
            <t>This check is necessary in order for the client to both know
            which protocol the server has selected, and to validate that the
            protocol sent by the server is one which that is acceptable to the
            client.</t>
          </li>
        </ul>
        </ol>
        <t>The next step in defining RADIUS/1.1 is to define how ALPN is
        configured on the client and server, server and to give more detailed
        requirements on its configuration and operation.</t>
      </section>
      <section anchor="configuration-of-alpn-for-radius11">
        <name>Configuration of ALPN for RADIUS/1.1</name>
        <t>Clients or servers supporting this specification can do so by
        extending their TLS configuration through the addition of a new
        configuration variable, called "Version" here.  The exact name given
        below does not need to be used, but it is RECOMMENDED <bcp14>RECOMMENDED</bcp14>
        that administrative interfaces or programming interfaces use a similar
        name in order to provide consistent terminology.  This variable
        controls how the implementation signals use of this protocol via
        ALPN.</t>

        <t>When set, this variable should contain the list of permitted RADIUS
        versions as numbers, e.g. e.g., "1.0" or "1.1".  The implementation may
        allow multiple values in one variable, or allow multiple variables, or
        instead use two configuration configurations for the "minimum" and "maximum" allowed
        versions.  We assume here that there is one variable, which can
        contain either no value, value or else a list of one or more versions which that the
        current implementation supports.  In this specification, the possible
        values, ALPN strings, and corresponding interpretations are:</t>
        <artwork><![CDATA[
Value       |   ALPN String(s)       | Interpretation
------------------------------------------------------
unset       |                        | no

	<table anchor="alpn-configuration-for-radius11" align="center">
	  <name></name>
	  <thead>
	    <tr>
	      <th>Value</th>
	      <th>ALPN String(s)</th>
	      <th>Interpretation</th>
	    </tr>
	  </thead>
	  <tbody>
	    <tr>
	      <td>unset</td>
	      <td></td>
	      <td>no ALPN strings are sent.
1.0         | radius/1.0             | require sent</td>
	    </tr>
	    <tr>
	      <td>1.0</td>
              <td>radius/1.0</td>
              <td>require historic RADIUS/TLS
1.0, 1.1    | radius/1.0, radius/1.1 | allow RADIUS/TLS</td>
	    </tr>
	    <tr>
	      <td>1.0, 1.1</td>
	      <td>radius/1.0, radius/1.1</td>
	      <td>allow either historic
            |                        | RADIUS/TLS or RADIUS/1.1.
1.1         | radius/1.1             | require RADIUS/1.1.
]]></artwork> RADIUS/1.1</td>
	    </tr>
	    <tr>
	      <td>1.1</td>
              <td>radius/1.1</td>
              <td>require RADIUS/1.1</td>
	    </tr>
	  </tbody>
	</table>

        <t>This configuration is also extensible to future RADIUS versions if
        that extension becomes necessary.  New values and ALPN names can
        simply be added to the list.  Implementations can then negotiate the
        highest version which that is supported by both client and server.</t>

        <t>Implementations SHOULD <bcp14>SHOULD</bcp14> support both historic
        RADIUS/TLS and RADIUS/1.1.  Such implementations MUST <bcp14>MUST</bcp14>
        set the default value for this configuration variable to "1.0, 1.1".
        This setting ensures that both versions of RADIUS can be
        negotiated.</t>

        <t>Implementations MAY <bcp14>MAY</bcp14> support only RADIUS/1.1.  In which case
        this case, the default value for this configuration variable MUST
        <bcp14>MUST</bcp14> be "1.1".  This behavior is NOT RECOMMENDED, <bcp14>NOT
        RECOMMENDED</bcp14>, as it is incompatible with historic RADIUS/TLS.
        This behavior can only be a reasonable default when all (or nearly
        all) RADIUS clients have been updated to support RADIUS/1.1.</t>

        <t>A more detailed definition of the variable and the meaning of the
        values is given below.</t>
        <t>Configuration

<!-- [rfced] Section 3.3: Please review the following questions regarding the
list that appears in this section.

a) Is this list intended to directly correspond to the preceding table
(now Table 1)? If so, please let us know if it should be updated, as
"Configuration Variable Name</t>
        <ul empty="true">
          <li>
            <t>Version</t>
          </li>
        </ul>
        <t>Values</t>
        <ul empty="true">
          <li>
            <t>When Name" does not appear in the table.

Original:
   A more detailed definition of the variable and the meaning of the
   values is given below.

   Configuration Variable Name

      Version

c) Please clarify this usage of either / or / or else. Are there three
alternatives? (Also, seemingly "with" was meant to be "which"; we changed it
to "that".)

Original:
         The client will receive either no ALPN response from the server, or
         an ALPN response of one version string with MUST match one of the
         strings it sent, or else a TLS alert of "no_application_protocol"
         (120).

Option A ("either X, Y, or Z"):
         The client will receive either no ALPN response from the
         server. an ALPN response of one version string that MUST
         match one of the strings it sent, or a TLS alert of
         "no_application_protocol" (120).

Option B ("X, Y, or Z"):
         The client will receive no ALPN response from the server, an
         ALPN response of one version string that MUST match one of
         the strings it sent, or a TLS alert of
         "no_application_protocol" (120).
-->

<dl newline="true" spacing="normal">
  <dt>Configuration Variable Name</dt>
  <dd>Version</dd>
</dl>

<dl newline="true" spacing="normal">
  <dt>For "Value":</dt>
  <dd>
    <ol type="A">
      <li>
        <t>If unset, ALPN is not used.</t>
        <t>Any connection MUST <bcp14>MUST</bcp14> use historic RADIUS/TLS.</t>
        <t>This variable is included here only for logical
        completeness. Implementations of this specification SHOULD
        <bcp14>SHOULD</bcp14> be configured to always send one or more ALPN
        strings. This data signals that the implementation is capable of
        performing ALPN negotiation, even if it is not currently configured to
        use RADIUS/1.1</t>
            <ul empty="true">
              <li>
                <t>Client Behavior</t>
                <ul empty="true">
                  <li>
                    <t>The RADIUS/1.1.</t>

        <dl newline="true" spacing="normal">
          <dt>Client Behavior</dt>
          <dd>The client MUST NOT <bcp14>MUST NOT</bcp14> send any protocol name via ALPN.</t>
                  </li>
                </ul>
                <t>Server Behavior</t>
                <ul empty="true">
                  <li> ALPN.</dd>

          <dt>Server Behavior</dt>
          <dd>
            <t>The server MUST NOT <bcp14>MUST NOT</bcp14> signal any protocol name via
            ALPN.</t>
            <t>If the server receives an ALPN name from the client, it MUST NOT
            <bcp14>MUST NOT</bcp14> close the connection. Instead, it simply
            does not reply with ALPN, ALPN and finishes the TLS connection setup as
            defined for historic RADIUS/TLS.</t>
            <t>Note that if a client sends "radius/1.1", the client will see
            that the server failed to acknowledge this request, request and will close
            the connection. For any other client configuration, the connection
            will use historic RADIUS/TLS.</t>
          </dd>
        </dl>
      </li>
                </ul>
              </li>
            </ul>
          </li>
        </ul>
        <ul empty="true">

      <li>
            <t>Other values ("1.0",
        <t>If set to "1.0", "1.0, 1.1", "1.1", etc.)</t>
            <ul empty="true">
              <li>
                <t>Client Behavior</t>
                <ul empty="true">
                  <li> or future values:</t>
        <dl newline="true" spacing="normal">
          <dt>Client Behavior</dt>
          <dd>
            <t>The client MUST <bcp14>MUST</bcp14> send the ALPN string(s)
            associated with the configured version.  e.g. For "1.0", example, send "radius/1.0".</t>
            "radius/1.0" for "1.0".</t>
	    <t>The client will receive either no ALPN response from the server,
	    server; or it will receive an ALPN response of one version string with MUST
	    that <bcp14>MUST</bcp14> match one of the strings it sent, sent; or else they will
	    receive a TLS alert of "no_application_protocol" (120).</t>
            <t>If the connection remains open, the client MUST <bcp14>MUST</bcp14>
            treat the connection as using the matching ALPN version.</t>
                  </li>
                </ul>
                <t>Server Behavior</t>
                <ul empty="true">
                  <li>
          </dd>
          <dt>Server Behavior</dt>
          <dd>
            <t>If the server receives no ALPN name from the client, it MUST
            <bcp14>MUST</bcp14> use historic RADIUS/TLS.</t>
            <t>If the server receives one or more ALPN names from the client,
            it MUST <bcp14>MUST</bcp14> reply with the highest mutually supported
            version and then use the latest supported version for this
            connection.</t>
            <t>If the server receives one or more ALPN names from the client,
            but none of the names match the versions supported by (or
            configured on) the server, it MUST <bcp14>MUST</bcp14> reply with a TLS
            alert of "no_application_protocol" (120), and then MUST it
            <bcp14>MUST</bcp14> close the TLS connection.</t>
            <t>These requirements for negotiation are not specific to RADIUS/1.1, and therefore
            RADIUS/1.1; therefore, they can be used unchanged if any new
            version of RADIUS is defined.</t>
          </dd>
        </dl>
      </li>
                </ul>
              </li>
            </ul>
          </li>
        </ul>

   </ol>
  </dd>
</dl>

        <t>By requiring the default configuration to allow historic
        RADIUS/TLS, implementations will be able to negotiate both historic
        RADIUS/TLS connections, connections and also RADIUS/1.1 connections.  Any other
        recommended default setting would prevent either the negotiation of
        historic RADIUS/TLS, RADIUS/TLS or prevent the negotiation of RADIUS/1.1.</t>

        <t>Once administrators verify that both ends of a connection support
        RADIUS/1.1, and that it has been negotiated successfully, the
        configurations SHOULD <bcp14>SHOULD</bcp14> be updated to require RADIUS/1.1.
        The connections should be monitored after this change to ensure that
        the systems continue to remain connected.  If there are connection
        issues, then the configuration should be reverted to using allow allowing both
        "radius/1.0" and "radius/1.1" ALPN strings, until such time as the administrator
        has resolved the connection problems have been resolved.</t> problems.</t>

        <t>We reiterate that systems implementing this specification, but
        which are configured with setting settings that forbid RADIUS/1.1, will behave
        largely the same as systems which that do not implement this specification.
        The only difference is that clients may send the ALPN name
        "radius/1.0".</t>

        <t>Systems implementing RADIUS/1.1 SHOULD NOT <bcp14>SHOULD NOT</bcp14> be
        configured by default to forbid that protocol.  That setting exists
        mainly for completeness, and to give administrators the flexibility to
        control their own deployments.</t>

        <t>While <xref target="RFC7301"/> does not discuss the possibility of
        the server sending a TLS alert of "no_application_protocol" (120) when
        the client does not use ALPN, this behavior appears to be useful.  As
        such, servers MAY <bcp14>MAY</bcp14> send a a TLS alert of
        "no_application_protocol" (120) when the client does not use ALPN.</t>

        <t>However, some TLS implementations may not permit an application to
        send a TLS alert of its choice, choice at a time of its choice.  This
        limitation means that it is not always possible for an application to
        send the TLS alert as discussed in the previous section.  The impact
        is that an implementation may attempt to connect, connect and then see that
        the connection fails, but it may not be able to determine why that failure
        has occurred.  Implementers and administrators should be aware that
        unexplained connection failures may be due to ALPN negotiation issues.</t>

        <t>The server MAY <bcp14>MAY</bcp14> send this alert during the ClientHello,
        ClientHello if it requires ALPN but does not receive it.  That is,
        there may not always be a need to wait for the TLS connection to be
        fully established before realizing that no common ALPN protocol can be
        negotiated.</t>

        <t>Where the client does perform signaling via ALPN ALPN, and the server
        determines that there is no compatible application protocol name, then
        as per <xref section="3.2" sectionFormat="comma" target="RFC7301"/>,
        it MUST <bcp14>MUST</bcp14> send a TLS alert of "no_application_protocol"
        (120).</t>
        <t>Whether

        <t>The server <bcp14>MUST</bcp14> close the connection whether or not
        the server sent a TLS alert for no compatible ALPN, it MUST close the connection. ALPN.  The above
        requirements on ALPN apply to both new sessions, sessions and to resumed
        sessions.</t>

        <t>In contrast, there is no need for the client to signal that there
        are no compatible application protocol names.  The client sends zero
        or more protocol names, and the server responds as above.  From the
        point of view of the client, the list it sent results in either a
        connection failure, failure or a connection success.</t>

        <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the server logs a descriptive
        error in this situation, so that an administrator can determine why a
        particular connection failed.  The log message SHOULD <bcp14>SHOULD</bcp14>
        include information about the other end of the connection, such as the IP
        address, certificate information, etc.  Similarly, when the client
        receives a TLS alert of "no_application_protocol" (120), it SHOULD
        <bcp14>SHOULD</bcp14> log a descriptive error message.  Such error
        messages are critical for helping administrators to diagnose
        connectivity issues.</t>

        <section anchor="using-protocol-error-for-signaling-alpn-failure">
          <name>Using Protocol-Error for Signaling ALPN Failure</name>

          <t>When it is not possible to send a TLS alert of
          "no_application_protocol" (120), then the only remaining method for
          one party to signal the other is to send application data inside of
          the TLS tunnel.  Therefore, for the situation when a one end of a
          connection determines that it requires ALPN ALPN, while the other end does
          not support ALPN, then the end requiring ALPN MAY <bcp14>MAY</bcp14> send a
          Protocol-Error packet <xref target="RFC7930"/> inside of the tunnel, tunnel
          and then MUST <bcp14>MUST</bcp14> close the connection.  If this is done,
          the Token field of the Protocol-Error packet cannot be copied from
          any request, and therefore request; therefore, that field MUST <bcp14>MUST</bcp14> be set to
          all zeros.</t>

          <t>The Protocol-Error packet SHOULD <bcp14>SHOULD</bcp14> contain a
          Reply-Message attribute with a textual string describing the cause
          of the error.  The packet SHOULD <bcp14>SHOULD</bcp14> also contain an
          Error-Cause attribute, with value Unsupported Extension (406). 406 (Unsupported Extension).  The
          packet SHOULD NOT <bcp14>SHOULD NOT</bcp14> contain other attributes.</t>

          <t>An implementation sending this packet could bypass any RADIUS encoder,
          encoder and simply write this packet as a predefined, fixed set of
          data to the TLS connection.  That process would likely be simpler
          than trying to call the normal RADIUS packet encoder to encode a
          reply packet with no corresponding request packet.</t>

          <t>As this packet is an unexpected response packet, existing client
          implementations of RADIUS over TLS will ignore it.  They may either
          log an error and close the connection, or they may discard the
          packet and leave the connection open.  If the connection remains
          open, the end supporting ALPN will close the connection, so there
          will be no side effects from sending this packet.  Therefore, while
          using a Protocol-Error packet in this way is unusual, it is both
          informative and safe.</t>

          <t>The purpose of this packet is not to have the other end of the
          connection automatically determine what went wrong, wrong and fix it.
          Instead, the packet is intended to be (eventually) seen by an
          administrator, who can then take remedial action.</t>
        </section>

        <section anchor="tabular-summary">
          <name>Tabular Summary</name>

	  <t>The preceding text gives a large number of recommendations. In order
	  to give a simpler description of the outcomes, a table of possible
	  behaviors for client/server values of the Version variable is given
	  below.  This  The row and column headings are the RADIUS version numbers
	  sent in ALPN (or no ALPN).  The contents of the table are the
	  resulting RADIUS version that is negotiated.  For clarity, only the
	  RADIUS version numbers have been given, and not the full ALPN
	  strings (e.g., "radius/1.0").</t>

	  <t>This table and the names given below are for informational and
	  descriptive purposes only.</t>
          <figure>

          <table>
            <name>Possible outcomes Outcomes for ALPN Negotiation</name>
            <artwork><![CDATA[
                             Server
             no ALPN  |   1.0    | 1.0, 1.1 |    1.1
Client    |--------------------------------------------
----------|
No ALPN   |   TLS        TLS        TLS        Close-S
          |
1.0       |   TLS        TLS        TLS        Alert
          |
1.0, 1.1  |   TLS        TLS        1.1        1.1
          |
1.1       |   Close-C    Alert      1.1        1.1
]]></artwork>
          </figure> ALPN</name>
	    <thead>
	      <tr>
		<th rowspan="2">Client</th>
		<th colspan="4" align="center">Server</th>
	      </tr>
	      <tr>
		<th>no ALPN</th>
		<th>1.0</th>
		<th>1.0, 1.1</th>
		<th>1.1</th>
	      </tr>
	    </thead>
	    <tbody>
	      <tr>
		<th>no ALPN</th>
		<td>TLS</td>
		<td>TLS</td>
		<td>TLS</td>
		<td>Close-S</td>
	      </tr>
	      <tr>
		<th>1.0</th>
		<td>TLS</td>
		<td>TLS</td>
		<td>TLS</td>
		<td>Alert</td>
	      </tr>
	      <tr>
		<th>1.0, 1.1</th>
		<td>TLS</td>
		<td>TLS</td>
		<td>1.1</td>
		<td>1.1</td>
	      </tr>
	      <tr>
		<th>1.1</th>
		<td>Close-C</td>
		<td>Alert</td>
		<td>1.1</td>
		<td>1.1</td>
	      </tr>
	    </tbody>
	  </table>

          <t>The table entries above have the following meaning:</t>
          <ul empty="true">
            <li>
              <t>Alert</t>
              <ul empty="true">
                <li>

          <dl newline="true" spacing="normal">
              <dt>Alert</dt>
                <dd>
                  <t>The client sends ALPN, and the server does not agree to
                  the clients client's ALPN proposal.  The server replies with a TLS
                  alert of "no_application_protocol" (120), (120) and then closes
                  the TLS connection.</t>
                  <t>As the server replies with a TLS alert, the
                  Protocol-Error packet is not used here.</t>
                </li>
              </ul>
              <t>Close-C</t>
              <ul empty="true">
                <li>
                </dd>
              <dt>Close-C</dt>
                <dd>
                  <t>The client sends ALPN, but the server does not respond
                  with ALPN.  The client closes the connection.</t>
                  <t>As noted in the previous section, the client MAY
                  <bcp14>MAY</bcp14> send a Protocol-Error packet to the
                  server before closing the connection.</t>
                </li>
              </ul>
              <t>Close-S</t>
              <ul empty="true">
                <li>
                </dd>
              <dt>Close-S</dt>
                <dd>
                  <t>The client does not send ALPN string(s), but the server
                  requires ALPN.  The server closes the connection.</t>
                  <t>As noted in the previous section, the server MAY
                  <bcp14>MAY</bcp14> send a Protocol-Error packet to the
                  client before closing the connection.  The server MAY
                  <bcp14>MAY</bcp14> also send a TLS alert of
                  "no_application_protocol" (120) before closing the
                  connection.</t>
                </li>
              </ul>
              <t>TLS</t>
              <ul empty="true">
                <li>
                </dd>
              <dt>TLS</dt>
                <dd>
                  <t>Historic RADIUS/TLS is used.  The client either sends no
                  ALPN string, string or sends "radius/1.0".  The server either
                  replies with no ALPN string, string or with "radius/1.0".  The
                  connection MUST <bcp14>MUST</bcp14> use historic RADIUS/TLS.</t>
                </li>
              </ul>
              <t>1.1</t>
              <ul empty="true">
                <li>
                </dd>
              <dt>1.1</dt>
                <dd>
                  <t>The client sends the ALPN string "radius/1.1. "radius/1.1".  The server
                  acknowledges this negotiation with a reply of "radius/1.1",
                  and then RADIUS/1.1 is used.</t>
                </li>
              </ul>
            </li>
          </ul>
                </dd>
	  </dl>

          <t>Implementations should note that this table may be extended in
          future specifications.  The above text is informative, and does not
          mandate that only the above ALPN strings are used.  The actual ALPN negotiation
          takes place as defined in the preceding sections of this document, document
          and in <xref target="RFC7301"/>.</t>
        </section>
      </section>

      <section anchor="miscellaneous-items">
        <name>Miscellaneous Items</name>
        <t>Implementations of this specification MUST <bcp14>MUST</bcp14> require
        TLS version 1.3 or later.</t>

        <t>The use of the ALPN string "radius/1.0" is technically unnecessary,
        as it is largely equivalent to not sending any ALPN string.  However,
        that value is useful for RADIUS administrators.  A system which that sends
        the ALPN string "radius/1.0" is explicitly signaling that it supports ALPN negotiation,
        ALPN, but that it is not currently configured to support
        RADIUS/1.1.  That information can be used by administrators to
        determine which devices are capable of ALPN.</t>

        <t>The use of the ALPN string "radius/1.0" also permits server
        implementations to send a TLS alert of "no_application_protocol" (120)
        when it cannot find a matching ALPN string.  Experiments with TLS
        library implementations suggest that in some cases it is possible to
        send that TLS alert when ALPN is not used.  However, such a scenario
        is not discussed on in <xref target="RFC7301"/>, target="RFC7301"/> and is likely not
        universal.  As a result, ALPN as defined in <xref target="RFC7301"/>
        permits servers to send that TLS alert in situations where it would be
        otherwise forbidden, forbidden or perhaps unsupported.</t>

        <t>Finally, defining ALPN strings for all known RADIUS versions will
        make it easier to support additional ALPN strings if that
        functionality is ever needed.</t>
      </section>

      <section anchor="session-resumption">
        <name>Session Resumption</name>

        <t><xref section="3.1" sectionFormat="comma" target="RFC7301"/> states
        that ALPN is negotiated on each connection, even if session resumption
        is used:</t>
        <ul empty="true">
          <li>
            <t>When

        <blockquote>When session resumption or session tickets <xref
        target="RFC5077"/> are used, the previous contents of this extension
        are irrelevant, and only the values in the new handshake messages are considered.</t>
          </li>
        </ul>
        considered.</blockquote>

	<t>(Note: RFC 5077 was obsoleted by <xref target="RFC8446"/>.)</t>

        <t>In order to prevent down-bidding attacks, RADIUS systems which that
        negotiate the "radius/1.1" protocol MUST <bcp14>MUST</bcp14> associate that
        information with the session ticket, ticket and enforce the use of
        "radius/1.1" on session resumption.  That is, if "radius/1.1" was
        negotiated for a session, both clients and servers MUST <bcp14>MUST</bcp14>
        behave as if the RADIUS/1.1 variable was set to "require" for that
        session.</t>

        <t>A client which that is resuming a "radius/1.1" connection MUST
        <bcp14>MUST</bcp14> advertise only the capability to do "radius/1.1"
        for the resumed session.  That is, even if the client configuration
        allows historic RADIUS/TLS for new connections, it MUST <bcp14>MUST</bcp14>
        signal "radius/1.1" when resuming a session which that had previously
        negotiated "radius/1.1".</t>

        <t>Similarly, when a server does resumption for a session which that had
        previously negotiated "radius/1.1".   If "radius/1.1",  if the client attempts to resume
        the sessions without signaling the use of RADIUS/1.1, the server MUST
        <bcp14>MUST</bcp14> close the connection.  The server MUST
        <bcp14>MUST</bcp14> send an appropriate TLS error, and also SHOULD
        <bcp14>SHOULD</bcp14> log a descriptive message as described
        above.</t>

        <t>In contrast, there is no requirement for a client or server to
        force the use of RADIUS/TLS from <xref target="RFC6614"/> RADIUS/TLS on session
        resumption.  Clients are free to signal support for "radius/1.1" on
        resumed sessions, even if the original session did not negotiate
        "radius/1.1".  Servers are free to accept this request, request and to
        negotiate the use of "radius/1.1" for such sessions.</t>
      </section>
    </section>

    <section anchor="radius11-packet-and-attribute-formats">
      <name>RADIUS/1.1 Packet and Attribute Formats</name>
      <t>This section describes the application-layer data which that is sent
      inside of (D)TLS when using the RADIUS/1.1 protocol.  Unless otherwise
      discussed herein, the application-layer data is unchanged from traditional historic RADIUS.  This protocol is only used when "radius/1.1" has
      been negotiated by both ends of a connection.</t>

      <section anchor="radius11-packet-format">
        <name>RADIUS/1.1 Packet Format</name>
        <t>When RADIUS/1.1 is used, the RADIUS header is modified from
        standard RADIUS.  While the header has the same size, some fields have
        different meaning. meanings.  The Identifier and the Request / and Response
        Authenticator fields are no longer used in RADIUS/1.1.  Any operations which
        that depend on those fields MUST NOT <bcp14>MUST NOT</bcp14> be performed.  As
        packet authentication, secrecy, and security are handled by the TLS
        layer, RADIUS-specific cryptographic primitives are no longer needed
        or used in RADIUS/1.1.</t>

        <t>A summary of the RADIUS/1.1 packet format is shown below.  The
        fields are transmitted from left to right.</t>

        <figure anchor="Header">
          <name>The RADIUS/1.1 Packet Format</name>
          <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Reserved-1   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Token                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                           Reserved-2                          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork>
        </figure>
        <t>Code</t>
        <ul empty="true">
          <li>

	<dl spacing="normal" newline="true">

          <dt>Code</dt>
          <dd>
            <t>The Code field is one octet, octet and identifies the type of RADIUS packet.</t>

            <t>The meaning of the Code field is unchanged from previous RADIUS specifications.</t>
          </li>
        </ul>
        <t>Reserved-1</t>
        <ul empty="true">
          <li>

          </dd>
          <dt>Reserved-1</dt>
          <dd>
            <t>The Reserved-1 field is one octet.</t>

            <t>This field was previously used as the "Identifier" in historic
            RADIUS/TLS.  It is now unused, as the Token field replaces it both
            as the way to identify requests, requests and to associate responses with
            requests.</t>

            <t>When sending packets, the Reserved-1 field MUST <bcp14>MUST</bcp14>
            be set to zero.  The Reserved-1 field MUST <bcp14>MUST</bcp14> be
            ignored when receiving a packet.</t>
          </li>
        </ul>
        <t>Length</t>
        <ul empty="true">
          <li>
          </dd>

          <dt>Length</dt>
          <dd>
            <t>The Length field is two octets.</t>
            <t>The meaning of the Length field is unchanged from previous RADIUS specifications.</t>
          </li>
        </ul>
        <t>Token</t>
        <ul empty="true">
          <li>
          </dd>
          <dt>Token</dt>
          <dd>
            <t>The Token field is four octets, octets and aids in matching requests
            and replies, as a replacement for the Identifier field.  The
            RADIUS server can detect a duplicate request if it receives the
            same Token value for two packets on a particular connection.</t>
            <t>All values are possible for the Token field.  Implementations MUST
            <bcp14>MUST</bcp14> treat the Token as an opaque blob when
            comparing Token values.</t>
            <t>Further requirements are given below in <xref
            target="sending-packets"/> for sending packets, packets and in <xref
            target="receiving-packets"/> for receiving packets.</t>
          </li>
        </ul>
        <t>Reserved-2</t>
        <ul empty="true">
          <li>
          </dd>

          <dt>Reserved-2</dt>
          <dd>
            <t>The Reserved-2 field is twelve (12) octets in length.</t>
            <t>These octets MUST <bcp14>MUST</bcp14> be set to zero when sending a packet.</t>
            <t>These octets MUST <bcp14>MUST</bcp14> be ignored when receiving a packet.</t>
            <t>These octets are reserved for future protocol extensions.</t>
          </li>
        </ul>
          </dd>
        </dl>
      </section>

      <section anchor="the-token-field">
        <name>The Token Field</name>
        <t>This section describes in more detail how the Token field is used.</t>

        <section anchor="sending-packets">
          <name>Sending Packets</name>

          <t>The Token field MUST <bcp14>MUST</bcp14> change for every new unique
          packet which that is sent on the same connection. For DTLS transport, it
          is possible to retransmit duplicate packets, in which case the Token
          value MUST NOT <bcp14>MUST NOT</bcp14> be changed when a duplicate packet is
          (re)sent.  When the contents of a retransmitted packet change for
          any reason (such as changing Acct-Delay-Time as discussed in <xref
          section="5.2" sectionFormat="comma" target="RFC2866"/>), the Token
          value MUST <bcp14>MUST</bcp14> be changed.  Note that on reliable
          transports, packets are never retransmitted, and therefore retransmitted; therefore, every new
          packet which that is sent has a unique Token value.</t>

          <t>We note that in previous RADIUS specifications, the Identifier
          field could have the same value for different packets on the same
          connection.  For example, Access-Request (Code 1) and
          Accounting-Request (Code 4) packets could both use ID 3, 3 and still
          be treated as different packets.  This overlap required requires that RADIUS
          clients and servers track the Identifier field, not only on a
          per-connection basis, but also on a per-Code basis.  This behavior
          adds complexity to implementations.</t>

	  <t>In contrast, the Token values MUST <bcp14>MUST</bcp14> be generated
	  from a 32-bit counter which that is unique to each connection.  Such a
	  counter SHOULD <bcp14>SHOULD</bcp14> be initialized to a random value,
	  taken from a random number generator, whenever a new connection
	  is opened.  The counter MUST <bcp14>MUST</bcp14> then be incremented for
	  every unique new packet which that is sent by the client.  Retransmissions
	  of the same packet MUST <bcp14>MUST</bcp14> use the same unchanged Token
	  value.  As the Token value is mandated to be unique per packet, a
	  duplicate Token value is the only way that a server can detect
	  duplicate transmissions.</t>

	  <t>This counter method ensures that the Tokens are unique, unique and are
          also independent of any Code value in the RADIUS packet header.
          This method is mandated because any other method of generating
          unique and non-conflicting Token values is more complex, with no
          additional benefit and only the likelihood of increased bugs and
          interoperability issues.  Any other method for generating Token
          values would require substantially more resources to track
          outstanding Token values and their associated expiry times.  The
          chance that initial values could potentially cause any confusion by
          being re-used reused across two connections is one in 2^32, 2<sup>32</sup>, which
          is acceptable.</t>

          <t>The purpose for initializing the Token to a random counter is
          mainly to aid administrators in debugging systems.  If the Token
          values always used the same sequence, then it would easier for a
          person to confuse different packets which that have the same Token value.
          By instead starting with a random value, those values are more
          evenly distributed across the set of allowed values, and values; therefore, they
          are therefore more likely to be unique.</t>

          <t>As there is no special meaning for the Token, there is no meaning
          when a counter "wraps" around from a high value back to zero.  The
          originating system can simply continue to increment the Token value
          without taking any special action in that situation.</t>

          <t>Once a RADIUS response to a request has been received and there
          is no need to track the packet any longer, the Token value can be
          reused.  This reuse happens only when the counter "wraps around"
          after 2^32 2<sup>32</sup> packets have been sent over one connection.
          This method of managing the counter automatically ensures a long
          delay (i.e. 2^32 (i.e., 2<sup>32</sup> packets) between multiple uses of the
          same Token value.  This large number of packets ensures that the
          only possible situation where there may be conflict is when a client
          sends billions of packets a second across one connection, or when a
          client sends billions of packets without receiving replies.  We
          suggest that such situations are vanishingly rare.  The best
          solution to those situations would be to limit the number out of
          outstanding packets over one connection to a number much lower than
          billions.</t>

          <t>If a RADIUS client has multiple independent subsystems which that send
          packets to a server, each subsystem MAY <bcp14>MAY</bcp14> open a new
          connection which that is unique to that subsystem.  There is no
          requirement that all packets go over one particular connection.
          That is, despite the use of a 32-bit Token field, RADIUS/1.1 clients
          are still permitted to open multiple source ports as discussed in
          <xref target="RFC2865"/> Section 2.5.</t> section="2.5" sectionFormat="comma" target="RFC2865"/>.</t>

          <t>While multiple connections from client to server are allowed, We we
          reiterate the suggestion of <xref section="3.3"
          sectionFormat="comma" target="RFC3539"/> that a single connection is
          preferred to multiple connections.  The use of a single connection
          can improve throughput and latency, while simplifying the clients client's
          efforts to determine server status.</t>
        </section>

        <section anchor="receiving-packets">
          <name>Receiving Packets</name>
          <t>A server which that receives RADIUS/1.1 packets MUST <bcp14>MUST</bcp14>
          perform packet deduplication for all situations where it is required
          by RADIUS.  Where RADIUS does not require deduplication (e.g. (e.g., TLS
          transport), the server SHOULD NOT <bcp14>SHOULD NOT</bcp14> do deduplication.
          However, DTLS transport is UDP-based, and therefore still requires
          deduplication.</t>

          <t>When using RADIUS/1.1, implementations MUST <bcp14>MUST</bcp14> do
          deduplication only on the Token field, and not on any other field or
          fields in the packet header. A server MUST <bcp14>MUST</bcp14> treat the
          Token as being an opaque field with no intrinsic meaning.  This
          requirement makes the receiver behavior independent of the methods
          by which the Counter is generated.</t>

          <t>Where Token deduplication is done, it MUST <bcp14>MUST</bcp14> be done
          on a per-connection basis.  If two packets which that are received on
          different connections contain the same Token value, then those
          packets MUST <bcp14>MUST</bcp14> be treated as distinct (i.e. (i.e., different)
          packets.  Systems performing deduplication MAY <bcp14>MAY</bcp14> still
          track the packet Code, Length, and Attributes which is that are associated
          with a Token value.  If it determines that the sender is re-using reusing
          Token values for distinct outstanding packets, then an error should
          be logged, and the connection MUST <bcp14>MUST</bcp14> be closed.  There
          is no way to negotiate correct behavior in the protocol.  Either the parties
          both parties operate normally and can communicate, or one end misbehaves,
          misbehaves and no communication is possible.</t>

	  <t>Once a reply has been sent, a system doing deduplication SHOULD
          <bcp14>SHOULD</bcp14> cache the replies as discussed in <xref
          section="2.2.2" sectionFormat="comma" target="RFC5080"/>:</t>
          <ul empty="true">
            <li>
              <t>Each

          <blockquote>Each cache entry SHOULD <bcp14>SHOULD</bcp14> be purged after
          a period of time.  This time
SHOULD <bcp14>SHOULD</bcp14> be no less than 5
          seconds, and no more than 30 seconds.  After about 30 seconds, most
          RADIUS clients and end users will have given up on the
          authentication request.  Therefore, there is little value in having
          a larger cache timeout.</t>
            </li>
          </ul> timeout.</blockquote>

          <t>This change from RADIUS means that the Identifier field is no
          longer useful for RADIUS/1.1.  The Reserved-1 field (previously used
          as the Identifier) MUST <bcp14>MUST</bcp14> be set to zero when encoding
          all RADIUS/1.1 packets.  Implementations of RADIUS/1.1 which that receive
          packets MUST <bcp14>MUST</bcp14> ignore this field.</t>
        </section>
      </section>
    </section>

    <section anchor="attribute-handling">
      <name>Attribute handling</name> Handling</name>
      <t>Most attributes in RADIUS have no special encoding "on the wire", or
      any special meaning between client and server.  Unless discussed in this
      section, all RADIUS attributes are unchanged in this specification.
      This requirement includes attributes which that contain a tag, as defined in
      <xref target="RFC2868"/>.</t>

      <section anchor="obfuscated-attributes">
        <name>Obfuscated Attributes</name>

        <t>Since the (D)TLS layer provides for connection authentication,
        integrity checks, and confidentiality, there is no need to hide the
        contents of an attribute on a hop-by-hop basis.  As a result, all
        attributes defined as being obfuscated via the shared secret no longer
        have the obfuscation step applied when RADIUS/1.1 is used.  Instead,
        those attributes MUST <bcp14>MUST</bcp14> be encoded using the encoding for
        the underlying data type, with any encryption / obfuscation step
        omitted.  For example, the User-Password attribute is no longer obfuscated,
        obfuscated and is instead sent as data type "text".</t>

        <t>There are risks from sending passwords over the network, even when
        they are protected by TLS.  One such risk comes from the common
        practice of multi-hop RADIUS routing.  As all security in RADIUS is on
        a hop-by-hop basis, every proxy which that receives a RADIUS packet can see
        (and modify) all of the information in the packet.  Sites wishing to
        avoid proxies SHOULD <bcp14>SHOULD</bcp14> use dynamic peer discovery <xref
        target="RFC7585"/>, which permits clients to make connections directly
        to authoritative servers for a realm.</t>

        <t>There are others other ways to mitigate these risks.  The simplest is to
        follow the requirements of item (3) from <xref section="2.4" section="3.4"
        sectionFormat="comma" target="RFC6614"/> item (3) and also follow <xref section="10.4"
        sectionFormat="comma" target="RFC7360"/>, which mandates that RADIUS
        over TLS implementations validate the peer before sending any RADIUS
        traffic.</t>

        <t>Another way to mitigate these risks is for the system being
        authenticated to use an authentication protocol which that never sends
        passwords (e.g. (e.g., an Extensible Authentication Protocol (EAP) method
        like EAP-pwd <xref target="RFC5931"/>), or which one that sends passwords protected by a
        TLS tunnel (e.g. EAP-TTLS (e.g., EAP Tunneled Transport Layer Security (EAP-TTLS)
        <xref target="RFC5281"/>).  The processes to choose and configuring configure an
        authentication protocol are strongly site-dependent, site dependent, so further discussion
        discussions of these issues are outside of the scope of this document.
        The goal here is to ensure that the reader has enough information to
        make an informed decision.</t>

        <t>We note that as the RADIUS shared secret is no longer used in this
        specification, it is no longer possible or necessary for any attribute
        to be obfuscated on a hop-by-hop basis using the previous methods
        defined for RADIUS.</t>

        <section anchor="user-password">
          <name>User-Password</name>
          <t>The User-Password attribute (<xref section="5.2"
          sectionFormat="comma" target="RFC2865"/>) MUST <bcp14>MUST</bcp14> be
          encoded the same as any other attribute of data type 'string' "string" (<xref
          section="3.5" sectionFormat="comma" target="RFC8044"/>).</t>

          <t>The contents of the User-Password field MUST <bcp14>MUST</bcp14> be at
          least one octet in length, length and MUST NOT <bcp14>MUST NOT</bcp14> be more than
          128 octets in length.  This limitation is maintained from <xref
          section="5.2" sectionFormat="comma" target="RFC2865"/> for
          compatibility with historic transports.</t>

          <t>Note that the User-Password attribute is not of data type 'text'. "text".
          The original reason in <xref target="RFC2865"/> was because the
          attribute was encoded as an opaque and obfuscated binary blob.  This
          document does not change the data type of User-Password, even though
          the attribute is no longer obfuscated.  The contents of the
          User-Password attribute do not have to be printable text, text or UTF-8
          data as per the definition of the 'text' "text" data type in <xref
          section="3.4" sectionFormat="comma" target="RFC8044"/>.</t>

          <t>However, implementations should be aware that passwords are often
          printable text, and where the passwords are printable text, it can
          be useful to store and display them as printable text.  Where
          implementations can process non-printable data in the 'text' "text" data
          type, they MAY <bcp14>MAY</bcp14> use the data type 'text' "text" for
          User-Password.</t>
        </section>

        <section anchor="chap-challenge">
          <name>CHAP-Challenge</name>

          <t><xref section="5.3" sectionFormat="comma" target="RFC2865"/>
          allows for the CHAP challenge to be taken from either the
          CHAP-Challenge attribute (<xref section="5.40" sectionFormat="comma" target="RFC2865"/>),
          target="RFC2865"/>) or the Request Authenticator field.  Since
          RADIUS/1.1 connections no longer use a Request Authenticator field,
          it is no longer possible to use the Request Authenticator field as
          the CHAP-Challenge when this transport profile is used.</t>

          <t>Clients which that send a CHAP-Password attribute (<xref section="5.3"
          sectionFormat="comma" target="RFC2865"/>) in an Access-Request
          packet over a RADIUS/1.1 connection MUST <bcp14>MUST</bcp14> also include
          a CHAP-Challenge attribute (<xref section="5.40"
          sectionFormat="comma" target="RFC2865"/>).</t>

          <t>Proxies may need to receive Access-Request packets over a
          non-RADIUS/1.1 transport and then forward those packets over a
          RADIUS/1.1 connection.  In that case, if the received Access-Request
          packet contains a CHAP-Password attribute but no CHAP-Challenge
          attribute, the proxy MUST <bcp14>MUST</bcp14> create a CHAP-Challenge
          attribute in the proxied packet using the contents from the incoming
          Request Authenticator of the received packet.</t>
        </section>

        <section anchor="tunnel-password">
          <name>Tunnel-Password</name>

          <t>The Tunnel-Password attribute (<xref section="3.5"
          sectionFormat="comma" target="RFC2868"/>) MUST <bcp14>MUST</bcp14> be
          encoded the same as any other attribute of data type 'string' which "string" that
          contains a tag, such as Tunnel-Client-Endpoint (<xref section="3.3"
          sectionFormat="comma" target="RFC2868"/>).  Since the attribute is
          no longer obfuscated in RADIUS/1.1, there is no need for a Salt
          field or Data-Length fields as described in <xref section="3.5"
          sectionFormat="comma" target="RFC2868"/>, and the target="RFC2868"/>. The textual value of
          the password can simply be encoded as-is.</t> as is.</t>

          <t>Note that the Tunnel-Password attribute is not of data type 'text'.
          "text".  The original reason in <xref target="RFC2868"/> was because
          the attribute was encoded as an opaque and obfuscated binary blob.
          We maintain that data type here, even though the attribute is no
          longer obfuscated.  The contents of the Tunnel-Password attribute do
          not have to be printable text, text or UTF-8 data as per the definition
          of the 'text' "text" data type in <xref section="3.4" sectionFormat="comma"
          target="RFC8044"/>.</t>

          <t>However, implementations should be aware that passwords are often
          printable text, and where the passwords are printable text, it can
          be useful to store and display them as printable text.  Where
          implementations can process non-printable data in the 'text' "text" data
          type, they MAY <bcp14>MAY</bcp14> use the data type 'text' "text" for
          Tunnel-Password.</t>
        </section>

        <section anchor="vendor-specific-attributes">
          <name>Vendor-Specific Attributes</name>

<!-- [rfced] As Section 3.4 of RFC 8044 refers to the "text" data,
should the section number be updated to 3.5?

Original:
   Specifically, the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes
   ([RFC2548], Section 2.4) MUST be encoded as any other attribute of data
   type 'string' ([RFC8044], Section 3.4).

Perhaps:
   Specifically, the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes
   ([RFC2548], Section 2.4) MUST be encoded as any other attribute of
   data type 'string' ([RFC8044], Section 3.5).
-->

<t>Any Vendor-Specific attribute which that uses similar obfuscation MUST
          <bcp14>MUST</bcp14> be encoded as per their base data type.
          Specifically, the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes
          (<xref section="2.4" sectionFormat="comma" target="RFC2548"/>) MUST
          <bcp14>MUST</bcp14> be encoded as any other attribute of data type 'string'
          "string" (<xref section="3.4" sectionFormat="comma"
          target="RFC8044"/>).</t>
        </section>
      </section>

      <section anchor="message-authenticator">
        <name>Message-Authenticator</name>

        <t>The Message-Authenticator attribute (<xref section="3.2"
        sectionFormat="comma" target="RFC3579"/>) MUST NOT <bcp14>MUST NOT</bcp14> be
        sent over a RADIUS/1.1 connection.  That attribute is not used or
        needed in RADIUS/1.1.</t>

        <t>If the Message-Authenticator attribute is received over a
        RADIUS/1.1 connection, the attribute MUST <bcp14>MUST</bcp14> be silently discarded,
        discarded or treated as an "invalid attribute", as defined in <xref
        section="2.8" sectionFormat="comma" target="RFC6929"/>.  That is, the
        Message-Authenticator attribute is no longer used to authenticate
        packets for the RADIUS/1.1 transport.  Its existence (or not) in this
        transport is meaningless.</t>

        <t>A system which that receives a Message-Authenticator attribute in a
        packet MUST <bcp14>MUST</bcp14> treat it as an "invalid attribute" as
        defined in <xref section="2.8" sectionFormat="comma"
        target="RFC6929"/>.  That is, the packet can still be processed, even
        if the Message-Authenticator attribute is ignored.</t>

        <t>For proxies, the Message-Authenticator attribute has always been
        defined as being created and consumed on a "hop by hop" "hop-by-hop" basis.  That
        is, a proxy which that received a Message-Authenticator attribute from a
        client would never forward that attribute as-is as is to another server.
        Instead, the proxy would either suppress, suppress or re-create, recreate the
        Message-Authenticator attribute in the outgoing request.  This
        existing behavior is leveraged in RADIUS/1.1 to suppress the use of the
        Message-Authenticator over a RADIUS/1.1 connection.</t>

        <t>A proxy may receive an Access-Request packet over a RADIUS/1.1 connection,
        connection and then forward that packet over a RADIUS/UDP or a
        RADIUS/TCP connection.  In that situation, the proxy SHOULD
        <bcp14>SHOULD</bcp14> add a Message-Authenticator attribute to every
        Access-Request packet which that is sent over an insecure transport
        protocol.</t>

        <t>The original text in <xref section="3.3"
        sectionFormat="comma" target="RFC3579"/>, "Note 1" paragraph Note 1 required that the
        Message-Authenticator attribute be present for certain Access-Request
        packets.  It also required the use of the Message-Authenticator when
        the Access-Request packet contained an EAP-Message attribute.
        Experience has shown that some RADIUS clients never use the
        Message-Authenticator, even for the situations where its use is
        suggested.</t>

        <t>When the Message-Authenticator attribute is missing from Access-Request Access-
        Request packets, it is often possible to trivially forge or replay
        those packets.  As such, this document RECOMMENDS it is <bcp14>RECOMMENDED</bcp14> that RADIUS
        clients always include Message-Authenticator in Access-Request packets
        when using UDP or TCP transport.  As the scope of this document is
        limited to defining RADIUS/1.1, we cannot mandate that behavior here.
        Instead, we can note that there are no known negatives to this
        behavior, and there are definite positives, such as increased
        security.</t>
      </section>

      <section anchor="message-authentication-code">
        <name>Message-Authentication-Code</name>
        <t>Similarly, the Message-Authentication-Code attribute defined in
        <xref section="3.3" sectionFormat="comma" target="RFC6218"/> MUST NOT
        <bcp14>MUST NOT</bcp14> be sent over a RADIUS/1.1 connection.  If it
        is received in a packet, it MUST <bcp14>MUST</bcp14> be treated as an "invalid
        attribute" as defined in <xref section="2.8" sectionFormat="comma"
        target="RFC6929"/>.</t>
        <t>As the Message-Authentication-Code attribute is no longer used in
        RADIUS/1.1, the related MAC-Randomizer attribute <xref (<xref section="3.2"
        sectionFormat="comma" target="RFC6218"/> MUST NOT target="RFC6218"/>) <bcp14>MUST NOT</bcp14> be
        sent over a RADIUS/1.1 connection.  If it is received in a packet, it MUST
        <bcp14>MUST</bcp14> be treated as an "invalid attribute" as defined in
        <xref section="2.8" sectionFormat="comma" target="RFC6929"/>.</t>
      </section>

<section anchor="chap-ms-chap-etc">
        <name>CHAP, MS-CHAP, etc.</name> and Similar Attributes</name>

        <t>While some attributes such as CHAP-Password, etc. CHAP-Password depend on
        insecure cryptographic primitives such as MD5, these attributes are
        treated as opaque blobs when sent between a RADIUS client and server.
        The contents of the attributes are not obfuscated, and they do not
        depend on the RADIUS shared secret.  As a result, these attributes are
        unchanged in RADIUS/1.1.</t>

        <t>Similarly, MS-CHAP depends on MD4, and RADIUS/1.1 does not change
        the definition of any MS-CHAP attributes.  However, MS-CHAP has been
        broken for decades, as noted in <xref target="ASLEAP"/>.  The only
        appropriate use-case use case for MS-CHAP is when it is protected by a secure
        transport such as RADIUS/TLS, RADIUS/TLS or RADIUS/DTLS, or when it is used for
        "inner tunnel" authentication methods as with PEAP the Protected Extensible
        Authentication Protocol (PEAP) or TTLS.</t>

        <t>A server implementing this specification can proxy CHAP, MS-CHAP, etc. without any issue.  A  server implementing this specification can and
        authenticate CHAP, MS-CHAP, etc. without any issue.  The RADIUS/1.1
        protocol changes how RADIUS packets are authenticated, authenticated and how "secret"
        data is obfuscated inside of a RADIUS packet.  It does not change any
        authentication method which that is transported inside of RADIUS.</t>
      </section>

      <section anchor="original-packet-code">
        <name>Original-Packet-Code</name>
        <t><xref section="4" sectionFormat="comma" target="RFC7930"/> defines
        an Original-Packet-Code attribute.  This attribute is needed because
        otherwise it is impossible to correlate the Protocol-Error response
        packet with a particular request packet.  The definition in <xref
        section="4" sectionFormat="comma" target="RFC7930"/> describes the
        reasoning behind this need:</t>
        <ul empty="true">
          <li>
            <t>The

        <blockquote>The Original-Packet-Code contains the code from the
        request that generated the protocol error so that clients can
        disambiguate requests with different codes and the same ID.</t>
          </li>
        </ul> ID.</blockquote>

        <t>This attribute is no longer needed in RADIUS/1.1.  The Identifier
        field is unused, so it impossible for two requests to have the "same"
        ID.  Instead, the Token field permits clients and servers to correlate
        requests and responses, independent of the Code value being used.</t>

        <t>Therefore, the Original-Packet-Code attribute (<xref section="4"
        sectionFormat="comma" target="RFC7930"/>) MUST NOT <bcp14>MUST NOT</bcp14> be
        sent over a RADIUS/1.1 connection.  If it is received in a packet, it MUST
        <bcp14>MUST</bcp14> be treated as an "invalid attribute" as defined in
        <xref section="2.8" sectionFormat="comma" target="RFC6929"/>.</t>
      </section>
    </section>

    <section anchor="other-considerations-when-using-alpn">
      <name>Other Considerations when using When Using ALPN</name>
      <t>Most of the differences between RADIUS and RADIUS/1.1 are in the
      packet header and attribute handling, as discussed above.  The remaining
      issues are a small set of unrelated topics, and are discussed here.</t>

      <section anchor="protocol-error">
        <name>Protocol-Error</name>
        <t>There are a number of situations where a RADIUS server is unable to
        respond to a request.  One situation is where the server depends on a
        database, and the database is down.  While arguably the server should
        close all incoming connections when it is unable to do anything, this
        action is not always effective.  A client may aggressively try to open
        new connections, connections or send packets to an unconnected UDP destination
        where the server is not listening.  Another situation where the server
        is unable to respond is when the server is proxying packets, and the
        outbound connections are either full or failed.</t>

        <t>In all RADIUS spercifications specifications prior to this one, there is no way
        for the server to send a client the positive signal that it received a request,
        request but is unable to send a response.  Instead, the server
        usually just discards the request, which to the client is
        indistinguishable from the situation where the server is down.  This
        failure case is made worse by the fact that perhaps some proxied
        packets succeed while others fail.  The client can only conclude then
        that the server is randomly dropping packets, packets and is unreliable.</t>

        <t>It would be very useful for servers to signal to clients that they
        have received a request, request but are unable to process it.  This
        specification uses the Protocol-Error packet <xref (<xref section="4"
        sectionFormat="comma" target="RFC7930"/> target="RFC7930"/>) as that signal.  The use of
        Protocol-Error allows for both hop-by-hop signaling in the case of
        proxy forwarding errors, and also for end-to-end signaling of server
        to client.  Such signaling should greatly improve the robustness of
        the RADIUS protocol.</t>

        <t>When a RADIUS/1.1 server determines that it is unable to process an
        Access-Request or Accounting-Request packet, it MUST <bcp14>MUST</bcp14>
        respond with a Protocol-Error packet containing an Error-Cause
        attribute.  A proxy which that cannot forward the packet MUST
        <bcp14>MUST</bcp14> respond with either 502 (Request Not Routable (Proxy)),
        (Proxy)) or 505 (Other Proxy Processing Error).  This requirement is
        to help distinguish failures in the proxy chain from failures at the
        final (i.e. (i.e., home) server,</t> server.</t>

        <t>For a home server, if none of the Error-Cause values match the
        reason for the failure, then the value 506 (Resources Unavailable) MUST
        <bcp14>MUST</bcp14> be used.</t>

        <t>When a RADIUS proxy receives a Protocol-Error reply, it MUST
        <bcp14>MUST</bcp14> examine the value of the Error-Cause attribute.
        If there is no Error-Cause attribute, or if its value is something other
        than 502 (Request Not Routable (Proxy)), 505 (Other Proxy Processing
        Error), or 506 (Resources Unavailable), then the proxy MUST <bcp14>MUST</bcp14>
        return the Protocol-Error response packet to the client, client and include
        the Error-Cause attribute from the response it received.  This process
        allows for full "end to end" "end-to-end" signaling of servers to clients.</t>

        <t>In all situations other then than those outlined in the preceding paragraph, a
        client which that receives a Protocol-Error reply MUST re-process <bcp14>MUST</bcp14>
        reprocess the original outgoing packet through the client forwarding
        algorithm.  This requirement includes both clients which that originate
        RADIUS traffic, traffic and proxies which that see an Error-Cause attribute of 502
        (Request Not Routable (Proxy)), (Proxy)) or 505 (Other Proxy Processing
        Error).</t>

        <t>The expected result of this processing is that the client forwards
        the packet to a different server.  Clients MUST NOT <bcp14>MUST NOT</bcp14>
        forward the packet over the same connection, connection and SHOULD NOT <bcp14>SHOULD
        NOT</bcp14> forward it to over a different connection to the same
        server.</t>

        <t>This process may continue over multiple connections and multiple
        servers, until the client either times out the request, request or fails to
        find a forwarding destination for the packet.  A proxy which that is unable
        to forward a packet MUST <bcp14>MUST</bcp14> reply with a Protocol-Error
        packet containing an Error-Cause, as defined above.  A client which that
        originates packets MUST <bcp14>MUST</bcp14> treat such a request as if it
        had received no response.</t>

        <t>This behavior is intended to improve the stability of the RADIUS
        protocol by addressing issues first raised in <xref section="2.8"
        sectionFormat="comma" target="RFC3539"/>.</t>
      </section>

      <section anchor="status-server">
        <name>Status-Server</name>

        <t><xref section="2.6.5" sectionFormat="comma" target="RFC6613"/>, and
        by extension <xref target="RFC7360"/>, suggest that the Identifier
        value zero (0) be reserved for use with Status-Server as an
        application-layer watchdog.  This practice MUST NOT <bcp14>MUST NOT</bcp14> be
        used for RADIUS/1.1, as the Identifier field is not used in this
        transport profile.</t>

        <t>The rationale for reserving one value of the Identifier field was
        the limited number of Identifiers available (256), (256) and the overlap in
        Identifiers between Access-Request packets and Status-Server packets.
        If all 256 Identifier values had been used to send Access-Request
        packets, then there would be no Identifier value available for sending
        a Status-Server packet.</t>

        <t>In contrast, the Token field allows for 2^32 2<sup>32</sup> outstanding
        packets on one RADIUS/1.1 connection.  If there is a need to send a
        Status-Server packet, it is nearly always possible to allocate a new
        value for the Token field.  If instead there are 2^32 2<sup>32</sup>
        outstanding packets for one connection, then it is likely that
        something has gone catastrophically wrong.  In that case, the safest
        way forward is likely to just close the connection.</t>
      </section>

      <section anchor="proxies">
        <name>Proxies</name>

        <t>A RADIUS proxy normally decodes and then re-encodes all attributes, included
        including obfuscated ones.  A RADIUS proxy will not generally rewrite
        the content of the attributes it proxies (unless site-local policy
        requires such a rewrite).  While some attributes may be modified due
        to administrative or policy rules on the proxy, the proxy will
        generally not rewrite the contents of attributes such as
        User-Password, Tunnel-Password, CHAP-Password, MS-CHAP-Password,
        MS-MPPE keys, etc.  All  Therefore, all attributes are therefore transported through a
        RADIUS/1.1 connection without changing their values or contents.</t>

        <t>A proxy may negotiate RADIUS/1.1 (or not) with a particular client
        or clients, and it may negotiate RADIUS/1.1 (or not) with a server or
        servers it connect connects to, in any combination.  As a result, this
        specification is fully compatible with all past, present, and future
        RADIUS attributes.</t>
      </section>
    </section>

    <section anchor="other-radius-considerations">
      <name>Other RADIUS Considerations</name>

      <t>This section discusses issues in RADIUS which that need to be addressed in
      order to support ALPN, but which aren't direcly directly part of the RADIUS/1.1
      protocol.</t>

      <section anchor="crypto-agility">
        <name>Crypto-Agility</name>

        <t>The crypto-agility requirements of <xref target="RFC6421"/> are
        addressed in <xref section="C" sectionFormat="comma" target="RFC6614"/>,
        target="RFC6614"/> and in <xref section="10.1" sectionFormat="comma"
        target="RFC7360"/>.  This specification makes no changes from, or additions to,
        to those specifications.  The use of ALPN, ALPN and the removal of MD5 has
        no impact on the security or privacy of the protocol.</t>

        <t>RADIUS/TLS has been widely deployed in at least eduroam <xref (<xref
        target="RFC7593"/> and <xref target="EDUROAM"/> target="EDUROAM"/>) and in OpenRoaming
        <xref target="OPENROAMING"/>.  RADIUS/DTLS has seen less adoption, but
        it is known to be supported in many RADIUS clients and servers.</t>

        <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that all implementations of
        historic RADIUS/TLS be updated to support this specification.  Where a
        system already implements RADIUS over TLS, the additional effort to
        implement this specification is minimal.  Once implementations support
        it, administrators can gain the benefit of it with little or no
        configuration changes.  This specification is backwards compatible
        with <xref target="RFC6614"/> and <xref target="RFC7360"/>.  It is
        only potentially subject to down-bidding attacks if implementations do
        not enforce ALPN negotiation correctly on session resumption.</t>

        <t>All crypto-agility needed or used by this specification is
        implemented in TLS.  This specification also removes all cryptographic
        primitives from the application-layer protocol (RADIUS) being
        transported by TLS.  As discussed in the following section, this
        specification also bans the development of all new cryptographic or
        crypto-agility methods in the RADIUS protocol.</t>
      </section>

      <section anchor="error-cause-attribute">
        <name>Error-Cause Attribute</name>

        <t>The Error-Cause attribute is defined in <xref
        target="RFC5176"/>. The "Table of Attributes" section given in <xref
        section="3.6" sectionFormat="comma" target="RFC5176"/> permits that
        attribute to appear in CoA-NAK and Disconnect-NAK packets.  As no
        other packet type is listed, the implication is that the Error-Cause
        attribute cannot appear in any other packet.  <xref target="RFC7930"/>
        also permits Error-Cause to appear in Protocol-Error packets.</t>

        <t>However, <xref section="2.6.1" sectionFormat="comma"
        target="RFC5080"/> suggests that Error-Cause may appear in
        Access-Reject packets.  No explanation is given for this change from
        <xref target="RFC5176"/>.  There is not even an acknowledgment that
        this suggestion is a change from any previous specification.  We
        correct that issue here.</t>

        <t>This specification updates <xref target="RFC5176"/> to allow the
        Error-Cause attribute to appear in Access-Reject packets.  It is RECOMMENDED
        <bcp14>RECOMMENDED</bcp14> that implementations include the
        Error-Cause attribute in Access-Reject packets where appropriate.</t>

        <t>That is, the reason for sending the Access-Reject packet (or the
        Protocol-Error packet) may match a defined Error-Cause value.  In that
        case, it is useful for implementations to send an Error-Cause
        attribute with that value.  This behavior can help RADIUS system
        administrators debug issues in complex proxy chains.</t>

        <t>For example, a proxy may normally forward Access-Request packets which
        that contain EAP-Message attributes.  The proxy can determine if the
        contents of the EAP-Message are invalid.  On  One example of an invalid
        EAP-Message is where the first octet has value larger than 4.  In that
        case, there may be no benefit to forwarding the packet, as the home
        server will reject it.  It may then then be possible for the proxy (with
        the knowledge and consent of involved parties) to immediately reply
        with an Access-Reject containing an Error-Cause attribute with value
        202 for "Invalid (Invalid EAP Packet (Ignored)".</t> (Ignored)).</t>

        <t>Another possibility is that if a proxy is configured to forward
        packets for a particular realm, but it has determined that there are
        no available connections to the next hop for that realm.  In that
        case, it may be possible for the proxy (again (again, with the knowledge and
        consent of involved parties) to reply with an Access-Reject containing
        an Error-Cause attribute with value 502 for "Request (Request Not Routable (Proxy)"</t>
        (Proxy)).</t>

        <t>These examples are given only for illustrative and informational
        purposes.  While it is useful to return an informative value for the
        Error-Cause attribute, proxies can only modify the traffic they
        forward with the explicit knowledge and consent of all involved
        parties.</t>
      </section>

      <section anchor="future-standards">
        <name>Future Standards</name>

        <t>Future work may define new attributes, packet types, etc.  It is
        important to be able to do such work without requiring that every new
        standard mention RADIUS/1.1 explicitly.  This document defines
        RADIUS/1.1 as having functional overlap with legacy RADIUS: the
        protocol state machine is unchanged, the packet header Code field is
        unchanged, and the attribute format is largely unchanged.  As a
        result, any new packet Code or attribute defined for RADIUS is
        explicitly compatible with RADIUS/1.1: RADIUS/1.1; the field contents and meanings
        are identical.  The only difference between the two protocols is that
        obfuscated attributes in RADIUS are not obfuscated in RADIUS/1.1, and
        this document defines how that mapping is done.</t>

        <t>Any future specification only needs to mention RADIUS/1.1 only if it
        adds fields to the RADIUS/1.1 packet header.  Otherwise, transport
        considerations for RADIUS/1.1 are identical to RADIUS over (D)TLS.</t>

        <t>We reiterate that this specification defines a new transport
        profile for RADIUS.  It does not define a completely new protocol.
        Any future specification which that defines a new attribute MUST
        <bcp14>MUST</bcp14> define it for RADIUS/UDP first, after which and afterwards those
        definitions can be applied to this transport profile.</t>

        <t>New specifications MAY <bcp14>MAY</bcp14> define new attributes which that
        use the obfuscation methods for User-Password as defined in <xref
        section="5.2" sectionFormat="comma" target="RFC2865"/>, target="RFC2865"/> or for
        Tunnel-Password as defined in <xref section="3.5"
        sectionFormat="comma" target="RFC2868"/>.  There is no need for those
        specifications to describe how those new attributes are transported in
        RADIUS/1.1.  Since RADIUS/1.1 does not use MD5, any obfuscated
        attributes will by definition be transported as their underlying data type,
        type "text" (<xref section="3.4" sectionFormat="comma"
        target="RFC8044"/>) or "string" (<xref section="3.5"
        sectionFormat="comma" target="RFC8044"/>).</t>

        <t>New RADIUS specifications MUST NOT <bcp14>MUST NOT</bcp14> define attributes which
        that can only be transported via RADIUS over TLS.  The RADIUS
        protocol has no way to signal the security requirements of individual
        attributes.  Any existing implementation will handle these new
        attributes as "invalid attributes" (<xref section="2.8"
        sectionFormat="comma" target="RFC6929"/>), target="RFC6929"/>) and could forward them over
        an insecure link.  As RADIUS security and signaling is hop-by-hop,
        there is no way for a RADIUS client or server to even know if such
        forwarding is taking place.  For these reasons and more, it is
        therefore inappropriate to define new attributes which that are only secure
        if they use a secure transport layer.</t>

        <t>The result is that specifications do not need to mention this
        transport profile, profile or make any special provisions for dealing with it.
        This specification defines how RADIUS packet encoding, decoding,
        authentication, and verification are performed when using RADIUS/1.1.
        So long as any future specification uses the existing encoding, etc. schemes for
        encoding, decoding, etc., that are defined for RADIUS, no additional
        text in future documents is necessary in order to be compatible with
        RADIUS/1.1.</t>

        <t>We note that it is theoretically possible for future standards to
        define new cryptographic primitives for use with RADIUS/UDP.  In that
        case, those documents would likely have to describe how to transport
        that data in RADIUS/1.1.  We believe that such standards are unlikely
        to be published, as other efforts in the RADEXT working group Working Group are
        forbidding such updates to RADIUS.</t>
      </section>
    </section>

    <section anchor="implementation-status">
      <name>Implementation Status</name>
      <t>(This section to be removed by the RFC editor.)</t>
      <t>This specification is being implemented (client and server) in the FreeRADIUS project which is hosted on GitHub at https://github.com/FreeRADIUS/freeradius-server/tree/v3.2.x  The code implementation "diff" is approximately 1,000 lines, including build system changes and changes to configuration parsers.</t>
    </section>
    <section anchor="privacy-considerations">
      <name>Privacy Considerations</name>
      <t>This specification requires secure transport for RADIUS.  RADIUS/1.1.
      RADIUS/1.1 has all of the privacy benefits of RADIUS/TLS <xref
      target="RFC6614"/> and RADIUS/DTLS <xref target="RFC7360"/>, target="RFC7360"/> and none of
      the privacy or security issues of RADIUS/UDP <xref target="RFC2865"/> or
      RADIUS/TCP <xref target="RFC6613"/>.</t>
    </section>

    <section anchor="security-considerations">
      <name>Security Considerations</name>

      <t>The primary focus of this document is addressing security
      considerations for RADIUS.  This specification relies on TLS and
      associated ALPN negotiation for much of its security.  We refer the
      reader to <xref target="RFC8446"/> and <xref target="RFC7360"/> for
      discussions of the security of those protocols.  The discussion in this
      section is limited to issues unique to this specification.</t>

      <t>Implementations should rely on the underlying TLS library to perform
      ALPN version negotiation.  That is, implementations should supply a list
      of permitted ALPN strings to the TLS library, and let it return the
      negotiated value.</t>

      <t>There are few other opportunities for security issues.  If an
      implementation gets ALPN negotiation wrong, then the wrong application
      data will be transported inside of TLS.  While RADIUS/1.0 and RADIUS/1.1
      share similar packet formats, the protocols are not mutually
      compatible.</t>

      <t>When an implementation receives the packets for a RADIUS version which
      that is not supported by this connection, it will not be able to
      process the packets.  Implementations can produce log messages
      indicating that the application-layer data is unexpected, unexpected and close the
      connection. In addition, the implementations which that see the incorrect
      application data already have full access to all secrets, passwords,
      etc. being transported, so any protocol differences do not result in any
      security issue. issues.  Since all of the application data is protected by TLS,
      there is no possibility for an attacker to obtain any extra data as a
      result of this misconfiguration.</t>

      <t>RADIUS/1.0 requests sent over a RADIUS/1.1 connection may be accepted
      by the RADIUS/1.1 server, as the server will ignore the ID field, field and
      try to use portions of the Request Authenticator as a Token.  However,
      the reply from the RADIUS/1.1 server will fail the Response
      Authenticator validation by the RADIUS/1.0 client.  The  Therefore, the responses will therefore
      be dropped.  The client will generally log these failures, and
      an administrator will address the issue.</t>

      <t>RADIUS/1.1 requests sent over a RADIUS/1.0 connection will generally
      be discarded the by the RADIUS/1.0 server, as the packets will fail the
      Request Authenticator checks.  That is, all request packets such as
      Accounting-Request, CoA-Request, and Disconnect-Request will be
      discarded by the server.  For Access-Request packets containing
      EAP-Message, the packets will be missing Message-Authenticator, Message-Authenticator and will
      therefore be discarded by the server.  Other Access-Request packets that
      contain obfuscated attributes such as User-Password will have those
      attributes decoded to nonsense, and will thus result resulting in Access-Reject
      responses.</t>

      <t>RADIUS/1.1 Access-Request packets containing non-obfuscated
      attributes such as CHAP-Password may be accepted by a RADIUS/1.0 server server,
      but the response will contain a Response Authenticator (i.e. (i.e., MD5 hash), hash)
      and not a Token which that matches the Token in the request.  A similar
      analysis applies for Access-Request packets containing Service-Type =
      Authorize-Only.</t>

      <t>In conclusion, any mismatch of versions between client and server
      will result in most request packets being discarded by the server, server and
      all response packets being discarded by the client.  The  Therefore, the two protocols
      are therefore incompatible, incompatible and safe from misconfigurations or erroneous
      implementations.</t>
    </section>

    <section anchor="iana-considerations">
      <name>IANA Considerations</name>

      <t>IANA is requested to update has updated the "TLS Application-Layer Protocol
      Negotiation (ALPN) Protocol IDs" registry with two new entries:</t>
      <artwork><![CDATA[
Protocol: RADIUS/1.0
Id. Sequence: 0x72

      <dl newline="false" spacing="compact">
	<dt>Protocol:</dt><dd>RADIUS/1.0</dd>
	<dt>Identification Sequence:</dt><dd>0x72 0x61 0x64 0x69 0x75 0x73 0x2f 0x31 0x2e 0x30
    ("radius/1.0")
Reference:  This document

Protocol: RADIUS/1.1
Id. Sequence: 0x72 ("radius/1.0")</dd>
	<dt>Reference:</dt><dd>RFC 9765</dd>
      </dl>

      <dl newline="false" spacing="compact">
	<dt>Protocol:</dt><dd>RADIUS/1.1</dd>
	<dt>Identification Sequence:</dt><dd>0x72 0x61 0x64 0x69 0x75 0x73 0x2f 0x31 0x2e 0x31
    ("radius/1.1")
Reference:  This document
]]></artwork>
    </section>
    <section anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>Thanks to Bernard Aboba, Karri Huhtanen, Heikki Vatiainen, Alexander Clouter, Michael Richardson, Hannes Tschofenig, Matthew Newton, and Josh Howlett for reviews and feedback.</t>
    </section>
    <section anchor="changelog">
      <name>Changelog</name>
      <t>(This section to be removed by the RFC editor.)</t>
      <t>draft-dekok-radext-sradius-00</t>
      <ul empty="true">
        <li>
          <t>Initial Revision</t>
        </li>
      </ul>
      <t>draft-dekok-radext-radiusv11-00</t>
      <ul empty="true">
        <li>
          <t>Use ALPN from RFC 7301, instead of defining a new port.  Drop the name "SRADIUS".</t>
          <t>Add discussion of Original-Packet-Code</t>
        </li>
      </ul>
      <t>draft-dekok-radext-radiusv11-01</t>
      <ul empty="true">
        <li>
          <t>Update formatting.</t>
        </li>
      </ul>
      <t>draft-dekok-radext-radiusv11-02</t>
      <ul empty="true">
        <li>
          <t>Add Flag field and description.</t>
          <t>Minor rearrangements and updates to text.</t>
        </li>
      </ul>
      <t>draft-dekok-radext-radiusv11-03</t>
      <ul empty="true">
        <li>
          <t>Remove Flag field and description based on feedback and expected use-cases.</t>
          <t>Use "radius/1.0" instead of "radius/1"</t>
          <t>Consistently refer to the specification as "RADIUSv11", and consistently quote the ALPN name as "radius/1.1"</t>
          <t>Add discussion of future attributes and future crypto-agility work.</t>
        </li>
      </ul>
      <t>draft-dekok-radext-radiusv11-04</t>
      <ul empty="true">
        <li>
          <t>Remove "radius/1.0" as it is unnecessary.</t>
          <t>Update Introduction with more historical background, which motivates the rest of the section.</t>
          <t>Change Identifier field to be reserved, as it is entirely unused.</t>
          <t>Update discussion on clear text passwords.</t>
          <t>Clarify discussion of Status-Server, User-Password, and Tunnel-Password.</t>
          <t>Give high level summary of ALPN, clear up client / server roles, and remove "radius/1.0" as it is unnecessary.</t>
          <t>Add text on RFC6421.</t>
        </li>
      </ul>
      <t>draft-dekok-radext-radiusv11-05</t>
      <ul empty="true">
        <li>
          <t>Clarify naming.  "radius/1.1" is the ALPN name.  "RADIUS/1.1" is the transport profile.</t>
          <t>Clarify that future specifications do not need to make provisions for dealing with this transport profile.</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Typos and word smithing.</t>
          <t>Define and use "RADIUS over TLS" instead of RADIUS/(D)TLS.</t>
          <t>Many cleanups and rework based on feedback from Matthew Newton.</t>
        </li>
      </ul>
      <t>draft-ietf-radext-radiusv11-00</t>
      <ul empty="true">
        <li>
          <t>No changes from previous draft.</t>
        </li>
      </ul>
      <t>draft-ietf-radext-radiusv11-01</t>
      <ul empty="true">
        <li>
          <t>Move to "experimental" based on WG feedback.</t>
          <t>Many cleanups based on review from Matthew Newton</t>
          <t>Removed requirement for supporting TLS-PSK.</t>
          <t>This document does not deprecate new cryptographic work in RADIUS.  The "deprecating insecure transports" document does that.</t>
        </li>
      </ul>
      <t>draft-ietf-radext-radiusv11-02</t>
      <ul empty="true">
        <li>
          <t>Note that we also update RFC 7930</t>
          <t>Minor updates to text.</t>
          <t>Add text explaining why "allow" is the default, and how to upgrade to "require"</t>
          <t>Discuss the use of the TLS alert "no_application_protocol" (120), and its limitations.</t>
          <t>Suggest the use of Protocol-Error as an application signal when it is not possible to send a "no_application_protocol" TLS alert.</t>
          <t>Update discussion of Message-Authenticator, and suggest that RADIUS/1.1 proxies always add Message-Authenticator to Access-Request packets being sent over UDP or TCP.</t>
          <t>Add term "historic RADIUS/TLS" as it is simpler than more awkward "6614 or 7360".</t>
          <t>Re-add ALPN "radius/1.0" based on comments from Heikki.  It signals that the system is ALPN-capable, among other.</t>
        </li>
      </ul>
      <t>draft-ietf-radext-radiusv11-03</t>
      <ul empty="true">
        <li>
          <t>Rename to "RADIUS ALPN and removing MD5"</t>
          <t>Add a few things missed when re-adding "radius/1.0"</t>
          <t>Clarify wording in a number of places.</t>
        </li>
      </ul>
      <t>draft-ietf-radext-radiusv11-04</t>
      <ul empty="true">
        <li>
          <t>Address github issues 3..9</t>
        </li>
      </ul>
      <t>draft-ietf-radext-radiusv11-05</t>
      <ul empty="true">
        <li>
          <t>Add discussion of Protocol-Error as per-link signalling.</t>
        </li>
      </ul>
      <t>draft-ietf-radext-radiusv11-06</t>
      <ul empty="true">
        <li>
          <t>Review from Paul Wouters</t>
          <t>Clarify client handling of Protocol-Error</t>
        </li>
      </ul>
      <t>draft-ietf-radext-radiusv11-07</t>
      <ul empty="true">
        <li>
          <t>Clarifications as requested by Jan-Frederik</t>
        </li>
      </ul>
      <t>draft-ietf-radext-radiusv11-08</t>
      <ul empty="true">
        <li>
          <t>Review from Claudio Allocchio</t>
        </li>
      </ul>
      <t>draft-ietf-radext-radiusv11-09</t>
      <ul empty="true">
        <li>
          <t>Review from Barry Lieba</t>
        </li>
      </ul>
      <t>draft-ietf-radext-radiusv11-10</t>
      <ul empty="true">
        <li>
          <t>AD review.</t>
        </li>
      </ul>
      <t>draft-ietf-radext-radiusv11-11</t>
      <ul empty="true">
        <li>
          <t>Review from Eric Vyncke</t>
        </li>
      </ul> ("radius/1.1")</dd>
	<dt>Reference:</dt><dd>RFC 9765</dd>
      </dl>
    </section>

  </middle>

  <back>
    <references>
      <name>References</name>

      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <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="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="RFC6421">
          <front>
            <title>Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)</title>
            <author fullname="D. Nelson" initials="D." role="editor" surname="Nelson"/>
            <date month="November" year="2011"/>
            <abstract>
              <t>This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6421"/>
          <seriesInfo name="DOI" value="10.17487/RFC6421"/>
        </reference>
        <reference anchor="RFC6929">
          <front>
            <title>Remote Authentication Dial In User Service (RADIUS) Protocol Extensions</title>
            <author fullname="A. DeKok" initials="A." surname="DeKok"/>
            <author fullname="A. Lior" initials="A." surname="Lior"/>
            <date month="April" year="2013"/>
            <abstract>
              <t>The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6929"/>
          <seriesInfo name="DOI" value="10.17487/RFC6929"/>
        </reference>
        <reference anchor="RFC6614">
          <front>
            <title>Transport Layer Security (TLS) Encryption for RADIUS</title>
            <author fullname="S. Winter" initials="S." surname="Winter"/>
            <author fullname="M. McCauley" initials="M." surname="McCauley"/>
            <author fullname="S. Venaas" initials="S." surname="Venaas"/>
            <author fullname="K. Wierenga" initials="K." surname="Wierenga"/>
            <date month="May" year="2012"/>
            <abstract>
              <t>This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6614"/>
          <seriesInfo name="DOI" value="10.17487/RFC6614"/>
        </reference>
        <reference anchor="RFC7301">
          <front>
            <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
            <author fullname="S. Friedl" initials="S." surname="Friedl"/>
            <author fullname="A. Popov" initials="A." surname="Popov"/>
            <author fullname="A. Langley" initials="A." surname="Langley"/>
            <author fullname="E. Stephan" initials="E." surname="Stephan"/>
            <date month="July" year="2014"/>
            <abstract>
              <t>This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7301"/>
          <seriesInfo name="DOI" value="10.17487/RFC7301"/>
        </reference>
        <reference anchor="RFC7360">
          <front>
            <title>Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS</title>
            <author fullname="A. DeKok" initials="A." surname="DeKok"/>
            <date month="September" year="2014"/>
            <abstract>
              <t>The RADIUS protocol defined in RFC 2865 has limited support for authentication and encryption of RADIUS packets. The protocol transports data in the clear, although some parts of the packets can have obfuscated content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can coexist with current RADIUS systems.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7360"/>
          <seriesInfo name="DOI" value="10.17487/RFC7360"/>
        </reference>
        <reference anchor="RFC8044">
          <front>
            <title>Data Types in RADIUS</title>
            <author fullname="A. DeKok" initials="A." surname="DeKok"/>
            <date month="January" year="2017"/>
            <abstract>
              <t>RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least the publication of RFC 2865. We provide an IANA registry for the data types and update the "RADIUS Attribute Types" registry to include a Data Type field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8044"/>
          <seriesInfo name="DOI" value="10.17487/RFC8044"/>
        </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.2865.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6421.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6929.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6614.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7360.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8044.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>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1321.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2548.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2866.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2868.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3539.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3579.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5176.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6151.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6218.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6613.xml"/>
        <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.7593.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7930.xml"/>

	<reference anchor="RFC1321">
          <front>
            <title>The MD5 Message-Digest Algorithm</title>
            <author fullname="R. Rivest" initials="R." surname="Rivest"/>
            <date month="April" year="1992"/>
            <abstract>
              <t>This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1321"/>
          <seriesInfo name="DOI" value="10.17487/RFC1321"/>
        </reference>
        <reference anchor="RFC2548">
          <front>
            <title>Microsoft Vendor-specific RADIUS Attributes</title>
            <author fullname="G. Zorn" initials="G." surname="Zorn"/>
            <date month="March" year="1999"/>
            <abstract>
              <t>This document describes the set of Microsoft vendor-specific RADIUS attributes. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2548"/>
          <seriesInfo name="DOI" value="10.17487/RFC2548"/>
        </reference>
        <reference anchor="RFC2866">
          <front>
            <title>RADIUS Accounting</title>
            <author fullname="C. Rigney" initials="C." surname="Rigney"/>
            <date month="June" year="2000"/>
            <abstract>
              <t>This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2866"/>
          <seriesInfo name="DOI" value="10.17487/RFC2866"/>
        </reference>
        <reference anchor="RFC2868">
          <front>
            <title>RADIUS Attributes for Tunnel Protocol Support</title>
            <author fullname="G. Zorn" initials="G." surname="Zorn"/>
            <author fullname="D. Leifer" initials="D." surname="Leifer"/>
            <author fullname="A. Rubens" initials="A." surname="Rubens"/>
            <author fullname="J. Shriver" initials="J." surname="Shriver"/>
            <author fullname="M. Holdrege" initials="M." surname="Holdrege"/>
            <author fullname="I. Goyret" initials="I." surname="Goyret"/>
            <date month="June" year="2000"/>
            <abstract>
              <t>This document defines a set of RADIUS (Remote Authentication Dial In User Service) attributes designed to support the provision of compulsory tunneling in dial-up networks. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2868"/>
          <seriesInfo name="DOI" value="10.17487/RFC2868"/>
        </reference>
        <reference anchor="RFC3539">
          <front>
            <title>Authentication, Authorization and Accounting (AAA) Transport Profile</title>
            <author fullname="B. Aboba" initials="B." surname="Aboba"/>
            <author fullname="J. Wood" initials="J." surname="Wood"/>
            <date month="June" year="2003"/>
            <abstract>
              <t>This document discusses transport issues that arise within protocols for Authentication, Authorization and Accounting (AAA). It also provides recommendations on the use of transport by AAA protocols. This includes usage of standards-track RFCs as well as experimental proposals. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3539"/>
          <seriesInfo name="DOI" value="10.17487/RFC3539"/>
        </reference>
        <reference anchor="RFC3579">
          <front>
            <title>RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)</title>
            <author fullname="B. Aboba" initials="B." surname="Aboba"/>
            <author fullname="P. Calhoun" initials="P." surname="Calhoun"/>
            <date month="September" year="2003"/>
            <abstract>
              <t>This document defines Remote Authentication Dial In User Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method- specific code, which resides on the RADIUS server. While EAP was originally developed for use with PPP, it is now also in use with IEEE 802. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3579"/>
          <seriesInfo name="DOI" value="10.17487/RFC3579"/>
        </reference>
        <reference anchor="RFC5176"> anchor="FIPS-140-3" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf">
	<front>
            <title>Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)</title>
            <author fullname="M. Chiba" initials="M." surname="Chiba"/>
            <author fullname="G. Dommety" initials="G." surname="Dommety"/>
            <author fullname="M. Eklund" initials="M." surname="Eklund"/>
            <author fullname="D. Mitton" initials="D." surname="Mitton"/>
            <author fullname="B. Aboba" initials="B." surname="Aboba"/>
            <date month="January" year="2008"/>
            <abstract>
              <t>This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5176"/>
          <seriesInfo name="DOI" value="10.17487/RFC5176"/>
        </reference>
        <reference anchor="RFC6151">
          <front>
            <title>Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</title>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <author fullname="L. Chen" initials="L." surname="Chen"/>
            <date month="March" year="2011"/>
            <abstract>
              <t>This document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6151"/>
          <seriesInfo name="DOI" value="10.17487/RFC6151"/>
        </reference>
        <reference anchor="RFC6218">
          <front>
            <title>Cisco Vendor-Specific RADIUS Attributes
	<title>Security Requirements for the Delivery of Keying Material</title>
            <author fullname="G. Zorn" initials="G." surname="Zorn"/>
            <author fullname="T. Zhang" initials="T." surname="Zhang"/>
            <author fullname="J. Walker" initials="J." surname="Walker"/>
            <author fullname="J. Salowey" initials="J." surname="Salowey"/>
            <date month="April" year="2011"/>
            <abstract>
              <t>This document defines a set of vendor-specific RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication Cryptographic Modules</title>
	<author>
	<organization abbrev="NIST">National Institute of any RADIUS message. These attributes have been allocated from the Cisco vendor-specific space and have been implemented by multiple vendors. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6218"/>
          <seriesInfo name="DOI" value="10.17487/RFC6218"/>
        </reference>
        <reference anchor="RFC6613">
          <front>
            <title>RADIUS over TCP</title>
            <author fullname="A. DeKok" initials="A." surname="DeKok"/>
            <date month="May" year="2012"/>
            <abstract>
              <t>The Remote Authentication Dial-In User Server (RADIUS) protocol has, until now, required the User Datagram Protocol (UDP) as the underlying transport layer. This document defines RADIUS over the Transmission Control Protocol (RADIUS/TCP), in order to address handling issues related to RADIUS over Transport Layer Security (RADIUS/TLS). It permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security. This document defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6613"/>
          <seriesInfo name="DOI" value="10.17487/RFC6613"/>
        </reference>
        <reference anchor="RFC7585">
          <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>
          </front>
          <seriesInfo name="RFC" value="7585"/>
          <seriesInfo name="DOI" value="10.17487/RFC7585"/>
        </reference>
        <reference anchor="RFC7593">
          <front>
            <title>The eduroam Architecture for Network Roaming</title>
            <author fullname="K. Wierenga" initials="K." surname="Wierenga"/>
            <author fullname="S. Winter" initials="S." surname="Winter"/>
            <author fullname="T. Wolniewicz" initials="T." surname="Wolniewicz"/>
            <date month="September" year="2015"/>
            <abstract>
              <t>This document describes the architecture of the eduroam service for federated (wireless) network access in academia. The combination of IEEE 802.1X, the Extensible Authentication Protocol (EAP), and RADIUS that is used in eduroam provides a secure, scalable, and deployable service for roaming network access. The successful deployment of eduroam over the last decade in the educational sector may serve as an example for other sectors, hence this document. In particular, the initial architectural choices and selection of standards are described, along with the changes that were prompted by operational experience.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7593"/>
          <seriesInfo name="DOI" value="10.17487/RFC7593"/>
        </reference>
        <reference anchor="RFC7930">
          <front>
            <title>Larger Packets for RADIUS over TCP</title>
            <author fullname="S. Hartman" initials="S." surname="Hartman"/> Technology</organization>
      </author>
	<date month="August" year="2016"/>
            <abstract>
              <t>The RADIUS-over-TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum size limit of a RADIUS packet proves problematic. This specification extends the RADIUS-over-TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action that required IESG approval.</t>
            </abstract> month="March" year="2019"/>
      </front>
	<seriesInfo name="RFC" value="7930"/> name="NIST FIPS" value="140-3"/>
	<seriesInfo name="DOI" value="10.17487/RFC7930"/> value="10.6028/NIST.FIPS.140-3"/>
      </reference>

        <reference anchor="EDUROAM" target="https://eduroam.org">
          <front>
            <title>eduroam</title>
            <author initials="" surname="eduroam" fullname="eduroam">
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>

        <reference anchor="OPENROAMING" target="https://wballiance.com/openroaming/">
          <front>
            <title>OpenRoaming: One global Wi-Fi network</title>
            <author initials="W. B." surname="Alliance" fullname="Wireless
            <author>
              <organization>Wireless Broadband Alliance">
              <organization/> Alliance</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>

        <reference anchor="ASLEAP" target="https://github.com/joswr1ght/asleap">
          <front>
            <title>asleap - recovers weak LEAP and PPTP passwords</title>
            <author initials="J." surname="Wright" fullname="Joshua Wright">
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="RFC5077">
          <front>
            <title>Transport Layer Security (TLS) Session Resumption without Server-Side State</title>
            <author fullname="J. Salowey" initials="J." surname="Salowey"/>
            <author fullname="H. Zhou" initials="H." surname="Zhou"/>
            <author fullname="P. Eronen" initials="P." surname="Eronen"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
	    <author/>
	    <date month="January" year="2008"/>
            <abstract>
              <t>This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5077"/>
          <seriesInfo name="DOI" value="10.17487/RFC5077"/>
        </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 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> month="November" year="2020"/>
          </front>
          <seriesInfo name="RFC" value="5931"/>
          <seriesInfo name="DOI" value="10.17487/RFC5931"/>
	  <refcontent>commit 254acab</refcontent>
        </reference>
        <reference anchor="RFC5281">
          <front>
            <title>Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)</title>
            <author fullname="P. Funk" initials="P." surname="Funk"/>
            <author fullname="S. Blake-Wilson" initials="S." surname="Blake-Wilson"/>
            <date month="August" year="2008"/>
            <abstract>
              <t>EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5077.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.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.5281.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5080.xml"/>

      </references>
    </references>

    <section anchor="acknowledgments" numbered="false">
      <name>Acknowledgments</name>
      <t>Thanks to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange. This memo provides information <contact fullname="Bernard Aboba"/>, <contact
      fullname="Karri Huhtanen"/>, <contact fullname="Heikki Vatiainen"/>,
      <contact fullname="Alexander Clouter"/>, <contact fullname="Michael
      Richardson"/>, <contact fullname="Hannes Tschofenig"/>, <contact
      fullname="Matthew Newton"/>, and <contact fullname="Josh Howlett"/> for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5281"/>
          <seriesInfo name="DOI" value="10.17487/RFC5281"/>
        </reference>
        <reference anchor="RFC5080">
          <front>
            <title>Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes</title>
            <author fullname="D. Nelson" initials="D." surname="Nelson"/>
            <author fullname="A. DeKok" initials="A." surname="DeKok"/>
            <date month="December" year="2007"/>
            <abstract>
              <t>This document describes common issues seen in Remote Authentication Dial In User Service (RADIUS) implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5080"/>
          <seriesInfo name="DOI" value="10.17487/RFC5080"/>
        </reference>
        <reference anchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246,
      reviews and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
      </references>
    </references> feedback.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAHJjEmcAA+29a3MbV5Yg+B2/Ihf+0GQPQPEhypJix90sUSqry3qsSJd7
YmO2IgEkyCwBmejMBCmUy/Nb5rfsL9vzvufeTJCyyxMbHTHsLpkEMu/j3HPP
+zGdTkdd2a2Kl9mni8u3P149OTk6mWQ/FHdFk9+U1U128cPH91lXZ02xru+K
7N3l+SifzZriTt+4OzkZLep5la9hkEWTL7tpWXTLaZMvii8d/qfctvDQFJ7b
bhZ5V7Qvs9Pnz84n+O+zSXZ+8i38++zZyRn9+3SSfXv27Hg0aru8WvwlX9UV
DNw122JUbhr6re1Oj49fHJ+O8qbIX2Zvq65oqqIb3d/Qol7/+3X2U918xuX/
sam3m9Hn+/DU9BLXOJrn3cus+LIZtdvZumzbsq6udxuY6e3r6zej0aZ8Ocpg
3/OX2a5o4de2brqmWMLas+ybbFEs8+2qaxEy8v1uzV/jn6N8293WzcvRaJqV
FXx4cZRdFn+qP8ODDKiLVV7ZR3UDC3/TFAVDFD4p1nm5epnl8NTiX5fwDYPx
CJ4cjaq6WeddeVfgEj+9efX85Nun8ivCVX599vT0RH99cfpCfwUAy6/fnh2f
2K/PjnWw46fwwKislsksJ2c23un50+dhwmfhV/307Pzshf36rf6KB63LODm3
xZ2ePA+LO9MVnT8/t19f2Kcvzmidry9//PTh4h3+Cj+CwONisW3qfD3mT/UI
Mv5hsMsj/CHv0J64/vdrONzbrtu0L588kScJ4ln24ePr9zjj2/d/TCb9sCmq
T/AgINvL7ENVZDerepavsp/K6ZsyA3y7B0x8aEk/lU2xKto2+wPMt5jBgQNy
rMq8mhdfscx7mIsfPprX6yc1rKbh1TyBFy6ufnh98TFZcd6uinyTTeFKz+FK
N212X+SfM3wyw9k/frz+mG3ytoWVL9qHlv5vdXu7zbOfmvLmttu/WF3rTdnd
bme0zr/W7X1zAm894dWMRndFtSVUu8Ebq/cY/uabwNTkX5GyyJHwaPrN9P7m
yQPE5wiehss4nWb5rO2afA5/Xd+WbQaUa7suqg5vdFkVbXax2axKIA5AD6Y/
5LuiyT42NdCBepW9L27qrqSvstdfuqJCotHilrNtW2T3sCClotc/XBEs5c9L
+PsIoHFbwHNFeHVTNOuyy7rbAjAlDF4v4eUsDyvJNrqGu7yB0+7wER57ks0B
A4pFNg4EfAxzva+z+W1e3cCWgEoCFBcFEit56MfLj0B1bLWvPvLq/Npg1Pp+
cGlAgvOq3QBBxHUtyxXs/baASfBhHjJrb2HWRdYW86boMgB0VWdAyW8KgtVi
QtCBKZChTGc5fAQoN/8MzyKmwYHozum5rmvK2bYrsnq23LbyzboAlFzw9pg7
LY7SUxWGo6RxoiRrovRoonRHf3nKS4M/iA0dMdasy8ViVYxG3yAbaerFdo5L
wNlsx3ZEP/8ss/3yC+61xS3yh0hC4UM4BrfJQjbe8sTwpW6yyOZF0+VlFQDQ
wjldLBYlzg5EJjoImh0vM8CDsXlBuAmnmx3Q/LjPX345nGSInvbRU/oI574M
n+Pe4XOY7vv6HqWBCZxuDdg7NGXblXCSeAdwq+n2ympR3pWLLaxXdkrIliNa
TAhnYmS5z1vCkQxZ/w1fKxh3ksEyKsS0yiOaDMnbnhXI822JMAYA7+DykK/f
Bd+0rlwXPO8c8BzQfdsiWsuYKDzci/BApIjW0+FyO0QteKcrgVQtaL/wHm4Z
H8nn82LT5bNVgdsDQOKHbQGrxS+ztlxv4KKM7xu410UzBrStt0YhJrAvvEfb
FufNs2X5BQHi4SI3tAQxpuKbEbbDa6zdnZXF8d5l8HVOuwJegyPAszu8lUol
4HV8Ee5iOVfgFtW8XsA7E0Ao/S2+n4w4cnXv8lW5oI/h2rxt223RKoRgD9um
7HbZbX6H5wRg+VzV9xVhKAwO5AmQYV23Hf9T1QjKHZ4f4ykIDL/8wrPZZyDh
TLKrgu5idkZfrxFlalhh0wrAgLsSf8zgGVwJTmirAZDAGoEEw+nUIATC6SEg
EHoCApiMngYs3bVdsW4RmPNbHGZWLjysFyWAEejX6qaGsW/xSURd3ubdtgIZ
blau4OrSLX4Dyyi+5IgUk+zN249X05OnxzJqa3Mtm3qNO9jhwcEGQJjkxcyb
3aarbwCZYDVGCv3e4Ah+omN3S8T9w4YckyLK3MkiYeezwuaYIFzmwIjgs0W5
XJZzkHhpCnejgRfnVfk3OnTCIcBtlAFogY0tMAdqtWsLu2iBdsjNKna4RoDL
W+IW6y2AmK9MQ2e+rht8Cxg3IN4KJ6JvdxmQpnK5s2GasH45EAAmDpYzHUZm
gRtmAlPt7uUVpkMEdcYb2PaOyWjJeB4eYJYD84Hkwqg6CD+8A3BLhVpPHj4H
Lyz8cH2FrxHPNEwFsG+a8i6fw6+wZ94wgBHOAXYCa2UaBzPewvG0KJHxlHC5
ylZY914aRwoesRq9IkDrOsDjuV8kUplV+RnQMbtv4KLxcRHxqzKAxS5MBgPi
3TLI3iLHAAVsPcmAjyFm3cJr85zOAYaqcS2wHbiAdsW6iJUDRBokXXqvWSLl
XfnnNiuQ2uBsgSjBlDQ/QAq2AuosYI6ucCKT0AW4x3Ob1w1IxB1DMxqzJ1ao
sAjb/kp58QD16MNMeOsxigEmaxG8hdzQ2QaqDQtk0aYVSaxYKH3Sg+KHdTv3
BcmDTpsncMHi2w3sfKliFRO+mPyLUIjygrFQAXYYLsg5TBrgAgDsgJMBxe3q
esHcri8hpnukNTc5Xlk8IbgosIN6VUzbfIVE+y5FWi9jwYFcRdSYKAUdDR1c
f3qhY0RGAFNLpRwlAxS+MhoM+skGWQbu/QIGAP4B+lTe7MIsDEPEYEDse0Wx
CgaFJ2GjwCuLSPxuiv/Ylg3P1W43tDQHU7owG5H7iy9w9fA6uJvXFg0CLV6A
njlMABr7P8NimQ/QJAVLBysYC8eVSWEFZNAJ9HdWLGsR3XEiWPMCxA64uW0H
96elcZcdHVL6BN1gBFbRkUTvpv+PbYHwWvJs9CBKj3jKOrXw8iUaTHQnhlv3
9sYRruBVLKOIuEHSifAHkk9QSm1r4wUDkqfRfy+hijYClyEoGoBEPPyCuTgO
ZyRxQAshEuFE2tl29VmRN4K4YuKqWHa6H7o9zOOJJ0enrPc3EJ+ynW+REIbB
iy+MbEjuFkjHV/gbqO94bjWoyiBzEb9khAdZa96Um87U147kpJwAiKDwQOTP
YfqCRQUS4Ihf5AskF3L1VZ+DPTsid8QqEq8JZlZ01LtB8o3BFTYvuqBd4NYp
rXhTABA5rhkF3ZaxHgFQisqAm0nUVSIIRmsn+AoC+eToDFe/yhG34Qm9ofTA
BaszbUJ+Yj0lSLKiffLYSKbr++m2ogV9gmFJKkT+XsCWQDjILgLywRLgSFbA
7P1wm20D4iiTi3newFUCpKk3OYyVXdefSQ0isrfAYWAAXj9JOzhTIzO1tqTl
tpqz0kjCBG/rrb4ui6CLqktY5XNlhTopPSRqKjJ1uFQolAGtrrctEL8u/8xy
0+DgwmlhbUjMFjQMQ8lW+Q4YfH5TTGMAhVvJuimaFJ3cf3QKiqoKsqjaIO6D
aCd33ugMMPeixInh0fIGyLQetinXJin+CEucfhQTGKjL26oqVu4DHPHd1fTd
x4+vs8/FjskKTa1EAwYZd4B1Y1kzmlX9mlHpRvwb1yBxdO2+x85JN0cKVG87
kZwZ3M5w4siREgtPoSLjSwVAABg3u0mWMwEBhS3HZ1ho5WP5DJosi5sdsgYQ
EW9uvfyKzFvPDBTi+WrrmXWxXNLNRQaNlki+5aaygehTitzPWsw0vykJLU0k
xgdItFjUVZHdlTnwDZKIWHlWet0hrtHVXpDePygo/DPPjMYenpltQotYX37d
NHUzfYXyqMM3fAQmzFHlyS7mCLrpp+KvcDxmymACxwQJF1GagkAUHq4dkboF
A6FDi6QYbwapXRCTXiqAI0NHdsvkuOTDa/M1Uva/FeFWvkLZA//4oahugHMJ
eTkws1SkMh8KPdex1gWoc2iCUMnAzllcHtnTP+lScF4CqO4RFrFCTAVkYR7w
4uwYYI4cj01ExPfItRTk2FXeIGKqEUzJbzB5Ca2jdYoVRe0SsK1OuW7vhUWt
mh7Jyu5KpJvW4VjTHITARZswEuJEe+RcRNrxbb2BWz1flSSV1irCwXWpGPyH
pGAbX4WdgXZLhIvsF+5J5m2A63km45Gej+OJfE6yZ2ygIB31PifZLt8rFyMt
pPGzXKRAmYHEAF4yyOUMMOWsRWT3SOBSV6J7ob0Abo4wzbAbwajopa2KM3Qe
fBUOTo+fnz3p5htaC/2xXWwO3fa8ldMJy86wmRrhM2fchKsLEnP+V3h5VlQw
VDewG6VUeQBGpG+0aiTJV229V8PABfb0i3nh7aA2AQ4mztbciSFkAeXJEUPN
cII2WWdyyslMUt+R8cwMHZHNS4SLlq0FTIeBDE2y22DpLWy7eG2JsYrW8ur7
i48TxD9E1MRWL/I/r1JN34KhIM2Xc8IXOb/BV5Hgkh2VrtfqPgfe6iVlh/Q9
ldZuksjC+xeIIlXJxmE1v5IOoQOs4S/kfAconZFF7tAj/P6BlwIXMSQBgjFF
hxP5UhasGjRsra0Q1HDqIneK7so2HXzWqbQIcoQ4SBz0azw3AOOqzpZw00jz
xtd3GRuq5+jwXkSkEbTZnJRLACgPxqIM/94UalYTYZOEAyGxkV098DU5mQru
DGDQxkx4tFXSLc2ySuAZULRl0TiSEahBABtpLzbA88WiSzofuQrUUK8iDcwH
BHAhvD6+wYLPrVyhoMb9hCoPcPGGZR/RgrxhS68Cogegy+EDCEFqZIceXkAK
GBTWOc9V9WVki1FAKVCE2nqFarL9t4gLyqUEHUVGcI6yYFgZFqoPiMCX6xJp
dECQQ9OQ18ASkXh5DiM3S478MWldaWc54AB05k+0UY1GP1bkBKd135dtIUrq
jB+NzHGTLFi4PPBacpkyHkVUPPY39QmHWvMeNFsZYtOhVeFcq+I+NWoEC6E3
CsVGjMTME0RWmiclZj2Pl3ja3eW2T4puPkwhS7bXwB94G8mu4SAZkGCC7n8Y
aIO6WiUa1HLbsVH76wa27cXWjDZ4rvc4yR807JGdAa40ccklLn4G0ECQDtmr
QekDrCMDQQsaH+i+uJ5WfRSF02XpXuINW5Y320ac7uSdF60QJ8O5vhoAuLj0
jKOXxJDdFHI7yLirHGToBTKqi/NvjzgHMiKGZhCDVhM8OQlCqMIe8jJk3r5F
5UiIMjl1zCcWGWXMfLbcNkR2xEJlKiHSUB0j6KSqiTLNBVz3kqqtZchQbTrw
PrC+TuCe4iBijzpyxfxLREkVbaZ9Bp2f6JRs1ng6IpjFF/QClB1edj4hNXCw
sqnec41HcOSAaRbRicS3TQavQZGd/dy4ZHYykXtlwu87IZ1EcSd4Pz62onwK
MOSfd3W5YG83TuP5HbpuNIahbvh7U7fgy4EwBgyluMbJqnpV3+xYi/5c7DIK
OsrG7368uh5P+L/Z+w/0+6fX/9ePbz+9vsTfr76/+OEH+2UkT1x9/+HHHy7D
b+HNVx/evXv9/pJfhk+z6KPR+N3FfxszHo8/fLx+++H9xQ/jHuNhHUmcfCAh
AEZ0ZOsZRczqD68+/r//8+Qp6Br/B6rcJycvQBHhPzBUD/5ACPFsdu50OLtR
MDcg/Zjnm7IDzYKMNexqQFQ8Gv2f/wK0rMimz/7lu1FqgSAbqy6ItaouQJoD
aiiCs5TDDQqVcubU+8VW1tHou690d9F6VTtTd71ZhP9ZcBDHIwMHaDtdZBVF
EnFZ5qsp4Dba4rIrEN3KeeH5bH8CjrmZ2B/PNGDAG4CiCIHRd7AE9ZIjY0iM
9HdlcS/GPLs2x4AnpE+RPX2OGhXOofyHuAhzAjJqTdAl97koNiwlo3orY40d
KDAgC8HhPWT4PG3+EsTZmyZfB1Dv367bahIN4Sa7fjU42TWSA4mFzV7VGOi0
SubkCKJorB+u9o5FpIWx5Mq0z3S8p/F4l3sGNCA8PnKi5P9zNJYMfxF4rLqG
vHqjjyI5s+A95LjuIqnPoaxAYEFfyBLNX6ByUdRsMCYr6rCjdkwkcgwaBnJK
J6wEGwZOOPYz4lQ3BQaQYMwOc6pbstIvC9BkWZtDc+KKIBKJxM7vKoJj8O0i
bAbkphT84o4euHHOyOJh7pce7FtoJl4UUfiHH3BALnFoAexKyUWfa6WjBEVB
dD2UGhkUchhomiE0l2jJnwoX88O8sWbwMqVnZk1GFQZ1iJeLwSngu/6aKwDz
/tFOlQ70vpBJZZKBDRXiT9aT37M8wdtodd+krvzrB9QdFXPFAhnzE04K6Esm
6n1kHWZZNsCJbkqLXkDiZ/YoHMPkbz8BSp3q1FOBXKQpJ9uApNuzVPK0NBx7
JWBQCuMReVT9qxyZpvfznoTOGu3Fuq5ssSXgtgUTQ9CDtuuN4OQ33/Az73E7
zvRIKHqt0KHNDhgoh5yY32VjjlSm4F1kSoxBvWuigSnpNWEBVYFGamMAXN3o
h8EDVolDxQuHaj4W84Ylf6gIltyQ3rRhyok3JLPmZcPiHlpx2LBm1jVkyV+J
yB5HApB9VW01YopwhlIxFqLBnZ1PLUFtU7c4JbtCUbxmjQyUiW5+m8xM9Lhh
p44KAfR+8DL5MYBvuJcpRGS5XWHEwurzVF1lSZRb5JJGWl5iJOusgONH+T2R
tQneDDWeyiNH8OtTIF7ntZcyFvfFNUWGOTjZDV9PDGgLsSWCjUTsUNgJlw/j
w1rG9g+bojF3OguCb110gQShwdy35c3tFB08Kx9ioG/RijmaoCWfglqalvka
RKW8CZEWTEXaJJiAqF+YbdaUxZI4FK+cBOPRBwz1zAWZg0Pb3QdnwWMaJPap
RG+CTU+dCwbjYunawueRPMs46U8YljgHXT655CeHbMSTW1EgR8L4MY7fMH8D
K4Cv6KnvC3hZuWl4Bm9KyzjfsL9hKFWgVWOAJR7gH635eVzEuETb2eLwMq/y
ci2ShUALgHt66C+gkJNWzFkaYUHXRkKB5cvBVAZczgEaHG9yFKFCuJIGB9qR
HSGJfLv0foklBjlSyI6FXaPcvY4AQEF3CCSzKrLPbb6q1d8UXZezw+yDPhl5
QUDP2zao6pMiUjR0MGLnYkFO7UwODGTJSc8XrQ45X0FS/fAUERCLQRipAFMR
OvFVD7RODpTpVYjV4EP0MJNjXZRMzhxtYUNR2KhJa0JYffiSEMWhp4cIJKHe
aPQ0QvsIZRwsJwnCGKcaxJyDkqzeMeooOpUcBDIR6j8ne4KouEODRaFm3/Fd
m98W88+RkSqmuw6oeCi1hHmnUWwOVBQrWKwovtQSPXTPwc1gr1IwiRyoBv/x
nbewVYf5YlK2k/8VdJ9Fi31CV10N+4RtCxRaRjTIYrwi9QNJWtcmhlUyfChT
YR7zKnrAcwwvXTFZbIP7O5JWBkz7KCOAXIeu2SRSpGxUAHLz+lAXDdzmlCc0
8sfPUibWDKP3NQHrz6xTjJkVaUIVOvVJGHRcP9wcjegVHm7R0bATZ6ESH/QC
KHKJ6WuoYLLkv8znbE7kYHuOt3HfkGff/Dy0jnKAd2MmDIxMCB1UXGU9ulWi
Xg1S1lsJm0kiYlXW85EBIXWtzOlUWXDEtIpO3DE2fntbb1cLJZKBI8BYbJlE
7hxrcMRlq+16Bn9OsuIIRLIxGmlIyxbt7rq/0nW+k+if9XbVlRhUArcR1QIE
DwYd2fEiHU+f5O/Y3Kn6P266u68TNCGlE89tvV2P2cC4zr/IXzgs7Ei3wopo
DuoJHJNk1IW0hjZZFxMCNWUjvAIvor3Q6ooVYYCC0UsNBkEnAGybhiSA5FyD
AP52SFNnrmB+XobkJJLvmWJQjD3GJi4MT9GIGizpICj9D/gZ/RmHkCTSv8P/
aKgrGgqJvH7xNhoBU/V+w89oW2G4dJhs8OfvwZckGosG/R2NAOHccyauHycD
CGUctLnA0xO0RqRDTMLvJ/AFY6IctI4ziqfZu4FBaxOpcjJxuoGTZADdgH+V
jouNBTHmUwQHUF4RfoRPsRuxd4lL8RMFSWkGrBvFm+AnyrL3QIXlmlKetMoZ
7NGR0IUZ0e4QmYCoj4g74APqIocJPY06DEYeqoHI2G2IoAdWQiy/b3/oK3Pi
hzDlF98bclU6PyjnbFxtvfczUg0LDUnggDwCSHDtDXMpBMZYccyMizAUcU5M
gmwKcdfTGu1gzF2rNvGgJw3prhf/zfZK8m20p7eVEa22+A17oO3DEsZ+D7Pi
Nr8r2ciROHbIS8DMtKxS/+zAKfSGxC3TNhCnUHdt64pWoutmVxio/xQLUuTN
itjKocFMBJYQ3O2iT/uJIBySFklTIQVNpX4Dh/quXSwIf898LLUzxCLWn3UU
NGOh4CvSy4hJbzsiz4j4I21KivYkxu2NTeyI/E7M6k5ppgNDvjgEbHohli/4
oNBut2D+R8BHtABxxHwrmG9SAU0YuNSD4TN6CSnHy5sBJMCs5ViiwBg9lTfn
OMYUqXwTMkxiPomom29oKxJjYMamynvHKJMZSF5pASXCeFe7ZImxzY1NgywF
Z38QLIWP4P+/82qWmexoaxQL77VuJ4rRu6KJDY4oykcYkZXHh8fk12ON3VQ/
VYrpLY6KtpWTem5zkZ6equlIRkjgomeF5g9posHAjDeovRXVMjZ7Igncbrxv
Y0/yY9jWe4tUQDU0Nuh4U11kBaU4yrZwqp4aMviaU+Aj6pDwx414IyWlg/dA
A+wByBsJGpG4YZ4xoqGT5CUebu/NhItJhhClJQdj9nsGDjJhIszBRoe/Ci8J
J82w0JpMB3JvPWcDnBkC3WUQjgTbJSH/Dcv3uCoaMED+eBzO6jo5AUHC1Gqj
+TIBHVXNdUYce0jEaJUQeAdSpwA3SFZmb6dRgdFME0EuJ96/KhoSzsdV/Rdn
o/iLXrBxdnByenzYu1nuPBusGIQEcFNUEeLRijpgXV36CpVZ0LyJ2DKusH6Y
POy53wrUh+/3fq7w8Og9Os3y3955HEHw4t0axFDyuwWxTs/TXFJbuWuYI9Z2
A096ecWsiL/T+tEOUPVsfYxaxJJVQIvk0gNKPnXmm8MImweA8utQ0DnsaKBA
kGKyGt3Atsh6LmlvL1c/gDLtbCC6rLNoYhFDyeMRopDZIkhmGj2dILmWRt2B
tP1hJ6tR1FdZLjEFaXbQAJJOeoL5vWS3qKgddIq9En8AVqvVcNoo1dE9gG4m
o+9o01zD3AuWDmntKsjfk/0EI9UoGY2pXHfbq+EzuCmyIvGbA69EUip7WYI9
qm7aqBID7Zo4IlnPPL/tCb16wLlZ/klQdv6YdkupV+hn200ivhBrWbPCi9cD
yqrFUStg1eJEiRsgZtfkaZZ8ZzIEa8Azq0iOfYu31IcRMhHW8Sl0mqlAw157
Bwb2QU/4KvV25JaFB9J0KgxSYhKhJUHYMz22LXlXYWx+2cI6V+z0ppIxeeoA
CeUXfCpqW6+4sFI/Ll5BYJdh2AjLtCwEmTn6RBRIcZfGlLIqHjvkbtGiKFls
JWbxnHcRpz1J1lcaNzwQTk+6BRY2geNBdLakRNHZ0EQYyyocvRUJGlaHIAKC
u8UhEDHRP7i8CN3erg7lZPLOx4dQ2Lpp6V/I8Yc4JlqR14Zik3xyN3ELyxUM
wEFplFcsAV5sC8fQwgVwhXpHNNqKx/iCFSZkSzyFM/qVPq1YWJ56+X8dhwlB
sOq10lmRHbNM30VKOodMtsGKDnQCCSZHeEzMU0C2CdKHfvclAbisTFZbr4uB
NH7GJ3xJir4lFd4oQ5AWFy2NnCeUOoWR/piigHc3+uIoExUV61SoeTukiAUd
U9TdOB1neBXK0XkdqB1J0YGFeqhDNLSpIWJmR4eHpc1Vg4b3Dq7MphMsRPLj
5IpISXLUCRWlVuWizjPbRcE+C/SNCf/Bh5FcIzep56RcL7y5APGBeG58TQLZ
dZmT2wqju3NSDpP1kNEMd4QlkpgHpMq+UHpxyqk2rahImMxAlpCjxPs/ETOB
MLOWx0cgOJWXdZqyS+qqUdm/nT96MmOpy+k+LzvzZiZaMd8lYrgZyL4AaVSg
F1otBNSJVfk3I9oYnc++98FSF5HF8CerFOgvk1aNCmkaak4I1QbE56yHHaww
lkHhTHx7Iw6E5aaBHEk9gSAqD13KR/U03CWJXpwhllDFLhqPpOFo7RaVkojY
kc6P2JTPMEs09bcy1DQTiuQEFIslli3wCQpqo3IW/AWnEhBboOyfbig3JfZ8
izHIHQTL8l91EhrOFRlQ/lY0telH8eOTFBXEk0QeQAIFmkJUj9rUJafTUXBQ
7QMhJsGxKBo5wQLL+QYnWj5w19kcEEuzJJki6IZ9tm65qxp9RiEyCs0QWHUg
BL+WoJNKLF5t9DMiUezQjuhdlGydrNmy92Bu4AmUrqcSicbjWqVf1MRmWmaC
VQ0yjKa2holFTr79qFW5JpTjwRJWNKRmo12xBxrl95SbBsPg194yODXZBO5r
CKSyV/WjRB+y4w5e4FJyZO8rVhsSVRKpCXhLmd9UeAF1/3dUqEJp+jfffJP9
SFK5xslPqZIEjXplxIyu5BtGIvF+B7bsCw/+BmrjdAiSaFkJwVldUjIaEhBN
dtGt1WPmSBCe291WTqOtWgwQECygkGKqhqLJa1QhwUiDobB4RmhiwaLo4qRk
vMfi7q12YUBFY3lx/B4+VFQLp9Zz3GqQ95LDkUB4X6Mi3iZvcb+xIzZHi8+B
4rQrCRxzBXN00OFFwIUWcWZeb0qtE4K2jMj8G+wfLN/QwOoPI48g2SuIfqqw
MTyh3ByNGcizT2gMmkoyr0snFfMQVrHBClpi5pQ4bRVVqIKfFX7BeYTixLOR
bcOmrIbLrXChG/EF/lgFw5YVW84Onh4/OxycgfwFMgFjTJRtdtETRFuLBcIg
FTkMFv92WP3ap2FKpTEpjsUuh/um7Irobcm/L8TWNNEqrgVdY06lr4eMZSK2
UdwoTMxGHCm0OCusDiZlc3fNTsIyqc4fGWqQ2Foab1IcjUwXVI8uF7OfPECw
JlbtQzIE6eQhrmDg91iS/4ZEYq6VaFZxrbZkOa8aTLov/zck2ZCGzyWZVIot
diS7CjMmMl8JGac4koGrqLGM/CYqLJgo3AVMwRdXhVZ+ccQIjeZmq3nYqo70
JA2Q3+uaET5OJR/EQIglPZHQFMslPCN23wFUjMlrXBx4+F6rFAGCPrtpt+0W
4zWZ0ZAY6Ir6Mybny0JohRQFCVFbdtwkv9ahYs4DkgEmhdY4/pxM615OAfS+
Jy8M1g1Vr9wXPm3z57mzIk9wx0ZOVkYOyDJJRvtDrqs82/XkowkFlltoBxYk
w0MsgI2vslzjfJFrX+czkpiutut13kgC6gZlET4KjJ68EbGErE4SZIa7Ngus
JRy/Tavt5XZrk0h4AuG2o9gWrPrCAZwY4KZigBo22FDOt+iJyJDij5NxxGUf
+c+9z1/zsKJoAXYk+GBEFIe4rK+JbeThXUSClZaNISnjSMK09sUa0Q+7jeJn
1DlEYUoSIfX3zIKfKHgJHd3iS8Rvf1UoV/j176P3OhcNi4RGfoZ/fYU3eHrl
1vt3F9j1VUNcoMyWDiBhXfsHcHFWuPX4df3q77bCVzbT4Ot0Lj+/5HYP/3X8
UdFKkS4kObmE3fEvfAEYVQDyDZagYf3Sbn5IMZaIE0pd4j1bzlKkzUU5Xv0Y
85umSGKX2zjaPE74QfaFy/rH/FYu+L/vs8JdXLSxkjk86eQBmc6FxUhaCoa6
yOk9CKrZthsElXDoENgQ6857EhpsP1hcYa/lLnYXPyY0R4WY1B6E85tE6Bdg
277qbTsI84WG8lksQA8QkW6QpIH943tPrXKP7F028PDeozXiyCQC/wb97mtg
jAGktN/vh6qgcJ5yjDEiWDHuxYGtEw6vj8NZjsfxjuT96HYMDEOfD4zyq2LE
LPCpd2nMMyPKiXN/xct1sTUiz3oTrdxtFo/xRKIoHqMcce6EVt9IxFsxISfl
TJiuiqWY8xAYKSUcdqgwjJBfkkRIHDLhbU+5slCFurO3ewHLDhVAHtpqjqEH
R0clV6gAbJL03UUyUqtO1LQGe9ymweo+gNT1DqTyYrXKqwIv4Vv0nPVBOBzE
J4EL7NNFvA4p3KGSr0izTicdRo/jMRk9ivltJcIqavy+NCqLzepvxGlB9hKz
p1ItLhmZJoS6him5RrYyviy3K5+PH1ubKJVU0hYlbf0RHOdNuNIzwXquNhWr
ctaPQWQKGzmI9gUhDgSqqqfBGQ99YAaK5n1bmtMHuIob1vQQc5yETUrmz684
R6KrVqppqE56+xsta2zDKs1GgzmHe5KIqeYQLKJkKzwRFJxqVc6afuV49Eze
ULMQPoCKnYYYFa2I1zMK0pNh9bS0XgyuQz620WZw3SrQDmp9LPjx6irOrZWS
dGJ2oCGrEu9YLt7UXKzkEvu7t8JLchjtvi3gttVc2EoHKdj8vbrgQik4do4v
ClbxYfjbfEOByGohAnR5g90d0LxsqW4R6VtyFo806kizD0g7534VHRXvZE1O
8T4PHZeiQTVpIS6ujXfyjkotFwtaGtC9Kykk8MkKCYxGg74nhF/bSR5k3oUj
jrKTixyD6J2dQQOK+wULlFW9tIDugWeI4fOnoLxTNZSff/4XrCRz/O23WOCj
0fS0SIgKBQl7dVPxjbLBznZ3uTIEY00h04oUUkzetqYCsZG+JrNso3WuXN4a
xykt4DSniBtEirsO+Dxo1VoWLAoMidM8okAZ8zMRj7E4VL2dgcRZGGEMLd5e
gQ/Oo3470Sz1EOi9y7ZMXuAyoXbuXD1Thpj4FJTW5aC0ahUmtS0XJI3Kfpi5
gDtUEUsbC2cdiymfwk5aDgIdXVgMrSbD0AbYGhUtOZXr8gVGL+EdtsMnSm9R
KIs6HiB0I4ickx5MiutOFE/SSynlfjDojkMP7+PgO3P1sl8kPgOus2O71RPU
mtQLX//eHZYfBKOEEveXFSMlIc7dxOiQf90sWZbke0uYRRucvR53W6t258UG
Q10fgeV1pEdc0v4xST5AnxLo8w1dKTwEMuO6mMe9vjz1WBKr0QJr7Ol9wFft
y6kyONOi2RJwFd9VX9DIJ8rtubWaikzGM7FjCAIp26DUz4QCpE73GJ2tS5FO
qSn7gXglR34ll94vw3L30xyCKDB1H5mi2mbUfivEBXzjycfHYE231gkYjg80
sn2wapATtaRSFflEQoYduQvMEWddkCgUOy7wH3UiAjD0q8eanIOYUYqiv2cF
ZftQnX4r/3odpTOXUtw1lOOKwDgUx6qJg0OBsSwn9MHMgBWncV8D9TUdXW8A
Ld4r/gWtmmpbCZ3h5J3bvNdQgGRS35xEYyU7tf/JnXedPtTUp21PnjzS9ETC
RfYXBpbAZy0W0C8AzXU1ZTjLHJoVocgrS6+D3UUxOHAO+uxOPHtaoSun0LFq
sXIdUFCaR5RR8WJq4epxLz4gdCD9sucg2h3Lg9QyZ6gAMih/7IqIm84wpvuS
v3RVqBZksPIXHqAd1/GjZHk6f62gTn16zXQfZyeLAXngs9OBz87w9RP46ix7
mp1nz7Jvs+fZi1/z2ei/TP/B/xtxpjP1u1AT+SdpLjM9yZJMaOmG4X/+/rut
Yd8PRwE89PO/fg2P//z9wREMpEN48FUjfN0afhc4uF4+R0dHD4xpbpJvvmcC
KO6S6/jiRUQYnSSIbVrgjzDPehtRrg428xFVOrRmooiS3caJVeZe/06GSlJ4
45ET3vRI9ePRKFyCUGHVrkV/vS4Rl79EtcDJm9wqk7cxDrSeSpENJ1FrnfR7
7e+kr/uoGGkxRQYP4oryDPqvgVYJ/CwMJsQtBv3M2lyxYqZPalnXIgR5WHni
bggaSRwNxtBo38N9j0oDKdUPMIKNFQQLnGCCoyfgm/GQ6fG+Zui3e5EgfeXX
ogEB24pROsjjQdfbRuYXQRy7zpZVMG75fmIwhhj6JxzkImdnInZ32+/3FXWO
9DX70AyIjW6yxZalscKiTjTWmQMCYVoTSXj9rkwAwE8Lt9ZJx5nUO4LthLRq
RNqOIsHKgZTyJIGSH+aWp9IkY7aqZ4wIFPZKJkq3XjnhN1IcPW5Y0MR1geAE
/u//fvCNoO1UdngoDVwSXBYjO75gGBi/EhAztKsK9LxHHU49fhYrEPkOTk4P
BU9wqhWhpGFsW+h3AzeIIRKSQIzkZftefvRO9V/lWqjSUA53LP4Uk9JDQ3sW
sMNdeINb3auv4FUIdRis3lFyjcQH9A1Z+HijHwUpf04PUTzsfgRWpjnFDBeP
ZkPOYdxWJWKWhmpFGpLU5KJr4fXvN72ar5MBY3JTqHjo7p+hVNmr0OEvnhev
lRaJOSMdC6c9aIpDqo+ThUoS3mSYu8WgrKpBeAEgHAaJVTeyA9JJ6Tsy7s7n
3fSyAIl8ei3ZbFGKihXFDsbVc2oUOBneVdgRlpmpgzeN+4cT8KxL2yRuJ1pI
icCwlTRmMxzs4IneElGVM3dLSzsjlNUjVH8ySIklrDHueRZIaVDrHEEdxLC4
abn1w2PafUBCy8khGwbmMCflwiXfPz20WSTYElk/2iHeXmZnooZprziiuix8
9BZpnQ4BtKt84zrsIqSS8ivePArHhB1DBuA0IVOLlGXcUwGU/WZktrJnaGP0
ba+ADLXx5iy9L2LxTFxBA5asiHkYenIBcNPp8uzsdDorKWYV85kCSgkeYeBn
7CbQaPjc3gl5s1RjBpN6tFkSIPMCppFCYtzZUyaWryQeTtbFsXeFtrWKjawk
b4LGHqIQZAHMXKnbOq5hznxRaDnfGtnO3ssTV71EfaVzdewtVo4by/EAFnJg
XwTZyl+/TGOBPLlA6wo73K1wnxBr62I4iQhi8jLZ+ajrQy7JavmAdBRej3Zz
ZJW2GH4S4h/Vb7IFi8OfVidSHmboIO6WFVtQCs6RQTpLWCyr9F1I4saTiuGh
v5UBY1ZwMHioRCIPwQSCJNS1hKHFtZUrvGBL2GmXCk1sxSIfEN2eicWYOG+c
9u2LvEvkwSxva56ZkIq6bM62N63ITAA6MimJH0LSOXySvcudcGuPFsiOSo1I
aLczNLPhJcImMJwl14KYPZeWT0R26m1HxrjeYMIvysaXQSm+bEq4AZjyaclS
t9g4UNkB3Vkdgunppkb+yqsI54FQ5h6taIMsWMCfsmY3b+q21cqFlhgvGiKg
wun/c3Y6yQbKjiahwxxCKmREzbW8SU9RFHVLy2TGb8teLiZVLYUzI3YvrrwQ
pB0Dj7MbaTvBiIl8p5prwp95lsW9y54BQIKW0x0ZQsUAN3TtR4fUEVjTH3ZW
BJK6pls5mB4ZJWOl00XWIh1wKnorxotwKLeFpg9YrUiprajXOQgZNJa47z1h
0iD+4CEhoQEQRxXOSBGKnSn6iIh5enhj7MTbjmEF8IFxJCyuIiRE23I5XVqc
G104T1+1z9dRMEbQI77WCTn/rME3uplcOI20tLTQglAT3DrGiUWasVLEE9f6
WksPqwjncyDtJpMjXD0hO7Hx9oVLCYppCou7IqcMxbth4nrVJq2fYggLgMdS
kwKvouFlqNLAagFyELyyiU8uEGvAIiDW+U2IIuSp4qh95SU591RcoIydHZRH
gOh+eoxLBCURZreyqL5j+sAtkST1JJZed9NjYQQW01yixDJFew2oUx6CB6WI
6sMEgcyvVBYwyR2VPgyplasWQy70sfqKoRQpg8oq1hKu5xrF+rBnLYS94BW+
y7E8GbyH2Xu5lQ6mBthtvdpqRjZTDx8zo6Ey8CUl/3M8hcAWVuTZjQn3fTzh
myDvrXGFSGsk4Uh3jILqMtwigQpeG0MAL1UgP4ziL8gbbL12Qj/OCYup9jwF
y6Kw2JciB0RcAaq8m3TU6/VWxQggXcJNHUAxbDxyMQcLoBll7DQ1Adxp9BNv
O547DzGrNKGGMayctmigY0lBOh/vU2bPf/nFtNnTo3Mr0mGjeAZONLnXfpol
QGIlkywp6WKoKqkqNO3Z+dkLH6B0BmtQqRVRNqlqgwoqtqbhPQ4tTLDboNgf
Zc5VIxqKfuWK3JutpG/BSqv5TjOiuAfXcmcUTUCuHeijoENNwAfFa6u5u5/s
yqrdJvu5b0z7hbxzvnus5Sz3nHSisGlBA2ERi0IFegvywHqAA+Fv4rMvpUSM
89gWoWyuywtg6TMe/4Aq5EWmoMMoisPlTC7q+GUfQxhbk3BpP15+5J71qYWD
EdzC9OMhxXvNTnwfWDJY3zZdkWnkiQEu9Gehom0quUvOrbmYNWw51mLsPPeZ
d1lIDkZecY2IDlJihkzVlvPIFR7OzrWu5GgmQpfGFauNFbDu1loQ46mHgtyv
grRsBgCrosGLjYFlWcga1YSlScjXs8+kIUK1M6iHWk0mDFEsikrGnsz4Wu0p
07fU9NryQ4M9IzLuYMYo8G8WM2yiQ2fs0TpLrq5qvHHK3iAs7AloqNpOxJ8y
iQNXWqfYJPUn80R+ebvkxr69+iPE2viMSKnqKXdsZZM9DvBkrUmiGa6hDM2q
BoLs2tSm8XUzzgtRu4pxPnGihWgfyvKddx4BJZbTYmheh2pxxA8LyRrl4AtN
M15xu0MuO79ebyuyUpC8pLn+67Ll8MPWOsOGR5VNiGAXpHPOvjAxXHp4qKaw
qPsnrpnsID4Ucs04G2WQf54fPz+eOPZ5iuZgiop9TWYyGgUz33bOLAa67Y1V
hKPrU7IgjTq55VfC7zBMeAtjPgpS3wBK5yJoBmCsJY0f2OmxfonGB5wExuEi
HOGrCbzQDpo0EdjARxsJYCaFgLxJMMp2oyQz6UwuCk+cYGx6zgrkE63gD6Og
izcXLwxJ7o2CG/YMyzR7lNjsUeaQhboSVING6TJpCR4nR7gUnp4P9mCPczpM
cbjfIUXJ8FJGb4B7D9eUds9F/D8mapLB3pknnSLnQowcRRTB1KPROzzQUJ8g
xALxGToV3ZY7ltO8xyBdqUu762nyqpMNtcaTGLmkklfpcuEGm4GLEdEKbQ52
ahzgfqU24MtTWhtKT3T5zb5Ors81ZeiDNBIuPNXGiNpK4jclTpDj+aShieRO
R5npUdwX2gBvKNaLev1Ye4pqyYEHOfduHdL/b8uFBb8GX5brbsys9rbeTGe7
KfzH2GyURIHAdqBREJjoUYd9Yy0s4jO3eUOxo/Om6NztCbn52nSZyhIXGw54
VC/dQP5alHxf+2IcgVFz+YiFi8E0pFTD0Rb534rEcC5zsdtoNQ/EUngeQ+Rw
VU/6a6xZJ0rdSzgutr+dfgTGjF2hHYAj2hEAZUksZo2jS9CGRWVjTKcbs+VS
ylU1Zfs5KcSwkSnb0H+2gptVN58lXlfNNRwqiEyUq2GA7MYhMB9Q4UBNGkfP
JPHaavxqozK0Wc1JDyJNiZBFrVRAXVmuRKyh4uESnBiIRdkOo9pEXCewri+7
VGPJE7s+2eAKuEYIO4obxcZaMKGIpT7/IZKlqaoT3Wq2XoQm4Tgv8mHhiGRW
3VX5GqMji4L7w9e0Qs6BOX9OjYyle5ZkDymj0zb2XuhclCjMiOkYbnbdUOHD
u8K8fGzexTp16+iwuRlyRvZiHLnsyhvRfltBBY1kJ+Wk7aQ6Eie/i5jhC665
yHEvXmAYeYmSy8HZYdwgNzx1coyP6cbFkdJGHkyrkZKqSq53WMFQlTxhn5go
g4BAvARSTWVwWEkS+XBo+xweJOWcWPgSXSiQ0NCbIE9Jq2usJmk3Wgu0ddeK
NdTXFx+nm/uF5hq9ODshB33dZD4BMrwV3bPcFaNy413jpzLg6XMcUMsFcXUd
9sbMb2uidkrzb7j44gO7YSsOVi+hRMuumJoCR2VelhLeo71mrdpHW2jDWcI/
kP5doSm4B5tQdMU6rvOKb2rg7MqABkoQNyF0u6iob5m/q3pv0JhScSQ0MJl5
KTk9UWCBCFAaUxCxmVRO2yMCWBtNe9Zst5Rzo330NKwjEHNpaxjY3SBNc+zH
YiBUY+632bXSbI5/sLdqH0s5MCNbGjHSY4Sm6uatszs49r90DOefOFnwn2SC
58dPn3pz2jkiKK8szqZLVxqHH8KZrYq87UIUZwjPYi7oY3WCwnFy+rwfztUv
Hyu+uY6LnhLf2gceq0Oca8f7pL1OCJuBfb53afGPsPcugSMy7n+KXUkrDQ5K
bKT3JESx95M0oFDTjO4KH2MUw0ce5ICCMxgdkBUj+6wBjFzOYHzT4uAwQ1gn
LDralggM6CHQxoKPiTGhRsID+BBGkYrXLATSXdo0eHYUswRAI4L64/Wb6XNe
ppQ+pWX3mgsxmN1+FLQp4j4l+dxMhb0E56FKuoGSEykEfbfqrZV6nViN2PiN
9FlOzQ5Vn8nO3VFDXKyPULabFcVYAAujkGb/tplU05XjiFqJDQMUwmtSD3EQ
ThOWBtEIpViX4i7dlOgQhUq9+h741qtb7CIJmCCJwelVQ7u7JDYqd8b3EAn5
PTl7F6njyv/HUzxK9p4eKyMmtiAu0oEMHpIBUREb7lsQcw6qNbh3qAcYiMga
j6xFuViyVxHVy3aoYb2FcGo6n/NV0ThfzSnOkFNwccMkME7k7JoDowYBJcmy
HJnDZVnz33RmsJOPInxT6edCWyGwuWJwZa0uDbHdLS+AyyqgAObdc1E9b9F9
aGdH0jES6+rn2FVZMh3NsDwMLDERtAqGgWPgQuB7oaSp6qgBcZwt2Zsfgmsw
iX4pQzjq1lfdYYJsihx1lSOnxiBa1sleLTeACtCR5JpIJ8mHQ4f+PBUffif5
JLLNtGqc0VK/sjC+JtPX1YLrKw+v6oyl7mCieZTlxdlwe2pP59lVvuqCg+cS
NjH1WRJtnCnsrUkJ0IJFXcubcriGnJiynaStZJAcpmVfmtl/dv+IPPP8f4E8
81Nh4h0vPywL4f77iSz7QfK/hZb/REJLcoxCwP4MTLJupleaBuutsxhImX7v
sJZIDYULaWdqbxVM6Vk4+7JBZdCtEqmMaqHWHOjd1fTdx4+vp5iSMf1TwQ4r
/fBTMb/jD4OlU6jY+dPniQWnT1t/B5XvKfNprIbF9Q2mEddgRjD4VY8dnJ1/
+yLpXHAYaX4hMmw/f6Yglx6xIk2/tqzlNFtZwjAfWyb5BNSF/MAyJgmZMfdN
ueKCVFLOF228KJUG3zEg/risyBoW3h8PehWevTh94Q8YXQxxx4yv2U9iDBEL
pBrGTChSIX1IoKIUyZYrJVProQPuE3FoppUo6EKcOytuNJAUCXN23UcXX1ku
lQ97KLv9cPyNYPSmZU3mUPvbIi558RUQl7wwLPJELcpIvv2686LMGu19QrES
iZdlrpjElkAuzkEGqDGZnnZoiBq77A7ZZT5kXF98xSFIqKwW1OFigWQjDcJ1
dB9J2CA0E9utOfTiusm8HA5xluKO282GmzNQKuCU9/qViC4dBbbdTe3SQdUY
YkW+ffflFW4jv0mphVbSagqJaJbQr+ElPEisEPt5o6jdqFbzm1SuyZBWk+95
9cfLj9z6Q9OcX30c1nFcC49wKFoDf/E1+IF2XnKNDG8pSQWkVaK8SN6hIlZx
ObCD+YlJmFxOssoG+ccZSsZjEmuxLFYOp4lVLZLkqq/BH7rwRasJwtgdBKXN
YQWUU8ZJ/XUzPYIoFjH9oAZJV5scA70GB1azj0gwUgquqsEHicVPkpALvqYq
KQ2uSmhbrx1GCPAjiwP3k6dYSw3nqr6WGlIqEPpekZAMw1NNKSKsOjMKjHPH
uSGwxJuCCYMInE6l9+3TIs9EaHBzFbmpLCqFaa0aMYa3sxcPfK0fuXJ40zzf
1OLMg36TTK3YzJetEmDUTbDQco5R2VSjY1Sv2dFWfj6q5+r6HHE5waq4ybni
C0UkuwRAFyZJr4juQknoXCQmqNghU0ldvXulRKxfxJUoXGGxPfijz3rlK+Xo
pyep/v6rpci3S4teFV7oxI0oGtEJb/+AxKFJLV+55UEvVlrjrClWtLJ3F6+m
nyhxp/xbJOYPQuv0PwW0xM48QUWIf8HGTBpBTuTOaUSKk5HxTXo5hdpLxnb2
VkDScd5dnk/EGZpEFrn9uXIKrVUP6CymKU09iIKbhqwPyUxkgkliRUj/FVuE
ryk17AtNQ3gGNxSFSkU6k7urcggyJ4VxvLt8ymtyODPoaorMH6iM6mCu4Y0L
4tZvLbJy1nAMNQalFvN8IVU9rE76zz9fXP0AHFPEesnE8UX84P5MqUAAjqHj
a+6NlByIXfU98UQRw/cflt8vtRmxG45uLNXTK+EWNeL2H6feenUI51IR5iNs
g7gId7W3oO9HOtaqOQVkt4E7Y/k+CHty7VPp5l8zdqQxfu0U17E2GbosEm60
VKMiCu1hfIzCNhjD8Mkxo/TYKuBFxliNUUiChVhQS7GS3PlDBxGkVTv4aHTn
q88+iIA65UQMYW/WoisQNAysYZJHSuvQe5GMR/pKzAjYpKEW1VA0kHENDtBJ
TBQ4vdJAm6QvQNL8SOPGXTpR0k+JT9FdYSudPLBHXzuRDcOicZXaORR38lLL
uAxCwuz57MBYYFCvuS90cSTXhPoCnYsL14h0ybQSOQ8GoVz1ss3Xs/Jm62r4
yM3zyQKLkN/Mfom3lxo3vIdBDxqdesUGXWUkrjKF7rPOn59WCrK1+UZGY1zL
GBeTqNK+REsajRZVkvDY4eslhcJUk6FED5dpz0YI8UFeR/HYj2C2WAB7ePPr
7X//P8gi2QcyULyS8s5BRVLpH8teS5i0AC006m5NItBY5ZhpUunpgaQfTpnu
RWNP4nQBbSR6TfdDWym6CC5gZmuOx6S1bSuVGrt6U85dZnZcgpSpXEw/fGBi
7nJie2qjkWHlMYjzuVX04d4wPp1ZI1Ata7ZsnYPCWuma8JETG5iRh1avqn7C
KUX3lZUNzRu48TPtwi5Zdew64crACB5zjfpwAM/Rbf0LNG3tuls6C26IbNmE
rncxd0wr75jbigxI3aRvbtC0BN/gkpqdJVf2Cj1LEa0oCxWb2clDcFKodS4w
A7JKko0d5HFNK7LcSnyu2uX6KcoPnpcKTPFzJHb0ynyJLW5G2fYeoog6Yu7D
bs2U98aNX6mujIvoBymkcaWCUEqvG1NYtXFllEFkZgyrmixdFDSt9DYoslEv
4FDEbRFwkkvnRKCQ4ZRcpoRY5qVGdnC2f922nToCWs/ANII27s9DceCcdnWz
LUGQJ46gvO/h0xJ856KI0kt8LndhDcQkA30I/pLaM0tsec7WQ+lNQPpUHEjQ
crNgCsbHWySRyDh60swpl5RHOGc2o3SMJnE7YSTYpKOidwRE802/NlzL1KmU
Yh1vXXMFLq0Tsm58rwY5yDqEYMvUO2ae+46WtR89W3VHlmY0juXgrXZteqQ5
aywV5a0aWnGRcS5xMpCLlqI8NhdRGiqeC6Ogs8WUfhL6xSCM35P4o0QdDZRU
mKhaTLt6Sr0gbSSk23ZPrBrRFef760NCJm+Qka52LssZoFrPAL8rKmPtCwB7
S+5Pt04PJma3pyt6SmP1MPqmcmwG1y/WlTL/qP/YvvZYImtKIPVgi1ei3d5z
oq1VzAQfF2mK5hU6d358mh3oQt/Dy5+AMtJGDzD2aXfIkWvnx+fZAcsZ9DH+
izvH5dHaDgezllhGLFabzJEOpQEhm5hGBP2nlFg7e0Au6ZKM7ZzPegvE4FCr
HbATK6cPrQJCuUSvvYWfeNBJCinV5XSagNFma03eKS9hyfL8+BlCSSsQ/Vjl
d/Akgik4tUXujLBKtubcij2dZ4MWDMUMzNfB7Pow88Am/Pmz59j4zJ5OwGgm
7tpQNQsJKokI4nrn1MqvwITH0UCwZS+4epFkoDZvm+pr9MGIIWnBTqPpw3v3
6pmM5tipK0PPFzoQOeL/44IlwQKLxgwQp9bR9SAiOIFTwQsoAcBcDXf+Ms/Q
xLkyU3f0EN4oAKe6/s77pszbqODj4g+eqTvSnK9uMO/ndv1g9mHUJoXXqIWI
jMJKfgwfkCYvaSRosZeYIVR/P2LEfjrfV3m76kI/3vB86bJqY6i0nn6SOhDU
cLOUaqSrqYkDtNey3pISkAwhVz1C3y1pPlE0hwoFWN/I3Mie2gAUFVCWtypQ
NNRgXRNKU7OyKYzUkwz518qDRIOfsXYa1cKJ5EURkzmzi9t6OczyGoDSWTPg
xPwr4rIKjTzhYdQu/Cs5p8O0KIhF9dKkF4/hcmtipgvtkCZgaufhbkBlRx1l
TIqr6iCAy5F4r75vw+zllbbT8nnD4gr3gFs0hrWkQS/LBhbS5KVPzY9rzDiP
xRXVaplKI+GRJtqd+YefhXhOmDF0oLJ8O/w2qsHUxWYk5jGUIX5A7TbjisJ4
5enwosVIyEy/ocg9MupFfRMItSR5erOMmbO9B6qXxe4T5bs49aoXyi7ko5Hu
zYWUf8Z9EP2vEu7cm+Veplf/abBGhEdhy8oVs4PT82eHTjmVMqywQP+8Wmr2
+HuJmkRgdREBVPMug2l6h9USApMzQ2OwuInsHm+4ikbYh10VIMD6Hg6E3fl6
2/ngEvfXbZVkhMCYqWzaYCmuig7mAcOcSUq5xfKLzjy0JkuhKNDLpIYTb83G
Vc05DB6tI66e+m2vDvrS0qiD/3rvVpZ1WlQs1F0sraughVawKIcuqRt6K+9y
TK5E9yGp+tQmvpc7wAxkiWcr5glmPq0re0hGgsEGVWqAQ+6OvqBI3rXiJosi
MlhjvYwpB3+2Scr+RIWMRZy8yJVE4+GpPgfeYray40RNcd9oSTHxXA44LsvO
BJKDLRdwoORTPMYVHC1Qn10ou2T0noY+NItd6t6VunnWJWjBxdRcBU606CB/
kgm2q8LKQtOOoqAz3FzYGNel6m2OyyT0XcxJtlwSazxJXdDiJ4s/wcje7HOx
a8V9RiX/U0ez1aryzigVMfcl5qgjzgqPdxSFLGSIa0x0Ikz72LRQeceNa2Ge
fT9RaFEmsqpoC93XjyamAGfMKU0Cg9OdcHYSyljrmUg3fYd2z0yDBrAtFZOV
HM+VsEOupYekTwK9eMVSgL9XRsSZ/eW72PqfVuIX43mrgkOoeqB55VZ/WaQM
Zo/WIlK7sIXG6lbWqvqnjksIYIXJvOliCSbuLcaRExTfML24IYFH0nX5s5w/
21MU4OnpibTPjBbpKgZcYBHQRfkle2VNWKs9tQJOxCPfOyMuNIZllsQVjCok
14iRWsktIYAUkBzqNS0mNAaWMnXYTn2XUyWId5fnRK4rEgLR3kmN8aQkBYXl
lnf53IRBBz/XTM9iEO7h4InYblb1TjxOmtJcLLZNna+1NsQLynykAgqvL3/8
9OHinfwN73wA2H2qc/Iz/Pzzh4+v3+P3b9//kSDl4gk4vA9nJhKaL+oN8ygy
SROL4lAuxihrLMstUUIlhQE3IBtWYQALjXt9mVm1yTRRA8Az1JcSZcKN1RRX
1B0stPOTeIQkCjxfYRkA12HYWgNo6QiJrQ9Vs7k6YlSLfs/NR3awJjMrFenq
dzHmdZZ49+PqzWjEvtG6cFqmuyblg6iH1JkiEpa07xQkHkZ1VE5A5GBtNyVJ
voVjVHKD0IFPScrKhiLZ7Xb2V6aQg91kSWNK9i0BQ9rwtddAXYqtcdXCge6R
wCoANRICkrSHI9fC0PZtMYydXG5mAFISTgs3WCSXvUFaZnDqazOmzB0wUh2K
x9qzUKt5c9ErLlVI2ZQydIsfZDK01lkuYQqL4q5Y1Zu1SES4dnLlRetHThkD
UIN/kur1ESH3dhzLV2J6PmziKfs+7fOTb58hQuFL42vrWm6cbmxMjDv7+Pd8
3OAz1yo7iflHWQz4Qk6xsq/qi+n7iz8RRl9i5Rzi6PRRFK4LF4mNd2oAoky4
ln2V4lGjeqkBl0wdHt68GOfDUkLqk5lDzE9D+emuFbsfMtrPoAmk9Xl52ns6
Ltj3jJtjsyYva/eTkC/YZjFdkC53ANT7Gm1sq7wyIPApsRKUlLKLztsXWOw4
zhstAHNkHKticRPKDDOGh1q6pL/5cRGOVsWkR+BDtUb25aAApDEEQ460DZcN
cotVVe/+gcONzmQftPZwtpQgPm7U3jeHBjiE6ELapMslcv4O1cg7H/XvRiOR
eBC9Dgk72ImS243u+Vn62eoafah+0nTnppDvsxFLy3AYUWeILWzIKMndFDUt
T9kpdUJworA0xfB+qFbyo6yAWu7VEVVvVWfeG4DvC/QNpk2oxChTS8sSLrGs
XbmTQNxoHIrOodghEit0vVJET8OK/CtR7AobELnkDQp1bMKQ2pTkFXo6ZDcI
xeKr2uSRYLK10kLav4U5kXPSsZbbMLqVEgm55kzdiv/pNZZjEB1Y13ilFFZ4
qhUWB7uuV1whgAqvHrJwti4WeCPIWBBsyOlN+gq3K7/JoDo9PuVI2rcB1Nrn
8uAtp9odjl2tMN6WdkoRArA09Cpbk99YelUU86ahJCYyX61N9L4lI7dgUMgw
CjkWwSrn3QDiT6gwnQld+ta2nmu+DVxkOf99p5STuPobz+p3PJ9zPZ+HvEpj
klnaQm+P7yRIEi7RqtVqa8Yc1pisPBgaj7hvS2tWoojYcas49HNaATEeKLYZ
7nHfqs3KYlm4sCC9It42DihRZDG4I3Mu57CUvQfA0WXxIbB094ZtD1fS7roF
gsifYOVGOn+m/CROekOek5jMhPTWgoEb7OujtoYQtEYGLBo5NIBAGwDTkrxz
Xd+sATfFhddRdqRueLXrV5qSMGcf3NhqQd7ltprLSarxnTWr4gb1cH7nZaSM
U+17JITY4pOr32iyQpS3K/GSe7rQBvuA81lbZ2qixFiYtwr99OK6p1XUCY8m
iXLc+tXcMso4VTD11L4AnpfCIrjpnTAhchhyCjVfE67wOrfwoZq772h8qTkt
CFnvawNfa+TP2XsHq/j2003SdKNcQ7h7h82tJnOkVxzTVXJF9yOuqiD2tVgE
RN2R61n28Yt2x24/6kYnlVKEfvabjFufLzLWYVz8xLmb5nHIbuzDiqGLU3hT
BNfp5dKDvu1EPmh9sBB/QpZ+6SZX6y9OSpArnouMROyT8C1UOt8LR20u76dO
ihLI8GXn945hoySYTKRUuBbwR3tbiPZvtfKHluXV6Mshd957pBuRqY4KdQxS
sFBRg51xrpiGasW94mN76i6n9f3YV94vArKvbHNSaCepS2+1fIZMkZyzyVkP
cg3woWSreWLBT5MEevXIDDMQPJSIRmrs4BUmIW+28xkas3g6lgzLZk/NY64v
/EDlDwTnmAuE7HtMakIiAgx2+QyuZMX1XoVtZbvJ4rGQdGIdjBKLAqcQW6/U
ibXY3iLYfFODN8ba3pULrKUU6Qp42axcQKw+adn6arHSErTpYQ9lGrQKuIHs
gkMt5I1uXhfZsu7nyq/K6jMzJwuul63lUWBn2brQ0eEg6TQ10Xwwks5fkTSD
VJiEBqd04OXnXmbUUVuKYDMsWPMVBkZpISyhBU9WWfm0PE153kMdqHwRIoXs
n5W1nVTm62XokQFQwwo4GEnZX4KOYg5Vj4zyoGHKRvRECtOG+vVUtr01lrIo
GPTE3vcFEHuGGZe01vrkE/bmcpJHUgAegQoH5GyQTaHNRbRgetqwBqkL5yhp
HaBBLmKRzYb2YUEkW7ZzQMhiqG7tJGlwqdUaZB4VFlr28mtNXe/2mhUPyEe9
hsKKT4BM2v8t0o90fypRJzi236TsA2cCkxzQzIlD2rY4PEO8+VocLOYJtcOp
ULws5QI/oRgHl/FOdsp912wbHKoeNUvcbGersr0l+VbDILWPVDApv/73a5L5
8VRvmnq7oaHgKXUb0ERqkjMJiLyfcWMJieAYjQ4ixycvhu32C00wAFqXFYAU
dXN0OGgDLLWejfcOHPQSpQ91J2+aoggkn9RUi2eDI5EqzH8su++3M/TM3Xbd
pn355MkNnOd2dgQY9iQM8WQJvzb5oty2U57nSQefPLk7Ozo9+qK52YvUf5SN
UeYek3V0Qwrjmo0dJ5Pj42MkzyHGghIftyXghnaOFE8nEXv5vUs9SaActuyh
w8AP9k8Oe50jYIZwipQmRkKnxzeuM7QK3k+eTAxNvocIlyeP/VTeURmFrUmT
3CIdl/iLtgNgo2CYAYVRXw05iKlYTMNi6CQT70rH6QOG5ltz0e75th0st+Ei
/GxFe3WEYTqOGSocXYL7p0SL0Imp51vD0ahFITkT21ArI+N2dkuJXJXi6IAT
7E14/vTps75bUFszScn20L7SPNtLoVGmBGoOb6jznvRRSaqQyPn4loU9r+5o
lDadkUSRpgitz5zASf1OylmTc7abNpsjYKFPmnVCA5ovXLWn5iG6cjFkjLxF
lAljvQppVJZYTW10C2AsXRWS9WWh8RazsrBm9tdm1lsC82ASW5MLeYvCtvCN
BLMlFLBKqccN2hZ76EGBYy4Zgv72jk1mF/fWYX4oL53FYjaK2S0/TvNMqTSE
FTAU0YMNIa2FR4nhQA0C623HuWyBRx9lmoHR26IF0wfbTBvLm3rYRrxxkhC9
oE5kH5VHHniJRnMGLR+Qv78XkhRGWGzn1JsMZD0y0XOm3TzvzPY17E7WWgPb
SuPcRVwfitdDUUFFoeC99KsJIfr0baVus95xa5AESRSUJ5HPebe19lZpKFLU
SneKpNbzdlOSObvvRFPyickiCYu4TAJuhMymnjpe0VtsWj1DQzhM6/AGeW6n
IMEKTO/qGXdXIr0Llm4FVNUGZ4R8Td7kwDARFR2+W0r7o1nkalvn3uBObkkT
1cyz4p0q1jcLKwP43o6SzIuCJELfE+jhgsu0SQpj9RVQmB0gebNIh34GHa0E
cwJkeEm9iceXpitkFkh2eBxy/q5d7o6YFILKhu0YMVsz1MyVcP44iBIvF2uB
mlkmOYhV7Brk94QL8zUgRHMHefLIQR7H8Y7RMmZFqLzJ9tB4z8mpho7IMTCH
zor7bkU1FaWDqHdIapRoP0dxQoER9kcSHaFzKqEPu5j5vHXRt/d4Q31aRvBH
TvpbxVhaKcu2pywcVQjuY8LeVXGk5MPr2mPDGgysdR0Ce42+OOSZhJWK3Cxa
BUAWvG3NAJD6tgzNY4R7HJ5YpPjh5cd13wcITN5HRPIpdj51jrYQGs7tudec
pykxjreHobOs9gDVDk0dYC2jOn8u6lSounBhAkEO+vuuZeVmpbLN44DBgP5y
XkyvMXrnv9I666b8WzH9UK12lnQAOlErZowdoh5HNgBtFIEgZF70dEB1ZOuB
UnPJ9Nox39uDnpoNvUrzHfe+F5HG2KUSh2ZT1QgRjHgajPdnup1yKwq/xvzs
qsAwmkQ4YI374v1FT7GhDyVdkAowEo/ZWDOtMQq3F052+YFkF40ryd47cfMA
BdDD8N3by3YMA98geRZ/MG4XbSUFtgwu2pej0f+An5G+8tJh8egtMIUrXBbI
CC+z4y/fnsI/z07wn6f4zwv87Bz/OYN/Tpfwzxl+e1rgb8ejDH4OxqyK44Dj
w9GnQqSTl4l3cTS0hJN/cAkn6RJOHlwCQQJ7ZEZBVKR85tVnEs/+UDQVBazM
6lk+yf6UN02Zfb+97fKqAPz/vig/fy6zP8NxYLVP+ORiVXzJqR/vq1UNFAVL
oMHlzYtV9gn/C8IdXpzv8wqNh9ft/LZeFlUJSsM7oEK3cFLvi/tOTYT/Vre3
KEmAftNJTtVdWdyz4WFZFAuMRiVce0VWCODbv8Gis2jyZTddFJ/rz1MAHYht
01YMKsfHWN/pLepHOeygYDPp4Cv8xt3Jibz0YyuxqdyWFWb89uwYu25LWg8W
LdcSmezrkiKblyCgsA6H2ZrjK0aP8dHoOxj1YrFImpwNl+56eIEntEC+dKwz
UbfDx147HckK3qzyG820wrL5ZCKU6Fpc5buyosMCdMFjWZsn2JnmqKL+YzOe
4Yyf6PAemJTK0pPNTHGCnrBsXq2Y1/Lq8GT8NfVHYp+P6VGiXlhspqMwoGXR
WCptHELbZmM+J1j22NqZhnf/Y1sLgWOlWRqE+Ku653zFCOzdMiHRIwnCRdvo
ozB9ijBVoEZwyFsrXWHmbQaZIstbIKOof1p2Dnc306B6uCMIfTTNVgvrrAj0
+k5aK5Js0Dk7T8AZucL93Ei9wZwVOgmrxOcajnbgWgp+pR6IyIcx1JLs+aZk
8vOvQFrA2JgY6FF+3yTNksID6HVlwMH+iCE6t+XNLVXjBs12uyYLnuV28Dq2
GxUMnqhY0NQrVTKaX3UyiDC0L4w74JyXRzHgfOQ2XlECB9Adj4vimAjIit8H
PmXfD7jOPVDJGDHkpem7rdAn9ZAfaq+n/rsMhLWabwUJq+26pARHXsqlOGm5
Wbduwhyw0eWXDWqoBFEyytmCU6u2G60uR1FHfZJDdD7mYnYSZdEt9zGK93Hm
UAhNplcfG4JI+buafTXjgkpqkxy2Goc1/vRHxy3727LnmL0O7YTe+iRc1Jd6
IJshm7zENjr9ePUnnmVP575FgbUsqKl9z4tFsDV3ksisY32DawaljgEQ+uJJ
EO0eg9spg159cfcFx8+LJErs+gXIdIGb9VhXdPsoqp2Z+f3tLhtT/LddE2D0
uYRfLdSPtt3c4Kro2ASgzAIumRKx1bk17wOZ51cF4P64qv/i7FZ/UXF+nB2c
nB4fau6i7ykpxO7KEvH3lm1KE+s1+sAVj8Mz9GnNkhO9f1m2dOG/fQq9p8y8
KCG+fECcJUhhjpJpjRX+h0uewxr3qH6sMQXDTKh77s+3WWfjgbwxR5a5XbGE
QBNLzO8pTSobo6cJx0SXhwhxn4opLpaIa0Tm7SJij+rCmp2xmM2RVnwcLnlE
XHIlm+NBztnkrL6ta63X89hdOBOJgKQSxEchkrRAY0lkX7k8D3JKTo4EorVc
GF899w3tD5/3u4s4A1JqqQDmay9SGEb72HqfihxKVjd2iqqj5+zo6MUjb5+P
BuWs/kUAUjrFMBWB+cqLyHvGfsbyaqCiH+HeZz+RJtRGABABQOtg9lfwyEzf
Bh5uPDX3ajWoOv+WV9M3TQHaWPn5keGepwuHobeLssZc7no+vy3rRwZ4kQ7w
BxD+d9kPZTHLH371hLjgxaVwn0dAfHKSTvQab+WfdxXc6NFoOp2SCDr6/wBL
SMHqXCEBAA==

-->
</rfc>