rfc9765.original.xml   rfc9765.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.4 (Ruby 2.6.8 -ietf-radext-radiusv11-11" number="9765" category="exp" submissionType="IETF" up
) --> dates="2865, 2866, 5176, 6613, 6614, 7360" obsoletes="" consensus="true" tocIncl
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ude="true" sortRefs="true" symRefs="true" version="3" xml:lang="en">
-ietf-radext-radiusv11-11" category="exp" submissionType="IETF" updates="2865, 2
866, 5176, 6613, 6614, 7360" tocInclude="true" sortRefs="true" symRefs="true" ve
rsion="3">
<!-- xml2rfc v2v3 conversion 3.13.0 -->
<front> <front>
<title abbrev="RADIUSv11">RADIUS/1.1, Leveraging ALPN to remove MD5</title> <title abbrev="RADIUS/1.1">RADIUS/1.1: Leveraging Application-Layer Protocol
<seriesInfo name="Internet-Draft" value="draft-ietf-radext-radiusv11-11"/> Negotiation (ALPN) to Remove MD5</title>
<seriesInfo name="RFC" value="9765"/>
<author initials="A." surname="DeKok" fullname="Alan DeKok"> <author initials="A." surname="DeKok" fullname="Alan DeKok">
<organization>FreeRADIUS</organization> <organization>FreeRADIUS</organization>
<address> <address>
<email>aland@freeradius.org</email> <email>aland@freeradius.org</email>
</address> </address>
</author> </author>
<date year="2024" month="October" day="18"/> <date year="2025" month="April"/>
<area>Internet</area> <area>SEC</area>
<workgroup>RADEXT Working Group</workgroup> <workgroup>radext</workgroup>
<keyword>Internet-Draft</keyword>
<!-- [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> <abstract>
<?line 75?> <t>This document defines Application-Layer Protocol Negotiation (ALPN)
extensions for use with RADIUS/TLS and RADIUS/DTLS. These extensions
permit the negotiation of an application protocol variant of 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 RFCs 2865, 2866, 5176, 6613, 6614, and 7360.</t>
<t>This document defines Application-Layer Protocol Negotiation Extensions for u
se with RADIUS/TLS and RADIUS/DTLS. These extensions permit the negotiation of
an application protocol variant of RADIUS, called "RADIUS/1.1". No changes are
made to RADIUS/UDP or RADIUS/TCP. The extensions allow the negotiation of a tra
nsport profile where the RADIUS shared secret is no longer used, and all MD5-bas
ed packet authentication and attribute obfuscation methods are removed.</t>
<t>This document updates RFC2865, RFC2866, RFC5176, RFC6613, RFC6614, and
RFC 7360.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-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/bro
wse/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.g
it"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 81?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The RADIUS protocol <xref target="RFC2865"/> uses MD5 <xref target="RFC
1321"/> to authenticate packets, and to obfuscate certain attributes. Additiona <t>The RADIUS protocol <xref target="RFC2865"/> uses MD5 <xref
l transport protocols were defined for TCP (<xref target="RFC6613"/>), TLS (<xre target="RFC1321"/> to authenticate packets and to obfuscate certain
f target="RFC6614"/>), and DTLS (<xref target="RFC7360"/>). However, those tran attributes. Additional transport protocols were defined for TCP <xref
sport protocols still use MD5 to authenticate individual packets. That is, the target="RFC6613"/>, TLS <xref target="RFC6614"/>, and DTLS <xref
shared secret was used along with MD5, even when the RADIUS packets were being t target="RFC7360"/>. However, those transport protocols still use MD5
ransported in (D)TLS. At the time, the consensus of the RADEXT working group wa to authenticate individual packets. That is, the shared secret was used
s that this continued use of MD5 was acceptable. TLS was seen as a simple "wrap along with MD5, even when the RADIUS packets were being transported in
per" around RADIUS, while using a fixed shared secret. The intention at the tim (D)TLS. At the time, the consensus of the RADEXT Working Group was that
e was to allow the use of (D)TLS while making essentially no changes to the basi this continued use of MD5 was acceptable. TLS was seen as a simple
c RADIUS encoding, decoding, authentication, and packet validation.</t> "wrapper" around RADIUS, while using a fixed shared secret. The
<t>Issues of MD5 security have been known for decades, most most notably i intention at the time was to allow the use of (D)TLS while making
n <xref target="RFC6151"/>, and in <xref section="3" sectionFormat="comma" targe essentially no changes to the basic RADIUS encoding, decoding,
t="RFC6421"/>, among others. The reliance on MD5 for security makes it impossib authentication, and packet validation.</t>
le to use RADIUS in secure systems which forbid the use of digest algorithms wit
h known vunerabilities. For example, FIPS-140 forbids systems from relying on i <t>Issues of MD5 security have been known for decades, most notably in
nsecure cryptographic methods for security.</t> <xref target="RFC6151"/> and in <xref section="3" sectionFormat="of"
<t>While the use of MD5 in RADIUS/TLS is not known to be insecure, it can target="RFC6421"/>, among others. The reliance on MD5 for security
be difficult for individual organizations to perform cryprographic analyses of t makes it impossible to use RADIUS in secure systems that forbid the use
he protocols that they use. It is much simpler and more practical to simply ver of digest algorithms with known vulnerabilities. For example, FIPS 140
ify that there insecure digests such as MD5 are not used anywhere in the system. forbids systems from relying on insecure cryptographic methods for
Then by definition, the systems are at least not known to be insecure.</t> security <xref target="FIPS-140-3"/>.</t>
<t>In addition, the use of MD5 in RADIUS/TLS and RADIUS/DLTS adds no secur
ity or privacy over that provided by TLS. In hindsight, the decision of the RAD <t>While the use of MD5 in RADIUS/TLS has not been proven to be insecure,
EXT working group to retain MD5 for historic RADIUS/TLS was likely wrong. It wa it has not been proven to be secure. This gap means that it is
s an easy decision to make in the short term, but it has caused ongoing problems difficult to use RADIUS in organizations that require the use of systems
which this document addresses. The author of this document played a part in th that have proven security. Those organizations tend to simply ban the
at original decision, which is now be corrected by this document.</t> use of insecure digests such as MD5 entirely, even if the use of MD5 has
<t>This document defines an Application-Layer Protocol Negotiation (ALPN) no known security impact. While the resulting system might still not be
<xref target="RFC7301"/> extension for RADIUS over (D)TLS which removes the need secure, it at least does not contain any known insecurities.</t>
to use MD5 for (D)TLS, which we call RADIUS/1.1. This specification makes no c
hanges to UDP or TCP transport. The RADIUS/1.1 protocol can best be understood <t>In addition, the use of MD5 in RADIUS/TLS and RADIUS/DLTS adds no
as a transport profile for RADIUS over TLS, rather than a whole-sale revision of security or privacy over that provided by TLS. In hindsight, the
the RADIUS protocol.</t> decision of the RADEXT Working Group to retain MD5 for historic
<t>Systems which implement this transport profile can be more easily verif RADIUS/TLS was likely wrong. It was an easy decision to make in the
ied to be FIPS-140 compliant. A preliminary implementation has shown that only short term, but it has caused ongoing problems that this document
minor code changes are required to support RADIUS/1.1 on top of an existing RADI addresses. The author of this document played a part in that original
US/TLS server implementation, which are:</t> decision, which is now 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 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 be best understood as a transport profile for RADIUS over
TLS, rather than a wholesale revision of the RADIUS protocol.</t>
<t>Systems that implement this transport profile can be more easily
verified to be 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. These include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>A method to set the list of supported ALPN protocols before the TLS <li>A method to set the list of supported ALPN protocols before the TLS
handshake starts</li> handshake starts.</li>
<li>After the TLS handshake has completed, a method to query if ALPN has <li>A method to query if ALPN has chosen a protocol (and if yes, which
chosen a protocol, and if yes, which protocol was chosen.</li> protocol was chosen) after the TLS handshake has completed.</li>
<li>Changes to the packet encoder and decoder, so that the individual pa <li>Changes to the packet encoder and decoder, so that the individual
ckets are not authenticated, and no attribute is encoded with the historic obfus packets are not authenticated, and no attribute is encoded with the
cation methods.</li> historic obfuscation methods.</li>
</ul> </ul>
<t>That is, the bulk of the ALPN protocol can be left to the underlying TL
S implementation. This document discusses the ALPN exchange in detail in order <t>That is, the bulk of the ALPN protocol can be left to the underlying
to give simplified descriptions for the reader, and so that the reader does not TLS implementation. This document discusses the ALPN exchange in detail
have to read or understand all of <xref target="RFC7301"/>.</t> in order to give simplified descriptions for the reader, and so that the
<t>The detailed list of changes from historic TLS-based transports to RADI reader does not have to read or understand all of <xref
US/1.1 is as follows:</t> 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"> <ul spacing="normal">
<li>ALPN is used for negotiation of this extension,</li> <li>ALPN is used for negotiation of this extension.</li>
<li>TLS 1.3 or later is required,</li> <li>TLS 1.3 or later is required.</li>
<li>All uses of the RADIUS shared secret have been removed,</li> <li>All uses of the RADIUS shared secret have been removed.</li>
<li>The now-unused Request and Response Authenticator fields have been r <li>The now unused Request and Response Authenticator fields have been
epurposed to carry an opaque Token which identifies requests and responses,</li> repurposed to carry an opaque Token that identifies requests and
<li>The functionality of the Identifier field has been replaced by the T responses.</li>
oken field, and the space previously taken by the Identifier field is now reserv <li>The functionality of the Identifier field has been replaced by the
ed and unused,</li> Token field, and the space previously taken by the Identifier field is
<li>The Message-Authenticator attribute (<xref section="3.2" sectionForm now reserved and unused.</li>
at="comma" target="RFC3579"/>) is not sent in any packet, and if received is ign <li>The Message-Authenticator attribute (<xref section="3.2"
ored,</li> sectionFormat="comma" target="RFC3579"/>) is not sent in any packet,
<li>Attributes such as User-Password, Tunnel-Password, and MS-MPPE keys and is ignored if received.</li>
are sent encoded as "text" (<xref section="3.4" sectionFormat="comma" target="RF <li>Attributes such as User-Password, Tunnel-Password, and MS-MPPE keys
C8044"/>) or "octets" (<xref section="3.5" sectionFormat="comma" target="RFC8044 are sent encoded as "text" (<xref section="3.4"
"/>), without the previous MD5-based obfuscation. This obfuscation is no longer sectionFormat="comma" target="RFC8044"/>) or "octets" (<xref
necessary, as the data is secured and kept private through the use of TLS,</li> section="3.5" sectionFormat="comma" target="RFC8044"/>), without the
<li>The conclusion of the efforts stemming from <xref target="RFC6421"/> previous MD5-based obfuscation. This obfuscation is no longer
is that crypto-agility in RADIUS is best done via a TLS wrapper, and not by ext necessary, as the data is secured and kept private through the use of
ending the RADIUS protocol.</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> <li>
<xref target="RFC5176"/> is updated to allow the Error-Cause attribute <xref target="RFC5176"/> is updated to allow the Error-Cause
to appear in Access-Reject packets.</li> attribute to appear in Access-Reject packets.</li>
</ul> </ul>
<t>The following items are left unchanged from traditional TLS-based trans
ports for RADIUS:</t> <t>The following items are left unchanged from historic TLS-based
transports for RADIUS:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The RADIUS packet header is the same size, and the Code and Length f <li>The RADIUS packet header is the same size, and the Code and Length
ields (<xref section="3" sectionFormat="comma" target="RFC2865"/>) have the same fields (<xref section="3" sectionFormat="comma" target="RFC2865"/>)
meaning as before,</li> have the same meaning as before.</li>
<li>The default 4K packet size is unchanged, although <xref target="RFC7
930"/> can still be leveraged to use larger packets,</li> <li>The default 4096-octet packet size from <xref target="RFC2865"
<li>All attributes which have simple encodings (that is, attributes whic sectionFormat="comma" section="3"/> is unchanged, although <xref
h do not use MD5 obfuscation) have the same encoding and meaning as before,</li> target="RFC7930"/> can still be leveraged to use larger packets.</li>
<li>As this extension is a transport profile for one "hop" (client to se
rver connection), it does not impact any other connection used by a client or se <li>All attributes that have simple encodings (that is, attributes
rver. The only systems which are aware that this transport profile is in use ar that do not use MD5 obfuscation) have the same encoding and meaning
e the client and server who have negotiated the use of this extension on a parti as before.</li>
cular shared connection,</li>
<li>This extension uses the same ports (2083/tcp and 2083/udp) which are <li>As this extension is a transport profile for one "hop"
defined for RADIUS/TLS <xref target="RFC6614"/> and RADIUS/DTLS <xref target="R (client-to-server connection), it does not impact any other connection
FC7360"/>.</li> used by a client or server. The only systems 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>
<li>This extension uses the same ports (2083/tcp and 2083/udp) that
are defined for RADIUS/TLS <xref target="RFC6614"/> and RADIUS/DTLS
<xref target="RFC7360"/>.</li>
</ul> </ul>
<t>A major benefit of this extension is that a server which implements it
can also be more easily verified for FIPS-140 compliance. That is, a server can <t>A major benefit of this extension is that a server that implements it
remove all uses of MD5, which means that those algorithms are provably not used can also be more easily verified for FIPS 140 compliance. That is, a
for security purposes. In that case, however, the server will not support CHAP server can remove all uses of MD5, which means that those algorithms are
, or any authentication method which uses MD5. The choice of which authenticati provably not used for security purposes. In that case, however, the
on method to accept is always left to the server. This specification does not c server will not support the Challenge Handshake Authentication Protocol
hange any authentication method carried in RADIUS, and does not mandate (or forb (CHAP) or any authentication method that uses MD5. The choice of which
id) the use of any authentication method for any system.</t> authentication method to accept is always left to the server. This
<t>As for proxies, there was never a requirement that proxies implement CH specification does not change any authentication method carried in
AP or MS-CHAP authentication. So far as a proxy is concerned, attributes relati RADIUS, and does not mandate (or forbid) the use of any authentication
ng to CHAP and MS-CHAP are simply opaque data that is transported unchanged to t method for any system.</t>
he next hop. It is therefore possible for a FIPS-140 compliant proxy to transpo
rt authentication methods which depend on MD5, so long as that data is forwarded <t>As for proxies, there was never a requirement that proxies implement
to a server which supports those methods.</t> CHAP or Microsoft CHAP (MS-CHAP) authentication. So far as a proxy is con
<t>We reiterate that the decision to support (or not) any authentication m cerned, attributes relating to
ethod is entirely site local, and is not a requirement of this specification. T CHAP and MS-CHAP are simply opaque data that is transported unchanged to
he contents or meaning of any RADIUS attribute other than Message-Authenticator the next hop. Therefore, it is possible for a FIPS 140 compliant proxy
(and similar attributes) are not modified. The only change to the Message-Authe to transport authentication methods that depend on MD5, so long as that
nticator attribute is that it is no longer used in RADIUS/1.1.</t> data is forwarded to a server that supports those methods.</t>
<t>Unless otherwise described in this document, all RADIUS requirements ap
ply to this extension. That is, this specification defines a transport profile <t>We reiterate that the decision to support (or not support) any authenti
for RADIUS. It is not an entirely new protocol, and it defines only minor chang cation
es to the existing RADIUS protocol. It does not change the RADIUS packet format method is entirely site local, and is not a requirement of this
, attribute format, etc. This specification is compatible with all RADIUS attri specification. The contents or meaning of any RADIUS attribute other
butes, past, present, and future.</t> than the Message-Authenticator (and similar attributes) are not modified.
<t>This specification is compatible with existing implementations of RADIU The only change to the Message-Authenticator attribute is that it is no
S/TLS and RADIUS/DTLS. Systems which implement this standard can fall back to h longer used in RADIUS/1.1.</t>
istoric RADIUS/TLS if no ALPN signaling is performed, and the local configuratio
n permits such fallback.</t> <t>Unless otherwise described in this document, all RADIUS requirements
<t>This specification is compatible with all existing RADIUS specification apply to this extension. That is, this specification defines a
s. There is no need for any RADIUS specification to mention this transport prof transport profile for RADIUS. It is not an entirely new protocol, and
ile by name, or to make provisions for this specification. This document define it defines only minor changes to the existing RADIUS protocol. It does
s how to transform RADIUS into RADIUS/1.1, and no further discussion of that tra not change the RADIUS packet format, attribute format, etc. This
nsformation is necessary.</t> specification is compatible with all RADIUS attributes of the past, presen
<t>We note that this document makes no changes to previous RADIUS specific t,
ations. Existing RADIUS implementations can continue to be used without modific and future.</t>
ation. Where previous specifications are explicitly mentioned and updated, thos
e updates or changes apply only when the RADIUS/1.1 transport profile is being u <t>This specification is compatible with existing implementations of
sed.</t> RADIUS/TLS and RADIUS/DTLS. Systems that implement this specification can
<t>In short, when negotiated on a connection, the RADIUS/1.1 transport pro fall back to historic RADIUS/TLS if no ALPN signaling is performed, and
file permits implementations to avoid MD5 when authenticating packets, or when o the local configuration permits such fallback.</t>
bfuscating certain attributes.</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 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 or when obfuscating certain attributes.</t>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and ",
only when, they "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
appear in all capitals, as shown here. "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<?line -6?> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</t> be
<t>The following list describes the terminology and abbreviations which ar interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
e used in this document.</t> target="RFC8174"/> when, and only when, they appear in all capitals, as
<ul spacing="normal"> shown here.
<li>ALPN</li> </t>
</ul>
<ul empty="true"> <t>The following list describes the terminology and abbreviations that are
<li> used in this document.</t>
<t>Application-Layer Protocol Negotiation, as defined in <xref target=
"RFC7301"/>.</t> <dl spacing="normal" newline="true">
</li> <dt>ALPN</dt>
</ul> <dd>Application-Layer Protocol Negotiation (as defined in <xref target="
<ul spacing="normal"> RFC7301"/>).</dd>
<li>RADIUS</li>
</ul> <dt>RADIUS</dt>
<ul empty="true"> <dd>
<li> <t>Remote Authentication Dial-In User Service (as defined in <xref targ
<t>The Remote Authentication Dial-In User Service protocol, as defined et="RFC2865"/>, <xref target="RFC2866"/>, and
in <xref target="RFC2865"/>, <xref target="RFC2866"/>, and <xref target="RFC517 <xref target="RFC5176"/>, among others).</t>
6"/> among others.</t> <t>While this protocol can be viewed as "RADIUS/1.0", for simplicity
<t>While this protocol can be viewed as "RADIUS/1.0", for simplicity a and historical compatibility, we keep the name "RADIUS".</t>
nd historical compatibility, we keep the name "RADIUS".</t> </dd>
</li>
</ul> <dt>RADIUS/UDP</dt>
<ul spacing="normal"> <dd>RADIUS over the User Datagram Protocol (see <xref target="RFC2865"
<li>RADIUS/UDP</li> />,
</ul> <xref target="RFC2866"/>, and <xref target="RFC5176"/>, among others).
<ul empty="true"> </dd>
<li>
<t>RADIUS over the User Datagram Protocol <xref target="RFC2865"/>, <x <dt>RADIUS/TCP</dt>
ref target="RFC2866"/>, <xref target="RFC5176"/>, among others.</t> <dd>RADIUS over the Transmission Control Protocol <xref target="RFC661
</li> 3"/>.</dd>
</ul>
<ul spacing="normal"> <dt>RADIUS/TLS</dt>
<li>RADIUS/TCP</li> <dd>RADIUS over Transport Layer Security <xref target="RFC6614"/>.</dd
</ul> >
<ul empty="true">
<li> <dt>RADIUS/DTLS</dt>
<t>RADIUS over the Transmission Control Protocol <xref target="RFC6613 <dd>RADIUS over Datagram Transport Layer Security <xref target="RFC736
"/>.</t> 0"/>.</dd>
</li>
</ul> <dt>RADIUS over TLS</dt>
<ul spacing="normal"> <dd>Refers to any RADIUS packets transported over TLS or DTLS. This
<li>RADIUS/TLS</li> terminology is used instead of alternatives such as "RADIUS/(D)TLS"
</ul> or "either RADIUS/TLS or RADIUS/DTLS". This term is generally used
<ul empty="true"> when referring to TLS-layer requirements for RADIUS packet
<li> transport.</dd>
<t>RADIUS over the Transport Layer Security protocol <xref target="RFC
6614"/>.</t> <dt>historic RADIUS/TLS</dt>
</li> <dd>Refers to RADIUS over (D)TLS (as defined in <xref target="RFC6614"
</ul> /> and
<ul spacing="normal"> <xref target="RFC7360"/>). This term does not include the protocol
<li>RADIUS/DTLS</li> defined in this specification.</dd>
</ul>
<ul empty="true"> <dt>RADIUS/1.1</dt>
<li> <dd>
<t>RADIUS over the Datagram Transport Layer Security protocol <xref t <t>RADIUS version 1.1, i.e.,
arget="RFC7360"/>.</t> the transport profile defined in this document. We use
</li> RADIUS/1.1 to refer interchangeably to TLS and DTLS
</ul> transport.</t>
<ul spacing="normal"> </dd>
<li>RADIUS over TLS</li>
</ul> <dt>TLS</dt>
<ul empty="true"> <dd>
<li> <t>Transport Layer Security.
<t>Any RADIUS packets transported over TLS or DTLS. This terminology Generally, when we refer to TLS in this document, we are
is used instead of alternatives such as "RADIUS/(D)TLS", or "either RADIUS/TLS o referring interchangeably to TLS or DTLS transport.</t>
r RADIUS/DTLS". This term is generally used when referring to TLS-layer require </dd>
ments for RADIUS packet transport.</t> </dl>
</li>
</ul>
<ul spacing="normal">
<li>historic RADIUS/TLS</li>
</ul>
<ul empty="true">
<li>
<t>RADIUS over (D)TLS as defined in <xref target="RFC6614"/> and <xref
target="RFC7360"/>. This term does not include the protocol defined in this sp
ecification.</t>
</li>
</ul>
<ul spacing="normal">
<li>RADIUS/1.1</li>
</ul>
<ul empty="true">
<li>
<t>The transport profile defined in this document, which stands for "R
ADIUS version 1.1". 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 Layer Security protocol. Generally when we refer to
TLS in this document, we are referring interchangeably to TLS or DTLS transport.
</t>
</li>
</ul>
</section> </section>
<section anchor="the-radius11-transport-profile-for-radius"> <section anchor="the-radius11-transport-profile-for-radius">
<name>The RADIUS/1.1 Transport profile for RADIUS</name> <name>The RADIUS/1.1 Transport Profile for RADIUS</name>
<t>This section describes the ALPN transport profile in detail. It first <t>This section describes the ALPN transport profile in detail. It
gives the name used for ALPN, and then describes how ALPN is configured and nego first gives the name used for ALPN, and then describes how ALPN is
tiated by client and server. It then concludes by discussing TLS issues such as configured and negotiated by the client and server. It then concludes by
what to do for ALPN during session resumption.</t> discussing TLS issues such as what to do for ALPN during session
resumption.</t>
<section anchor="alpn-name-for-radius11"> <section anchor="alpn-name-for-radius11">
<name>ALPN Name for RADIUS/1.1</name> <name>ALPN Name for RADIUS/1.1</name>
<t>The ALPN name defined for RADIUS/1.1 is as follows:</t> <t>The ALPN name defined for RADIUS/1.1 is as follows:</t>
<ul empty="true">
<li> <dl spacing="normal" newline="true">
<t>"radius/1.1"</t> <dt>"radius/1.1"</dt>
<ul empty="true"> <dd>The protocol defined by this specification.</dd>
<li> </dl>
<t>The protocol defined by this specification.</t>
</li> <t>Where ALPN is not configured or is not received in a TLS
</ul> connection, systems supporting ALPN <bcp14>MUST NOT</bcp14> use
</li> RADIUS/1.1.</t>
</ul>
<t>Where ALPN is not configured or is not received in a TLS connection, <t>Where ALPN is configured, the client signals support by sending
systems supporting ALPN MUST NOT use RADIUS/1.1.</t> ALPN strings listing which protocols it supports. The server can
<t>Where ALPN is configured, the client signals support by sending ALPN accept one of these proposals and reply with a matching ALPN string,
strings listing which protocols it supports. The server can accept one of these or reject this proposal and not reply with any ALPN string. A full
proposals and reply with a matching ALPN string, or reject this proposal, and n walkthrough of the protocol negotiation is given below.</t>
ot reply with any ALPN string. A full walk-through of the protocol negotiation
is given below.</t> <t>Implementations <bcp14>MUST</bcp14> signal ALPN "radius/1.1" in
<t>Implementations MUST signal ALPN "radius/1.1" in order for it to be u order for it to be used in a connection.</t>
sed in a connection.</t>
<t>The next step in defining RADIUS/1.1 is to review how ALPN works.</t> <t>The next step in defining RADIUS/1.1 is to review how ALPN
works.</t>
</section> </section>
<section anchor="operation-of-alpn"> <section anchor="operation-of-alpn">
<name>Operation of ALPN</name> <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 brie <t>In order to provide a high-level description of ALPN for readers
f overview here.</t> who are not familiar with the details of <xref target="RFC7301"/>, we
<t>Once a system has been configured to support ALPN, it is negotiated o provide a brief overview here.</t>
n a per-connection basis as per <xref target="RFC7301"/>. The negotiation proce
eds as follows:</t> <t>Once a system has been configured to support ALPN, it is negotiated
<t>1) The client sends an ALPN extension in the ClientHello. This exten on a per-connection basis as per <xref target="RFC7301"/>. The
sion lists one or more application protocols by name. These names are the proto negotiation proceeds as follows:</t>
cols which the client is claiming to support.</t>
<t>2) The server receives the extension, and validates the application p <ol spacing="normal" type="%d)">
rotocol name(s) against the list it has configured.</t> <li>The client sends an ALPN extension in the ClientHello. This
<ul empty="true"> extension lists one or more application protocols by name. These
names are the protocols that the client is claiming to support.</li>
<li> <li>
<t>If the server finds no acceptable common protocols (ALPN or other <t>The server receives the extension and validates the
wise), it closes the connection.</t> application protocol name(s) against the list it has
configured.</t>
<t>If the server finds no acceptable common protocols (ALPN or
otherwise), it closes the connection.</t>
</li> </li>
</ul>
<t>3) Otherwise, the server returns a ServerHello with either no ALPN ex
tension, or an ALPN extension containing only one named application protocol, wh
ich needs to be one of the names proposed by the client.</t>
<ul empty="true">
<li> <li>
<t>If the client did not signal ALPN, or the server does not accept <t>Otherwise, the server returns a ServerHello with either no ALPN
the ALPN proposal, the server does not reply with any ALPN name.</t> extension or an ALPN extension containing only one named
application protocol, which needs to be one of the names proposed
by the client.</t>
<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> </li>
</ul>
<t>4) The client receives the ServerHello, validates the received applic
ation protocol (if any) against the name(s) it sent, and records which applicati
on protocol was chosen.</t>
<ul empty="true">
<li> <li>
<t>This check is necessary in order for the client to both know whic <t>The client receives the ServerHello, validates the received
h protocol the server has selected, and to validate that the protocol sent by th application protocol (if any) against the name(s) it sent, and
e server is one which is acceptable to the client.</t> records which application protocol was chosen.</t>
<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 that is acceptable to the
client.</t>
</li> </li>
</ul> </ol>
<t>The next step in defining RADIUS/1.1 is to define how ALPN is configu <t>The next step in defining RADIUS/1.1 is to define how ALPN is
red on the client and server, and to give more detailed requirements on its conf configured on the client and server and to give more detailed
iguration and operation.</t> requirements on its configuration and operation.</t>
</section> </section>
<section anchor="configuration-of-alpn-for-radius11"> <section anchor="configuration-of-alpn-for-radius11">
<name>Configuration of ALPN for RADIUS/1.1</name> <name>Configuration of ALPN for RADIUS/1.1</name>
<t>Clients or servers supporting this specification can do so by extendi <t>Clients or servers supporting this specification can do so by
ng their TLS configuration through the addition of a new configuration variable, extending their TLS configuration through the addition of a new
called "Version" here. The exact name given below does not need to be used, bu configuration variable, called "Version" here. The exact name given
t it is RECOMMENDED that administrative interfaces or programming interfaces use below does not need to be used, but it is <bcp14>RECOMMENDED</bcp14>
a similar name in order to provide consistent terminology. This variable contr that administrative interfaces or programming interfaces use a similar
ols how the implementation signals use of this protocol via ALPN.</t> name in order to provide consistent terminology. This variable
<t>When set, this variable should contain the list of permitted RADIUS v controls how the implementation signals use of this protocol via
ersions as numbers, e.g. "1.0" or "1.1". The implementation may allow multiple ALPN.</t>
values in one variable, or allow multiple variables, or instead use two configur
ation for "minimum" and "maximum" allowed versions. We assume here that there i <t>When set, this variable should contain the list of permitted RADIUS
s one variable, which can contain either no value, or else a list of one or more versions as numbers, e.g., "1.0" or "1.1". The implementation may
versions which the current implementation supports. In this specification, the allow multiple values in one variable, allow multiple variables, or
possible values, ALPN strings, and corresponding interpretations are:</t> instead use two configurations for the "minimum" and "maximum" allowed
<artwork><![CDATA[ versions. We assume here that there is one variable, which can
Value | ALPN String(s) | Interpretation contain either no value or a list of one or more versions that the
unset | | no ALPN strings are sent. current implementation supports. In this specification, the possible
1.0 | radius/1.0 | require historic RADIUS/TLS values, ALPN strings, and corresponding interpretations are:</t>
1.0, 1.1 | radius/1.0, radius/1.1 | allow either historic
| | RADIUS/TLS or RADIUS/1.1. <table anchor="alpn-configuration-for-radius11" align="center">
1.1 | radius/1.1 | require RADIUS/1.1. <name></name>
]]></artwork> <thead>
<t>This configuration is also extensible to future RADIUS versions if th <tr>
at extension becomes necessary. New values and ALPN names can simply be added t <th>Value</th>
o the list. Implementations can then negotiate the highest version which is sup <th>ALPN String(s)</th>
ported by both client and server.</t> <th>Interpretation</th>
<t>Implementations SHOULD support both historic RADIUS/TLS and RADIUS/1. </tr>
1. Such implementations MUST set the default value for this configuration varia </thead>
ble to "1.0, 1.1". This setting ensures that both versions of RADIUS can be neg <tbody>
otiated.</t> <tr>
<t>Implementations MAY support only RADIUS/1.1. In which case the defau <td>unset</td>
lt value for this configuration variable MUST be "1.1". This behavior is NOT RE <td></td>
COMMENDED, as it is incompatible with historic RADIUS/TLS. This behavior can on <td>no ALPN strings are sent</td>
ly be a reasonable default when all (or nearly all) RADIUS clients have been upd </tr>
ated to support RADIUS/1.1.</t> <tr>
<t>A more detailed definition of the variable and the meaning of the val <td>1.0</td>
ues is given below.</t> <td>radius/1.0</td>
<t>Configuration Variable Name</t> <td>require historic RADIUS/TLS</td>
<ul empty="true"> </tr>
<li> <tr>
<t>Version</t> <td>1.0, 1.1</td>
</li> <td>radius/1.0, radius/1.1</td>
</ul> <td>allow either historic RADIUS/TLS or RADIUS/1.1</td>
<t>Values</t> </tr>
<ul empty="true"> <tr>
<li> <td>1.1</td>
<t>When the variable is unset, ALPN is not used.</t> <td>radius/1.1</td>
<t>Any connection MUST use historic RADIUS/TLS.</t> <td>require RADIUS/1.1</td>
<t>This variable is included here only for logical completeness. Im </tr>
plementations of this specification SHOULD be configured to always send one or m </tbody>
ore ALPN strings. This data signals that the implementation is capable performi </table>
ng ALPN negotiation, even if it is not currently configured to use RADIUS/1.1</t
> <t>This configuration is also extensible to future RADIUS versions if
<ul empty="true"> that extension becomes necessary. New values and ALPN names can
<li> simply be added to the list. Implementations can then negotiate the
<t>Client Behavior</t> highest version that is supported by both client and server.</t>
<ul empty="true">
<li> <t>Implementations <bcp14>SHOULD</bcp14> support both historic
<t>The client MUST NOT send any protocol name via ALPN.</t> RADIUS/TLS and RADIUS/1.1. Such implementations <bcp14>MUST</bcp14>
</li> set the default value for this configuration variable to "1.0, 1.1".
</ul> This setting ensures that both versions of RADIUS can be
<t>Server Behavior</t> negotiated.</t>
<ul empty="true">
<li> <t>Implementations <bcp14>MAY</bcp14> support only RADIUS/1.1. In
<t>The server MUST NOT signal any protocol name via ALPN.</t this case, the default value for this configuration variable
> <bcp14>MUST</bcp14> be "1.1". This behavior is <bcp14>NOT
<t>If the server receives an ALPN name from the client, it M RECOMMENDED</bcp14>, as it is incompatible with historic RADIUS/TLS.
UST NOT close the connection. Instead, it simply does not reply with ALPN, and This behavior can only be a reasonable default when all (or nearly
finishes the TLS connection setup as defined for historic RADIUS/TLS.</t> all) RADIUS clients have been updated to support RADIUS/1.1.</t>
<t>Note that if a client sends "radius/1.1", the client will
see that the server failed to acknowledge this request, and will close the conn <t>A more detailed definition of the variable and the meaning of the
ection. For any other client configuration, the connection will use historic RA values is given below.</t>
DIUS/TLS.</t>
</li> <!-- [rfced] Section 3.3: Please review the following questions regarding the
</ul> list that appears in this section.
</li>
</ul> a) Is this list intended to directly correspond to the preceding table
</li> (now Table 1)? If so, please let us know if it should be updated, as
</ul> "Configuration Variable Name" does not appear in the table.
<ul empty="true">
<li> Original:
<t>Other values ("1.0", "1.0, 1.1", "1.1", etc.)</t> A more detailed definition of the variable and the meaning of the
<ul empty="true"> values is given below.
<li>
<t>Client Behavior</t> Configuration Variable Name
<ul empty="true">
<li> Version
<t>The client MUST send the ALPN string(s) associated with t
he configured version. e.g. For "1.0", send "radius/1.0".</t> c) Please clarify this usage of either / or / or else. Are there three
<t>The client will receive either no ALPN response from the alternatives? (Also, seemingly "with" was meant to be "which"; we changed it
server, or an ALPN response of one version string with MUST match one of the str to "that".)
ings it sent, or else a TLS alert of "no_application_protocol" (120).</t>
<t>If the connection remains open, the client MUST treat the Original:
connection as using the matching ALPN version.</t> The client will receive either no ALPN response from the server, or
</li> an ALPN response of one version string with MUST match one of the
</ul> strings it sent, or else a TLS alert of "no_application_protocol"
<t>Server Behavior</t> (120).
<ul empty="true">
<li> Option A ("either X, Y, or Z"):
<t>If the server receives no ALPN name from the client, it M The client will receive either no ALPN response from the
UST use historic RADIUS/TLS.</t> server. an ALPN response of one version string that MUST
<t>If the server receives one or more ALPN names from the cl match one of the strings it sent, or a TLS alert of
ient, it MUST reply with the highest mutually supported version and then use the "no_application_protocol" (120).
latest supported version for this connection.</t>
<t>If the server receives one or more ALPN names from the cl Option B ("X, Y, or Z"):
ient, but none of the names match the versions supported by (or configured on) t The client will receive no ALPN response from the server, an
he server, it MUST reply with a TLS alert of "no_application_protocol" (120), an ALPN response of one version string that MUST match one of
d then MUST close the TLS connection.</t> the strings it sent, or a TLS alert of
<t>These requirements for negotiation are not specific to RA "no_application_protocol" (120).
DIUS/1.1, and therefore can be used unchanged if any new version of RADIUS is de -->
fined.</t>
</li> <dl newline="true" spacing="normal">
</ul> <dt>Configuration Variable Name</dt>
</li> <dd>Version</dd>
</ul> </dl>
</li>
</ul> <dl newline="true" spacing="normal">
<t>By requiring the default configuration to allow historic RADIUS/TLS, <dt>For "Value":</dt>
implementations will be able to negotiate both historic RADIUS/TLS connections, <dd>
and also RADIUS/1.1 connections. Any other recommended default setting would pr <ol type="A">
event either the negotiation of historic RADIUS/TLS, or prevent the negotiation <li>
of RADIUS/1.1.</t> <t>If unset, ALPN is not used.</t>
<t>Once administrators verify that both ends of a connection support RAD <t>Any connection <bcp14>MUST</bcp14> use historic RADIUS/TLS.</t>
IUS/1.1, and that it has been negotiated successfully, the configurations SHOULD <t>This variable is included here only for logical
be updated to require RADIUS/1.1. The connections should be monitored after th completeness. Implementations of this specification
is change to ensure that the systems continue to remain connected. If there are <bcp14>SHOULD</bcp14> be configured to always send one or more ALPN
connection issues, then the configuration should be reverted to using allow bot strings. This data signals that the implementation is capable of
h "radius/1.0" and "radius/1.1" ALPN strings, until such time as the connection performing ALPN negotiation, even if it is not currently configured to
problems have been resolved.</t> use RADIUS/1.1.</t>
<t>We reiterate that systems implementing this specification, but which
are configured with setting that forbid RADIUS/1.1, will behave largely the same <dl newline="true" spacing="normal">
as systems which do not implement this specification. The only difference is t <dt>Client Behavior</dt>
hat clients may send the ALPN name "radius/1.0".</t> <dd>The client <bcp14>MUST NOT</bcp14> send any protocol name via ALPN
<t>Systems implementing RADIUS/1.1 SHOULD NOT be configured by default t .</dd>
o forbid that protocol. That setting exists mainly for completeness, and to giv
e administrators the flexibility to control their own deployments.</t> <dt>Server Behavior</dt>
<t>While <xref target="RFC7301"/> does not discuss the possibility of th <dd>
e server sending a TLS alert of "no_application_protocol" (120) when the client <t>The server <bcp14>MUST NOT</bcp14> signal any protocol name via
does not use ALPN, this behavior appears to be useful. As such, servers MAY sen ALPN.</t>
d a a TLS alert of "no_application_protocol" (120) when the client does not use <t>If the server receives an ALPN name from the client, it
ALPN.</t> <bcp14>MUST NOT</bcp14> close the connection. Instead, it simply
<t>However, some TLS implementations may not permit an application to se does not reply with ALPN and finishes the TLS connection setup as
nd a TLS alert of its choice, at a time of its choice. This limitation means t defined for historic RADIUS/TLS.</t>
hat it is not always possible for an application to send the TLS alert as discus <t>Note that if a client sends "radius/1.1", the client will see
sed in the previous section. The impact is that an implementation may attempt t that the server failed to acknowledge this request and will close
o connect, and then see that the connection fails, but not be able to determine the connection. For any other client configuration, the connection
why that failure has occurred. Implementers and administrators should be aware will use historic RADIUS/TLS.</t>
that unexplained connection failures may be due to ALPN negotiation issues.</t> </dd>
<t>The server MAY send this alert during the ClientHello, if it requires </dl>
ALPN but does not receive it. That is, there may not always be a need to wait </li>
for the TLS connection to be fully established before realizing that no common A
LPN protocol can be negotiated.</t> <li>
<t>Where the client does perform signaling via ALPN and the server deter <t>If set to "1.0", "1.0, 1.1", "1.1", or future values:</t>
mines that there is no compatible application protocol name, then as per <xref s <dl newline="true" spacing="normal">
ection="3.2" sectionFormat="comma" target="RFC7301"/>, it MUST send a TLS alert <dt>Client Behavior</dt>
of "no_application_protocol" (120).</t> <dd>
<t>Whether or not the server sent a TLS alert for no compatible ALPN, it <t>The client <bcp14>MUST</bcp14> send the ALPN string(s)
MUST close the connection. The above requirements on ALPN apply to both new se associated with the configured version. For example, send
ssions, and to resumed sessions.</t> "radius/1.0" for "1.0".</t>
<t>In contrast, there is no need for the client to signal that there are <t>The client will receive either no ALPN response from the
no compatible application protocol names. The client sends zero or more protoc server; or it will receive an ALPN response of one version string
ol names, and the server responds as above. From the point of view of the clien that <bcp14>MUST</bcp14> match one of the strings it sent; or else th
t, the list it sent results in either a connection failure, or a connection succ ey will
ess.</t> receive a TLS alert of "no_application_protocol" (120).</t>
<t>It is RECOMMENDED that the server logs a descriptive error in this si <t>If the connection remains open, the client <bcp14>MUST</bcp14>
tuation, so that an administrator can determine why a particular connection fail treat the connection as using the matching ALPN version.</t>
ed. The log message SHOULD include information about the other end of the conne </dd>
ction, such as IP address, certificate information, etc. Similarly, when the cl <dt>Server Behavior</dt>
ient receives a TLS alert of "no_application_protocol" it SHOULD log a descripti <dd>
ve error message. Such error messages are critical for helping administrators t <t>If the server receives no ALPN name from the client, it
o diagnose connectivity issues.</t> <bcp14>MUST</bcp14> use historic RADIUS/TLS.</t>
<t>If the server receives one or more ALPN names from the client,
it <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 <bcp14>MUST</bcp14> reply with a TLS
alert of "no_application_protocol" (120), and then it
<bcp14>MUST</bcp14> close the TLS connection.</t>
<t>These requirements for negotiation are not specific to
RADIUS/1.1; therefore, they can be used unchanged if any new
version of RADIUS is defined.</t>
</dd>
</dl>
</li>
</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 and also RADIUS/1.1 connections. Any other
recommended default setting would prevent either the negotiation of
historic 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 <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 allowing both
"radius/1.0" and "radius/1.1" ALPN strings, until the administrator
has resolved the connection problems.</t>
<t>We reiterate that systems implementing this specification, but
which are configured with settings that forbid RADIUS/1.1, will behave
largely the same as systems 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 <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 <bcp14>MAY</bcp14> send 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 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 and then see that
the connection fails, but it may not be able to determine why that failu
re
has occurred. Implementers and administrators should be aware that
unexplained connection failures may be due to ALPN issues.</t>
<t>The server <bcp14>MAY</bcp14> send this alert during the
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, and the server
determines that there is no compatible application protocol name, then
as per <xref section="3.2" sectionFormat="comma" target="RFC7301"/>,
it <bcp14>MUST</bcp14> send a TLS alert of "no_application_protocol"
(120).</t>
<t>The server <bcp14>MUST</bcp14> close the connection whether or not
the server sent a TLS alert for no compatible ALPN. The above
requirements on ALPN apply to both new 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 or a connection success.</t>
<t>It is <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 <bcp14>SHOULD</bcp14>
include information about the other end of the connection, such as the I
P
address, certificate information, etc. Similarly, when the client
receives a TLS alert of "no_application_protocol" (120), it
<bcp14>SHOULD</bcp14> log a descriptive error message. Such error
messages are critical for helping administrators diagnose
connectivity issues.</t>
<section anchor="using-protocol-error-for-signaling-alpn-failure"> <section anchor="using-protocol-error-for-signaling-alpn-failure">
<name>Using Protocol-Error for Signaling ALPN Failure</name> <name>Using Protocol-Error for Signaling ALPN Failure</name>
<t>When it is not possible to send a TLS alert of "no_application_prot
ocol" (120), then the only remaining method for one party to signal the other is <t>When it is not possible to send a TLS alert of
to send application data inside of the TLS tunnel. Therefore, for the situatio "no_application_protocol" (120), then the only remaining method for
n when a one end of a connection determines that it requires ALPN while the othe one party to signal the other is to send application data inside of
r end does not support ALPN, the end requiring ALPN MAY send a Protocol-Error pa the TLS tunnel. Therefore, for the situation when one end of a
cket <xref target="RFC7930"/> inside of the tunnel, and then MUST close the conn connection determines that it requires ALPN, while the other end does
ection. If this is done, the Token field of the Protocol-Error packet cannot be not support ALPN, then the end requiring ALPN <bcp14>MAY</bcp14> send
copied from any request, and therefore that field MUST be set to all zeros.</t> a
<t>The Protocol-Error packet SHOULD contain a Reply-Message attribute Protocol-Error packet <xref target="RFC7930"/> inside of the tunnel
with a textual string describing the cause of the error. The packet SHOULD also and then <bcp14>MUST</bcp14> close the connection. If this is done,
contain an Error-Cause attribute, with value Unsupported Extension (406). The the Token field of the Protocol-Error packet cannot be copied from
packet SHOULD NOT contain other attributes.</t> any request; therefore, that field <bcp14>MUST</bcp14> be set to
<t>An implementation sending this packet could bypass any RADIUS encod all zeros.</t>
er, and simply write this packet as a predefined, fixed set of data to the TLS c
onnection. That process would likely be simpler than trying to call the normal <t>The Protocol-Error packet <bcp14>SHOULD</bcp14> contain a
RADIUS packet encoder to encode a reply packet with no corresponding request pac Reply-Message attribute with a textual string describing the cause
ket.</t> of the error. The packet <bcp14>SHOULD</bcp14> also contain an
<t>As this packet is an unexpected response packet, existing client im Error-Cause attribute, with value 406 (Unsupported Extension). The
plementations of RADIUS over TLS will ignore it. They may either log an error a packet <bcp14>SHOULD NOT</bcp14> contain other attributes.</t>
nd 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 c <t>An implementation sending this packet could bypass any RADIUS
onnection, so there will be no side effects from sending this packet. Therefore encoder and simply write this packet as a predefined, fixed set of
, while using a Protocol-Error packet in this way is unusual, it is both informa data to the TLS connection. That process would likely be simpler
tive and safe.</t> than trying to call the normal RADIUS packet encoder to encode a
<t>The purpose of this packet is not to have the other end of the conn reply packet with no corresponding request packet.</t>
ection automatically determine what went wrong, and fix it. Instead, the packet
is intended to be (eventually) seen by an administrator, who can then take reme <t>As this packet is an unexpected response packet, existing client
dial action.</t> 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 and fix it.
Instead, the packet is intended to be (eventually) seen by an
administrator, who can then take remedial action.</t>
</section> </section>
<section anchor="tabular-summary"> <section anchor="tabular-summary">
<name>Tabular Summary</name> <name>Tabular Summary</name>
<t>The preceding text gives a large number of recommendations. In ord
er to give a simpler description of the outcomes, a table of possible behaviors <t>The preceding text gives a large number of recommendations. In order
for client/server values of the Version variable is given below. This table and to give a simpler description of the outcomes, a table of possible
the names given below are for informational and descriptive purposes only.</t> behaviors for client/server values of the Version variable is given
<figure> below. The row and column headings are the RADIUS version numbers
<name>Possible outcomes for ALPN Negotiation</name> sent in ALPN (or no ALPN). The contents of the table are the
<artwork><![CDATA[ resulting RADIUS version that is negotiated. For clarity, only the
Server RADIUS version numbers have been given, and not the full ALPN
no ALPN | 1.0 | 1.0, 1.1 | 1.1 strings (e.g., "radius/1.0").</t>
Client |--------------------------------------------
No ALPN | TLS TLS TLS Close-S <t>This table and the names given below are for informational and
| descriptive purposes only.</t>
1.0 | TLS TLS TLS Alert
| <table>
1.0, 1.1 | TLS TLS 1.1 1.1 <name>Possible Outcomes for ALPN</name>
| <thead>
1.1 | Close-C Alert 1.1 1.1 <tr>
]]></artwork> <th rowspan="2">Client</th>
</figure> <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> <t>The table entries above have the following meaning:</t>
<ul empty="true">
<li> <dl newline="true" spacing="normal">
<t>Alert</t> <dt>Alert</dt>
<ul empty="true"> <dd>
<li> <t>The client sends ALPN, and the server does not agree to
<t>The client sends ALPN, and the server does not agree to the the client's ALPN proposal. The server replies with a TLS
clients ALPN proposal. The server replies with a TLS alert of "no_application_ alert of "no_application_protocol" (120) and then closes
protocol" (120), and then closes the TLS connection.</t> the TLS connection.</t>
<t>As the server replies with a TLS alert, the Protocol-Error <t>As the server replies with a TLS alert, the
packet is not used here.</t> Protocol-Error packet is not used here.</t>
</li> </dd>
</ul> <dt>Close-C</dt>
<t>Close-C</t> <dd>
<ul empty="true"> <t>The client sends ALPN, but the server does not respond
<li> with ALPN. The client closes the connection.</t>
<t>The client sends ALPN, but the server does not respond with <t>As noted in the previous section, the client
ALPN. The client closes the connection.</t> <bcp14>MAY</bcp14> send a Protocol-Error packet to the
<t>As noted in the previous section, the client MAY send a Pro server before closing the connection.</t>
tocol-Error packet to the server before closing the connection.</t> </dd>
</li> <dt>Close-S</dt>
</ul> <dd>
<t>Close-S</t> <t>The client does not send ALPN string(s), but the server
<ul empty="true"> requires ALPN. The server closes the connection.</t>
<li> <t>As noted in the previous section, the server
<t>The client does not send ALPN string(s), but the server req <bcp14>MAY</bcp14> send a Protocol-Error packet to the
uires ALPN. The server closes the connection.</t> client before closing the connection. The server
<t>As noted in the previous section, the server MAY send a Pro <bcp14>MAY</bcp14> also send a TLS alert of
tocol-Error packet to the client before closing the connection. The server MAY "no_application_protocol" (120) before closing the
also send a TLS alert of "no_application_protocol" (120) before closing the conn connection.</t>
ection.</t> </dd>
</li> <dt>TLS</dt>
</ul> <dd>
<t>TLS</t> <t>Historic RADIUS/TLS is used. The client either sends no
<ul empty="true"> ALPN string or sends "radius/1.0". The server either
<li> replies with no ALPN string or with "radius/1.0". The
<t>Historic RADIUS/TLS is used. The client either sends no AL connection <bcp14>MUST</bcp14> use historic RADIUS/TLS.</t>
PN string, or sends "radius/1.0". The server either replies with no ALPN string </dd>
, or with "radius/1.0". The connection MUST use historic RADIUS/TLS.</t> <dt>1.1</dt>
</li> <dd>
</ul> <t>The client sends the ALPN string "radius/1.1". The server
<t>1.1</t> acknowledges this negotiation with a reply of "radius/1.1",
<ul empty="true"> and then RADIUS/1.1 is used.</t>
<li> </dd>
<t>The client sends the ALPN string "radius/1.1. The server a </dl>
cknowledges this negotiation with a reply of "radius/1.1", and then RADIUS/1.1 i
s used.</t> <t>Implementations should note that this table may be extended in
</li> future specifications. The above text is informative, and does not
</ul> mandate that only the above ALPN strings are used. The actual ALPN
</li> takes place as defined in the preceding sections of this document
</ul> and in <xref target="RFC7301"/>.</t>
<t>Implementations should note that this table may be extended in futu
re specifications. The above text is informative, and does not mandate that onl
y the above ALPN strings are used. The actual ALPN negotiation takes place as d
efined in the preceding sections of this document, and in <xref target="RFC7301"
/>.</t>
</section> </section>
</section> </section>
<section anchor="miscellaneous-items"> <section anchor="miscellaneous-items">
<name>Miscellaneous Items</name> <name>Miscellaneous Items</name>
<t>Implementations of this specification MUST require TLS version 1.3 or <t>Implementations of this specification <bcp14>MUST</bcp14> require
later.</t> TLS version 1.3 or later.</t>
<t>The use of the ALPN string "radius/1.0" is technically unnecessary, a
s it is largely equivalent to not sending any ALPN string. However, that value <t>The use of the ALPN string "radius/1.0" is technically unnecessary,
is useful for RADIUS administrators. A system which sends the ALPN string "radi as it is largely equivalent to not sending any ALPN string. However,
us/1.0" is explicitly signaling that it supports ALPN negotiation, but that it i that value is useful for RADIUS administrators. A system that sends
s not currently configured to support RADIUS/1.1. That information can be used the ALPN string "radius/1.0" is explicitly signaling that it supports
by administrators to determine which devices are capable of ALPN.</t> ALPN, but that it is not currently configured to support
<t>The use of the ALPN string "radius/1.0" also permits server implement RADIUS/1.1. That information can be used by administrators to
ations to send a TLS alert of "no_application_protocol" (120) when it cannot fin determine which devices are capable of ALPN.</t>
d 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. <t>The use of the ALPN string "radius/1.0" also permits server
However, such a scenario is not discussed on <xref target="RFC7301"/>, and is l implementations to send a TLS alert of "no_application_protocol" (120)
ikely not universal. As a result, ALPN as defined in <xref target="RFC7301"/> p when it cannot find a matching ALPN string. Experiments with TLS
ermits servers to send that TLS alert in situations where it would be otherwise library implementations suggest that in some cases it is possible to
forbidden, or perhaps unsupported.</t> send that TLS alert when ALPN is not used. However, such a scenario
<t>Finally, defining ALPN strings for all known RADIUS versions will mak is not discussed in <xref target="RFC7301"/> and is likely not
e it easier to support additional ALPN strings if that functionality is ever nee universal. As a result, ALPN as defined in <xref target="RFC7301"/>
ded.</t> permits servers to send that TLS alert in situations where it would be
otherwise 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>
<section anchor="session-resumption"> <section anchor="session-resumption">
<name>Session Resumption</name> <name>Session Resumption</name>
<t><xref section="3.1" sectionFormat="comma" target="RFC7301"/> states t
hat ALPN is negotiated on each connection, even if session resumption is used:</ <t><xref section="3.1" sectionFormat="comma" target="RFC7301"/> states
t> that ALPN is negotiated on each connection, even if session resumption
<ul empty="true"> is used:</t>
<li>
<t>When session resumption or session tickets <xref target="RFC5077" <blockquote>When session resumption or session tickets <xref
/> are used, the previous contents of this extension are irrelevant, and only th target="RFC5077"/> are used, the previous contents of this extension
e values in the new handshake messages are considered.</t> are irrelevant, and only the values in the new handshake messages are
</li> considered.</blockquote>
</ul>
<t>In order to prevent down-bidding attacks, RADIUS systems which negoti <t>(Note: RFC 5077 was obsoleted by <xref target="RFC8446"/>.)</t>
ate the "radius/1.1" protocol MUST associate that information with the session t
icket, and enforce the use of "radius/1.1" on session resumption. That is, if " <t>In order to prevent down-bidding attacks, RADIUS systems that
radius/1.1" was negotiated for a session, both clients and servers MUST behave a negotiate the "radius/1.1" protocol <bcp14>MUST</bcp14> associate that
s if the RADIUS/1.1 variable was set to "require" for that session.</t> information with the session ticket and enforce the use of
<t>A client which is resuming a "radius/1.1" connection MUST advertise o "radius/1.1" on session resumption. That is, if "radius/1.1" was
nly the capability to do "radius/1.1" for the resumed session. That is, even if negotiated for a session, both clients and servers <bcp14>MUST</bcp14>
the client configuration allows historic RADIUS/TLS for new connections, it MUS behave as if the RADIUS/1.1 variable was set to "require" for that
T signal "radius/1.1" when resuming a session which had previously negotiated "r session.</t>
adius/1.1".</t>
<t>Similarly, when a server does resumption for a session which had prev <t>A client that is resuming a "radius/1.1" connection
iously negotiated "radius/1.1". If the client attempts to resume the sessions <bcp14>MUST</bcp14> advertise only the capability to do "radius/1.1"
without signaling the use of RADIUS/1.1, the server MUST close the connection. for the resumed session. That is, even if the client configuration
The server MUST send an appropriate TLS error, and also SHOULD log a descriptive allows historic RADIUS/TLS for new connections, it <bcp14>MUST</bcp14>
message as described above.</t> signal "radius/1.1" when resuming a session that had previously
<t>In contrast, there is no requirement for a client or server to force negotiated "radius/1.1".</t>
the use of <xref target="RFC6614"/> RADIUS/TLS on session resumption. Clients a
re free to signal support for "radius/1.1" on resumed sessions, even if the orig <t>Similarly, when a server does resumption for a session that had
inal session did not negotiate "radius/1.1". Servers are free to accept this re previously negotiated "radius/1.1", if the client attempts to resume
quest, and to negotiate the use of "radius/1.1" for such sessions.</t> the sessions without signaling the use of RADIUS/1.1, the server
<bcp14>MUST</bcp14> close the connection. The server
<bcp14>MUST</bcp14> send an appropriate TLS error, and also
<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"/> 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 and to
negotiate the use of "radius/1.1" for such sessions.</t>
</section> </section>
</section> </section>
<section anchor="radius11-packet-and-attribute-formats"> <section anchor="radius11-packet-and-attribute-formats">
<name>RADIUS/1.1 Packet and Attribute Formats</name> <name>RADIUS/1.1 Packet and Attribute Formats</name>
<t>This section describes the application-layer data which is sent inside <t>This section describes the application-layer data that is sent
of (D)TLS when using the RADIUS/1.1 protocol. Unless otherwise discussed herein inside of (D)TLS when using the RADIUS/1.1 protocol. Unless otherwise
, the application-layer data is unchanged from traditional RADIUS. This protoco discussed herein, the application-layer data is unchanged from historic RA
l is only used when "radius/1.1" has been negotiated by both ends of a connectio DIUS. This protocol is only used when "radius/1.1" has
n.</t> been negotiated by both ends of a connection.</t>
<section anchor="radius11-packet-format"> <section anchor="radius11-packet-format">
<name>RADIUS/1.1 Packet Format</name> <name>RADIUS/1.1 Packet Format</name>
<t>When RADIUS/1.1 is used, the RADIUS header is modified from standard <t>When RADIUS/1.1 is used, the RADIUS header is modified from
RADIUS. While the header has the same size, some fields have different meaning. standard RADIUS. While the header has the same size, some fields have
The Identifier and the Request / Response Authenticator fields are no longer u different meanings. The Identifier and the Request and Response
sed in RADIUS/1.1. Any operations which depend on those fields MUST NOT be perf Authenticator fields are no longer used in RADIUS/1.1. Any operations
ormed. As packet authentication, secrecy, and security are handled by the TLS l that depend on those fields <bcp14>MUST NOT</bcp14> be performed. As
ayer, RADIUS-specific cryptographic primitives are no longer needed or used in R packet authentication, secrecy, and security are handled by the TLS
ADIUS/1.1.</t> layer, RADIUS-specific cryptographic primitives are no longer needed
<t>A summary of the RADIUS/1.1 packet format is shown below. The fields or used in RADIUS/1.1.</t>
are transmitted from left to right.</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"> <figure anchor="Header">
<name>The RADIUS/1.1 Packet Format</name> <name>The RADIUS/1.1 Packet Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 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 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 | | Code | Reserved-1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token | | Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Reserved-2 | | Reserved-2 |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ... | Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Code</t>
<ul empty="true"> <dl spacing="normal" newline="true">
<li>
<t>The Code field is one octet, and identifies the type of RADIUS pa <dt>Code</dt>
cket.</t> <dd>
<t>The Code field is one octet and identifies the type of RADIUS pac
ket.</t>
<t>The meaning of the Code field is unchanged from previous RADIUS s pecifications.</t> <t>The meaning of the Code field is unchanged from previous RADIUS s pecifications.</t>
</li>
</ul> </dd>
<t>Reserved-1</t> <dt>Reserved-1</dt>
<ul empty="true"> <dd>
<li>
<t>The Reserved-1 field is one octet.</t> <t>The Reserved-1 field is one octet.</t>
<t>This field was previously used as the "Identifier" in historic RA
DIUS/TLS. It is now unused, as the Token field replaces it both as the way to i <t>This field was previously used as the "Identifier" in historic
dentify requests, and to associate responses with requests.</t> RADIUS/TLS. It is now unused, as the Token field replaces it both
<t>When sending packets, the Reserved-1 field MUST be set to zero. as the way to identify requests and to associate responses with
The Reserved-1 field MUST be ignored when receiving a packet.</t> requests.</t>
</li>
</ul> <t>When sending packets, the Reserved-1 field <bcp14>MUST</bcp14>
<t>Length</t> be set to zero. The Reserved-1 field <bcp14>MUST</bcp14> be
<ul empty="true"> ignored when receiving a packet.</t>
<li> </dd>
<dt>Length</dt>
<dd>
<t>The Length field is two octets.</t> <t>The Length field is two octets.</t>
<t>The meaning of the Length field is unchanged from previous RADIUS specifications.</t> <t>The meaning of the Length field is unchanged from previous RADIUS specifications.</t>
</li> </dd>
</ul> <dt>Token</dt>
<t>Token</t> <dd>
<ul empty="true"> <t>The Token field is four octets and aids in matching requests
<li> and replies, as a replacement for the Identifier field. The
<t>The Token field is four octets, and aids in matching requests and RADIUS server can detect a duplicate request if it receives the
replies, as a replacement for the Identifier field. The RADIUS server can detec same Token value for two packets on a particular connection.</t>
t a duplicate request if it receives <t>All values are possible for the Token field. Implementations
the same Token value for two packets on a particular connection.</t> <bcp14>MUST</bcp14> treat the Token as an opaque blob when
<t>All values are possible for the Token field. Implementations MUS comparing Token values.</t>
T treat the Token as an opaque blob when comparing Token values.</t> <t>Further requirements are given below in <xref
<t>Further requirements are given below in <xref target="sending-pac target="sending-packets"/> for sending packets and in <xref
kets"/> for sending packets, and in <xref target="receiving-packets"/> for recei target="receiving-packets"/> for receiving packets.</t>
ving packets.</t> </dd>
</li>
</ul> <dt>Reserved-2</dt>
<t>Reserved-2</t> <dd>
<ul empty="true">
<li>
<t>The Reserved-2 field is twelve (12) octets in length.</t> <t>The Reserved-2 field is twelve (12) octets in length.</t>
<t>These octets MUST be set to zero when sending a packet.</t> <t>These octets <bcp14>MUST</bcp14> be set to zero when sending a pa
<t>These octets MUST be ignored when receiving a packet.</t> cket.</t>
<t>These octets <bcp14>MUST</bcp14> be ignored when receiving a pack
et.</t>
<t>These octets are reserved for future protocol extensions.</t> <t>These octets are reserved for future protocol extensions.</t>
</li> </dd>
</ul> </dl>
</section> </section>
<section anchor="the-token-field"> <section anchor="the-token-field">
<name>The Token Field</name> <name>The Token Field</name>
<t>This section describes in more detail how the Token field is used.</t > <t>This section describes in more detail how the Token field is used.</t >
<section anchor="sending-packets"> <section anchor="sending-packets">
<name>Sending Packets</name> <name>Sending Packets</name>
<t>The Token field MUST change for every new unique packet which is se
nt on the same connection. For DTLS transport, it is possible to retransmit dupl <t>The Token field <bcp14>MUST</bcp14> change for every new unique
icate packets, in which case the Token value MUST NOT be changed when a duplicat packet that is sent on the same connection. For DTLS transport, it
e packet is (re)sent. When the contents of a retransmitted packet change for an is possible to retransmit duplicate packets, in which case the Token
y reason (such changing Acct-Delay-Time as discussed in <xref section="5.2" sect value <bcp14>MUST NOT</bcp14> be changed when a duplicate packet is
ionFormat="comma" target="RFC2866"/>), the Token value MUST be changed. Note th (re)sent. When the contents of a retransmitted packet change for
at on reliable transports, packets are never retransmitted, and therefore every any reason (such as changing Acct-Delay-Time as discussed in <xref
new packet which is sent has a unique Token value.</t> section="5.2" sectionFormat="comma" target="RFC2866"/>), the Token
<t>We note that in previous RADIUS specifications, the Identifier fiel value <bcp14>MUST</bcp14> be changed. Note that on reliable
d could have the same value for different packets on the same connection. For e transports, packets are never retransmitted; therefore, every new
xample, Access-Request (Code 1) and Accounting-Request (Code 4) packets could bo packet that is sent has a unique Token value.</t>
th use ID 3, and still be treated as different packets. This overlap required t
hat RADIUS clients and servers track the Identifier field, not only on a per-con <t>We note that in previous RADIUS specifications, the Identifier
nection basis, but also on a per-Code basis. This behavior adds complexity to i field could have the same value for different packets on the same
mplementations.</t> connection. For example, Access-Request (Code 1) and
<t>In contrast, the Token values MUST be generated from a 32-bit count Accounting-Request (Code 4) packets could both use ID 3 and still
er which is unique to each connection. Such a counter SHOULD be initialized to be treated as different packets. This overlap requires that RADIUS
a random value, taken from a random number generator, whenever a new connection clients and servers track the Identifier field, not only on a
is opened. The counter MUST then be incremented for every unique new packet whi per-connection basis, but also on a per-Code basis. This behavior
ch is sent by the client. Retransmissions of the same packet MUST use the same adds complexity to implementations.</t>
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 trans <t>In contrast, the Token values <bcp14>MUST</bcp14> be generated
missions.</t> from a 32-bit counter that is unique to each connection. Such a
<t>This counter method ensures that the Tokens are unique, and are als counter <bcp14>SHOULD</bcp14> be initialized to a random value,
o independent of any Code value in the RADIUS packet header. This method is man taken from a random number generator, whenever a new connection
dated because any other method of generating unique and non-conflicting Token va is opened. The counter <bcp14>MUST</bcp14> then be incremented for
lues is more complex, with no additional benefit and only the likelihood of incr every unique new packet that is sent by the client. Retransmissions
eased bugs and interoperability issues. Any other method for generating Token v of the same packet <bcp14>MUST</bcp14> use the same unchanged Token
alues would require substantially more resources to track outstanding Token valu value. As the Token value is mandated to be unique per packet, a
es and their associated expiry times. The chance that initial values could pote duplicate Token value is the only way that a server can detect
ntially cause any confusion by being re-used across two connections is one in 2^ duplicate transmissions.</t>
32, which is acceptable.</t>
<t>The purpose for initializing the Token to a random counter is mainl <t>This counter method ensures that the Tokens are unique and are
y to aid administrators in debugging systems. If the Token values always used t also independent of any Code value in the RADIUS packet header.
he same sequence, then it would easier for a person to confuse different packets This method is mandated because any other method of generating
which have the same Token value. By instead starting with a random value, thos unique and non-conflicting Token values is more complex, with no
e values are more evenly distributed across the set of allowed values, and are t additional benefit and only the likelihood of increased bugs and
herefore more likely to be unique.</t> interoperability issues. Any other method for generating Token
<t>As there is no special meaning for the Token, there is no meaning w values would require substantially more resources to track
hen a counter "wraps" around from a high value back to zero. The originating sy outstanding Token values and their associated expiry times. The
stem can simply continue to increment the Token value without taking any special chance that initial values could potentially cause any confusion by
action in that situation.</t> being reused across two connections is one in 2<sup>32</sup>, which
<t>Once a RADIUS response to a request has been received and there is is acceptable.</t>
no need to track the packet any longer, the Token value can be reused. This reu
se happens only when the counter "wraps around" after 2^32 packets have been sen <t>The purpose for initializing the Token to a random counter is
t over one connection. This method of managing the counter automatically ensure mainly to aid administrators in debugging systems. If the Token
s a long delay (i.e. 2^32 packets) between multiple uses of the same Token value values always used the same sequence, then it would easier for a
. This large number of packets ensures that the only possible situation where person to confuse different packets that have the same Token value.
there may be conflict is when a client sends billions of packets a second across By instead starting with a random value, those values are more
one connection, or when a client sends billions of packets without receiving re evenly distributed across the set of allowed values; therefore, they
plies. We suggest that such situations are vanishingly rare. The best solution are more likely to be unique.</t>
to those situations would be to limit the number out outstanding packets over o
ne connection to a number much lower than billions.</t> <t>As there is no special meaning for the Token, there is no meaning
<t>If a RADIUS client has multiple independent subsystems which send p when a counter "wraps" around from a high value back to zero. The
ackets to a server, each subsystem MAY open a new connection which is unique to originating system can simply continue to increment the Token value
that subsystem. There is no requirement that all packets go over one particular without taking any special action in that situation.</t>
connection. That is, despite the use of a 32-bit Token field, RADIUS/1.1 clien
ts are still permitted to open multiple source ports as discussed in <xref targe <t>Once a RADIUS response to a request has been received and there
t="RFC2865"/> Section 2.5.</t> is no need to track the packet any longer, the Token value can be
<t>While multiple connections from client to server are allowed, We re reused. This reuse happens only when the counter "wraps around"
iterate the suggestion of <xref section="3.3" sectionFormat="comma" target="RFC3 after 2<sup>32</sup> packets have been sent over one connection.
539"/> that a single connection is preferred to multiple connections. The use o This method of managing the counter automatically ensures a long
f a single connection can improve throughput and latency, while simplifying the delay (i.e., 2<sup>32</sup> packets) between multiple uses of the
clients efforts to determine server status.</t> 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 of
outstanding packets over one connection to a number much lower than
billions.</t>
<t>If a RADIUS client has multiple independent subsystems that send
packets to a server, each subsystem <bcp14>MAY</bcp14> open a new
connection 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 section="2.5" sectionFormat="comma" target="RFC2865"/>.</t>
<t>While multiple connections from client to server are allowed, 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 client's
efforts to determine server status.</t>
</section> </section>
<section anchor="receiving-packets"> <section anchor="receiving-packets">
<name>Receiving Packets</name> <name>Receiving Packets</name>
<t>A server which receives RADIUS/1.1 packets MUST perform packet dedu <t>A server that receives RADIUS/1.1 packets <bcp14>MUST</bcp14>
plication for all situations where it is required by RADIUS. Where RADIUS does perform packet deduplication for all situations where it is required
not require deduplication (e.g. TLS transport), the server SHOULD NOT do dedupli by RADIUS. Where RADIUS does not require deduplication (e.g., TLS
cation. However, DTLS transport is UDP-based, and therefore still requires dedu transport), the server <bcp14>SHOULD NOT</bcp14> do deduplication.
plication.</t> However, DTLS transport is UDP-based, and therefore still requires
<t>When using RADIUS/1.1, implementations MUST do deduplication only o deduplication.</t>
n the Token field, and not on any other field or fields in the packet header. A
server MUST treat the Token as being an opaque field with no intrinsic meaning. <t>When using RADIUS/1.1, implementations <bcp14>MUST</bcp14> do
This requirement makes the receiver behavior independent of the methods by whic deduplication only on the Token field, and not on any other field or
h the Counter is generated.</t> fields in the packet header. A server <bcp14>MUST</bcp14> treat the
<t>Where Token deduplication is done, it MUST be done on a per-connect Token as being an opaque field with no intrinsic meaning. This
ion basis. If two packets which are received on different connections contain t requirement makes the receiver behavior independent of the methods
he same Token value, then those packets MUST be treated as distinct (i.e. differ by which the Counter is generated.</t>
ent) packets. Systems performing deduplication MAY still track the packet Code,
Length, and Attributes which is associated with a Token value. If it determine <t>Where Token deduplication is done, it <bcp14>MUST</bcp14> be done
s that the sender is re-using Token values for distinct outstanding packets, the on a per-connection basis. If two packets that are received on
n an error should be logged, and the connection MUST be closed. There is no way different connections contain the same Token value, then those
to negotiate correct behavior in the protocol. Either the parties both operate packets <bcp14>MUST</bcp14> be treated as distinct (i.e., different)
normally and can communicate, or one end misbehaves, and no communication is po packets. Systems performing deduplication <bcp14>MAY</bcp14> still
ssible.</t> track the packet Code, Length, and Attributes that are associated
<t>Once a reply has been sent, a system doing deduplication SHOULD cac with a Token value. If it determines that the sender is reusing
he the replies as discussed in <xref section="2.2.2" sectionFormat="comma" targe Token values for distinct outstanding packets, then an error should
t="RFC5080"/>:</t> be logged, and the connection <bcp14>MUST</bcp14> be closed. There
<ul empty="true"> is no way to negotiate correct behavior in the protocol. Either
<li> both parties operate normally and can communicate, or one end
<t>Each cache entry SHOULD be purged after a period of time. This misbehaves and no communication is possible.</t>
time
SHOULD be no less than 5 seconds, and no more than 30 seconds. After <t>Once a reply has been sent, a system doing deduplication
about 30 seconds, most RADIUS clients and end users will have given <bcp14>SHOULD</bcp14> cache the replies as discussed in <xref
up on the authentication request. Therefore, there is little value section="2.2.2" sectionFormat="comma" target="RFC5080"/>:</t>
in having a larger cache timeout.</t>
</li> <blockquote>Each cache entry <bcp14>SHOULD</bcp14> be purged after
</ul> a period of time. This time <bcp14>SHOULD</bcp14> be no less than 5
<t>This change from RADIUS means that the Identifier field is no longe seconds, and no more than 30 seconds. After about 30 seconds, most
r useful for RADIUS/1.1. The Reserved-1 field (previously used as the Identifie RADIUS clients and end users will have given up on the
r) MUST be set to zero when encoding all RADIUS/1.1 packets. Implementations of authentication request. Therefore, there is little value in having
RADIUS/1.1 which receive packets MUST ignore this field.</t> a larger cache 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) <bcp14>MUST</bcp14> be set to zero when encoding
all RADIUS/1.1 packets. Implementations of RADIUS/1.1 that receive
packets <bcp14>MUST</bcp14> ignore this field.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="attribute-handling"> <section anchor="attribute-handling">
<name>Attribute handling</name> <name>Attribute Handling</name>
<t>Most attributes in RADIUS have no special encoding "on the wire", or an <t>Most attributes in RADIUS have no special encoding "on the wire", or
y special meaning between client and server. Unless discussed in this section, any special meaning between client and server. Unless discussed in this
all RADIUS attributes are unchanged in this specification. This requirement inc section, all RADIUS attributes are unchanged in this specification.
ludes attributes which contain a tag, as defined in <xref target="RFC2868"/>.</t This requirement includes attributes that contain a tag, as defined in
> <xref target="RFC2868"/>.</t>
<section anchor="obfuscated-attributes"> <section anchor="obfuscated-attributes">
<name>Obfuscated Attributes</name> <name>Obfuscated Attributes</name>
<t>Since the (D)TLS layer provides for connection authentication, integr
ity checks, and confidentiality, there is no need to hide the contents of an att <t>Since the (D)TLS layer provides for connection authentication,
ribute on a hop-by-hop basis. As a result, all attributes defined as being obfu integrity checks, and confidentiality, there is no need to hide the
scated via the shared secret no longer have the obfuscation step applied when RA contents of an attribute on a hop-by-hop basis. As a result, all
DIUS/1.1 is used. Instead, those attributes MUST be encoded using the encoding attributes defined as being obfuscated via the shared secret no longer
for the underlying data type, with any encryption / obfuscation step omitted. F have the obfuscation step applied when RADIUS/1.1 is used. Instead,
or example, the User-Password attribute is no longer obfuscated, and is instead those attributes <bcp14>MUST</bcp14> be encoded using the encoding for
sent as data type "text".</t> the underlying data type, with any encryption / obfuscation step
<t>There are risks from sending passwords over the network, even when th omitted. For example, the User-Password attribute is no longer
ey are protected by TLS. One such risk comes from the common practice of multi- obfuscated and is instead sent as data type "text".</t>
hop RADIUS routing. As all security in RADIUS is on a hop-by-hop basis, every p
roxy which receives a RADIUS packet can see (and modify) all of the information <t>There are risks from sending passwords over the network, even when
in the packet. Sites wishing to avoid proxies SHOULD use dynamic peer discovery they are protected by TLS. One such risk comes from the common
<xref target="RFC7585"/>, which permits clients to make connections directly to practice of multi-hop RADIUS routing. As all security in RADIUS is on
authoritative servers for a realm.</t> a hop-by-hop basis, every proxy that receives a RADIUS packet can see
<t>There are others ways to mitigate these risks. The simplest is to fo (and modify) all of the information in the packet. Sites wishing to
llow the requirements of <xref section="2.4" sectionFormat="comma" target="RFC66 avoid proxies <bcp14>SHOULD</bcp14> use dynamic peer discovery <xref
14"/> item (3) and <xref section="10.4" sectionFormat="comma" target="RFC7360"/> target="RFC7585"/>, which permits clients to make connections directly
, which mandates that RADIUS over TLS implementations validate the peer before s to authoritative servers for a realm.</t>
ending any RADIUS traffic.</t>
<t>Another way to mitigate these risks is for the system being authentic <t>There are other ways to mitigate these risks. The simplest is to
ated to use an authentication protocol which never sends passwords (e.g. EAP-pwd follow the requirements of item (3) from <xref section="3.4"
<xref target="RFC5931"/>), or which sends passwords protected by a TLS tunnel ( sectionFormat="comma" target="RFC6614"/> and also follow <xref section="
e.g. EAP-TTLS <xref target="RFC5281"/>). The processes to choose and configurin 10.4"
g an authentication protocol are strongly site-dependent, so further discussion sectionFormat="comma" target="RFC7360"/>, which mandates that RADIUS
of these issues are outside of the scope of this document. The goal here is to over TLS implementations validate the peer before sending any RADIUS
ensure that the reader has enough information to make an informed decision.</t> traffic.</t>
<t>We note that as the RADIUS shared secret is no longer used in this sp
ecification, it is no longer possible or necessary for any attribute to be obfus <t>Another way to mitigate these risks is for the system being
cated on a hop-by-hop basis using the previous methods defined for RADIUS.</t> authenticated to use an authentication protocol that never sends
passwords (e.g., an Extensible Authentication Protocol (EAP) method
like EAP-pwd <xref target="RFC5931"/>), or one that sends passwords prot
ected by a
TLS tunnel (e.g., EAP Tunneled Transport Layer Security (EAP-TTLS)
<xref target="RFC5281"/>). The processes to choose and configure an
authentication protocol are strongly site dependent, so further
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"> <section anchor="user-password">
<name>User-Password</name> <name>User-Password</name>
<t>The User-Password attribute (<xref section="5.2" sectionFormat="com <t>The User-Password attribute (<xref section="5.2"
ma" target="RFC2865"/>) MUST be encoded the same as any other attribute of data sectionFormat="comma" target="RFC2865"/>) <bcp14>MUST</bcp14> be
type 'string' (<xref section="3.5" sectionFormat="comma" target="RFC8044"/>).</t encoded the same as any other attribute of data type "string" (<xref
> section="3.5" sectionFormat="comma" target="RFC8044"/>).</t>
<t>The contents of the User-Password field MUST be at least one octet
in length, and MUST NOT be more than 128 octets in length. This limitation is m <t>The contents of the User-Password field <bcp14>MUST</bcp14> be at
aintained from <xref section="5.2" sectionFormat="comma" target="RFC2865"/> for least one octet in length and <bcp14>MUST NOT</bcp14> be more than
compatibility with historic transports.</t> 128 octets in length. This limitation is maintained from <xref
<t>Note that the User-Password attribute is not of data type 'text'. section="5.2" sectionFormat="comma" target="RFC2865"/> for
The original reason in <xref target="RFC2865"/> was because the attribute was en compatibility with historic transports.</t>
coded as an opaque and obfuscated binary blob. This document does not change th
e data type of User-Password, even though the attribute is no longer obfuscated. <t>Note that the User-Password attribute is not of data type "text".
The contents of the User-Password attribute do not have to be printable text, The original reason in <xref target="RFC2865"/> was because the
or UTF-8 data as per the definition of the 'text' data type in <xref section="3. attribute was encoded as an opaque and obfuscated binary blob. This
4" sectionFormat="comma" target="RFC8044"/>.</t> document does not change the data type of User-Password, even though
<t>However, implementations should be aware that passwords are often p the attribute is no longer obfuscated. The contents of the
rintable text, and where the passwords are printable text, it can be useful to s User-Password attribute do not have to be printable text or UTF-8
tore and display them as printable text. Where implementations can process non- data as per the definition of the "text" data type in <xref
printable data in the 'text' data type, they MAY use the data type 'text' for Us section="3.4" sectionFormat="comma" target="RFC8044"/>.</t>
er-Password.</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" data
type, they <bcp14>MAY</bcp14> use the data type "text" for
User-Password.</t>
</section> </section>
<section anchor="chap-challenge"> <section anchor="chap-challenge">
<name>CHAP-Challenge</name> <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 (<x <t><xref section="5.3" sectionFormat="comma" target="RFC2865"/>
ref section="5.40" sectionFormat="comma" target="RFC2865"/>), or the Request Aut allows for the CHAP challenge to be taken from either the
henticator field. Since RADIUS/1.1 connections no longer use a Request Authenti CHAP-Challenge attribute (<xref section="5.40" sectionFormat="comma"
cator field, it is no longer possible to use the Request Authenticator field as target="RFC2865"/>) or the Request Authenticator field. Since
the CHAP-Challenge when this transport profile is used.</t> RADIUS/1.1 connections no longer use a Request Authenticator field,
<t>Clients which send CHAP-Password attribute (<xref section="5.3" sec it is no longer possible to use the Request Authenticator field as
tionFormat="comma" target="RFC2865"/>) in an Access-Request packet over a RADIUS the CHAP-Challenge when this transport profile is used.</t>
/1.1 connection MUST also include a CHAP-Challenge attribute (<xref section="5.4
0" sectionFormat="comma" target="RFC2865"/>).</t> <t>Clients that send a CHAP-Password attribute (<xref section="5.3"
<t>Proxies may need to receive Access-Request packets over a non-RADIU sectionFormat="comma" target="RFC2865"/>) in an Access-Request
S/1.1 transport and then forward those packets over a RADIUS/1.1 connection. In packet over a RADIUS/1.1 connection <bcp14>MUST</bcp14> also include
that case, if the received Access-Request packet contains a CHAP-Password attri a CHAP-Challenge attribute (<xref section="5.40"
bute but no CHAP-Challenge attribute, the proxy MUST create a CHAP-Challenge att sectionFormat="comma" target="RFC2865"/>).</t>
ribute in the proxied packet using the contents from the incoming Request Authen
ticator of the received packet.</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 <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>
<section anchor="tunnel-password"> <section anchor="tunnel-password">
<name>Tunnel-Password</name> <name>Tunnel-Password</name>
<t>The Tunnel-Password attribute (<xref section="3.5" sectionFormat="c
omma" target="RFC2868"/>) MUST be encoded the same as any other attribute of dat <t>The Tunnel-Password attribute (<xref section="3.5"
a type 'string' which contains a tag, such as Tunnel-Client-Endpoint (<xref sect sectionFormat="comma" target="RFC2868"/>) <bcp14>MUST</bcp14> be
ion="3.3" sectionFormat="comma" target="RFC2868"/>). Since the attribute is no encoded the same as any other attribute of data type "string" that
longer obfuscated in RADIUS/1.1, there is no need for a Salt field or Data-Lengt contains a tag, such as Tunnel-Client-Endpoint (<xref section="3.3"
h fields as described in <xref section="3.5" sectionFormat="comma" target="RFC28 sectionFormat="comma" target="RFC2868"/>). Since the attribute is
68"/>, and the textual value of the password can simply be encoded as-is.</t> no longer obfuscated in RADIUS/1.1, there is no need for a Salt
<t>Note that the Tunnel-Password attribute is not of data type 'text'. field or Data-Length fields as described in <xref section="3.5"
The original reason in <xref target="RFC2868"/> was because the attribute was sectionFormat="comma" target="RFC2868"/>. The textual value of
encoded as an opaque and obfuscated binary blob. We maintain that data type her the password can simply be encoded as is.</t>
e, even though the attribute is no longer obfuscated. The contents of the Tunne
l-Password attribute do not have to be printable text, or UTF-8 data as per the <t>Note that the Tunnel-Password attribute is not of data type
definition of the 'text' data type in <xref section="3.4" sectionFormat="comma" "text". The original reason in <xref target="RFC2868"/> was because
target="RFC8044"/>.</t> the attribute was encoded as an opaque and obfuscated binary blob.
<t>However, implementations should be aware that passwords are often p We maintain that data type here, even though the attribute is no
rintable text, and where the passwords are printable text, it can be useful to s longer obfuscated. The contents of the Tunnel-Password attribute do
tore and display them as printable text. Where implementations can process non- not have to be printable text or UTF-8 data as per the definition
printable data in the 'text' data type, they MAY use the data type 'text' for Tu of the "text" data type in <xref section="3.4" sectionFormat="comma"
nnel-Password.</t> 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" data
type, they <bcp14>MAY</bcp14> use the data type "text" for
Tunnel-Password.</t>
</section> </section>
<section anchor="vendor-specific-attributes"> <section anchor="vendor-specific-attributes">
<name>Vendor-Specific Attributes</name> <name>Vendor-Specific Attributes</name>
<t>Any Vendor-Specific attribute which uses similar obfuscation MUST b
e encoded as per their base data type. Specifically, the MS-MPPE-Send-Key and M <!-- [rfced] As Section 3.4 of RFC 8044 refers to the "text" data,
S-MPPE-Recv-Key attributes (<xref section="2.4" sectionFormat="comma" target="RF should the section number be updated to 3.5?
C2548"/>) MUST be encoded as any other attribute of data type 'string' (<xref se
ction="3.4" sectionFormat="comma" target="RFC8044"/>).</t> 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 that uses similar obfuscation
<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"/>)
<bcp14>MUST</bcp14> be encoded as any other attribute of data type
"string" (<xref section="3.4" sectionFormat="comma"
target="RFC8044"/>).</t>
</section> </section>
</section> </section>
<section anchor="message-authenticator"> <section anchor="message-authenticator">
<name>Message-Authenticator</name> <name>Message-Authenticator</name>
<t>The Message-Authenticator attribute (<xref section="3.2" sectionForma
t="comma" target="RFC3579"/>) MUST NOT be sent over a RADIUS/1.1 connection. Th <t>The Message-Authenticator attribute (<xref section="3.2"
at attribute is not used or needed in RADIUS/1.1.</t> sectionFormat="comma" target="RFC3579"/>) <bcp14>MUST NOT</bcp14> be
<t>If the Message-Authenticator attribute is received over a RADIUS/1.1 sent over a RADIUS/1.1 connection. That attribute is not used or
connection, the attribute MUST be silently discarded, or treated as an "invalid needed in RADIUS/1.1.</t>
attribute", as defined in <xref section="2.8" sectionFormat="comma" target="RFC6
929"/>. That is, the Message-Authenticator attribute is no longer used to authe <t>If the Message-Authenticator attribute is received over a
nticate packets for the RADIUS/1.1 transport. Its existence (or not) in this tr RADIUS/1.1 connection, the attribute <bcp14>MUST</bcp14> be silently
ansport is meaningless.</t> discarded or treated as an "invalid attribute", as defined in <xref
<t>A system which receives a Message-Authenticator attribute in a packet section="2.8" sectionFormat="comma" target="RFC6929"/>. That is, the
MUST treat it as an "invalid attribute" as defined in <xref section="2.8" secti Message-Authenticator attribute is no longer used to authenticate
onFormat="comma" target="RFC6929"/>. That is, the packet can still be processed packets for the RADIUS/1.1 transport. Its existence (or not) in this
, even if the Message-Authenticator attribute is ignored.</t> transport is meaningless.</t>
<t>For proxies, the Message-Authenticator attribute has always been defi
ned as being created and consumed on a "hop by hop" basis. That is, a proxy whi <t>A system that receives a Message-Authenticator attribute in a
ch received a Message-Authenticator attribute from a client would never forward packet <bcp14>MUST</bcp14> treat it as an "invalid attribute" as
that attribute as-is to another server. Instead, the proxy would either suppres defined in <xref section="2.8" sectionFormat="comma"
s, or re-create, the Message-Authenticator attribute in the outgoing request. T target="RFC6929"/>. That is, the packet can still be processed, even
his existing behavior is leveraged in RADIUS/1.1 to suppress the use of Message- if the Message-Authenticator attribute is ignored.</t>
Authenticator over a RADIUS/1.1 connection.</t>
<t>A proxy may receive an Access-Request packet over a RADIUS/1.1 connec <t>For proxies, the Message-Authenticator attribute has always been
tion, and then forward that packet over a RADIUS/UDP or a RADIUS/TCP connection. defined as being created and consumed on a "hop-by-hop" basis. That
In that situation, the proxy SHOULD add a Message-Authenticator attribute to e is, a proxy that received a Message-Authenticator attribute from a
very Access-Request packet which is sent over an insecure transport protocol.</t client would never forward that attribute as is to another server.
> Instead, the proxy would either suppress or recreate the
<t>The original text in <xref section="3.3" sectionFormat="comma" target Message-Authenticator attribute in the outgoing request. This
="RFC3579"/>, "Note 1" paragraph required that the Message-Authenticator attribu existing behavior is leveraged in RADIUS/1.1 to suppress the use of the
te be present for certain Access-Request packets. It also required the use of M Message-Authenticator over a RADIUS/1.1 connection.</t>
essage-Authenticator when the Access-Request packet contained an EAP-Message att
ribute. Experience has shown that some RADIUS clients never use the Message-Aut <t>A proxy may receive an Access-Request packet over a RADIUS/1.1
henticator, even for the situations where its use is suggested.</t> connection and then forward that packet over a RADIUS/UDP or a
<t>When the Message-Authenticator attribute is missing from Access-Reque RADIUS/TCP connection. In that situation, the proxy
st packets, it is often possible to trivially forge or replay those packets. As <bcp14>SHOULD</bcp14> add a Message-Authenticator attribute to every
such, this document RECOMMENDS that RADIUS clients always include Message-Authe Access-Request packet that is sent over an insecure transport
nticator in Access-Request packets when using UDP or TCP transport. As the scop protocol.</t>
e of this document is limited to defining RADIUS/1.1, we cannot mandate that beh
avior here. Instead, we can note that there are no known negatives to this beha <t>The original text in <xref section="3.3"
vior, and there are definite positives, such as increased security.</t> sectionFormat="comma" target="RFC3579"/>, 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 packets, it is often possible to trivially forge or replay
those packets. As such, 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>
<section anchor="message-authentication-code"> <section anchor="message-authentication-code">
<name>Message-Authentication-Code</name> <name>Message-Authentication-Code</name>
<t>Similarly, the Message-Authentication-Code attribute defined in <xref <t>Similarly, the Message-Authentication-Code attribute defined in
section="3.3" sectionFormat="comma" target="RFC6218"/> MUST NOT be sent over a <xref section="3.3" sectionFormat="comma" target="RFC6218"/>
RADIUS/1.1 connection. If it is received in a packet, it MUST be treated as "in <bcp14>MUST NOT</bcp14> be sent over a RADIUS/1.1 connection. If it
valid attribute" as defined in <xref section="2.8" sectionFormat="comma" target= is received in a packet, it <bcp14>MUST</bcp14> be treated as an "invali
"RFC6929"/>.</t> d
<t>As the Message-Authentication-Code attribute is no longer used in RAD attribute" as defined in <xref section="2.8" sectionFormat="comma"
IUS/1.1, the related MAC-Randomizer attribute <xref section="3.2" sectionFormat= target="RFC6929"/>.</t>
"comma" target="RFC6218"/> MUST NOT be sent over a RADIUS/1.1 connection. If it <t>As the Message-Authentication-Code attribute is no longer used in
is received in a packet, it MUST be treated as "invalid attribute" as defined i RADIUS/1.1, the related MAC-Randomizer attribute (<xref section="3.2"
n <xref section="2.8" sectionFormat="comma" target="RFC6929"/>.</t> sectionFormat="comma" target="RFC6218"/>) <bcp14>MUST NOT</bcp14> be
sent over a RADIUS/1.1 connection. If it is received in a packet, it
<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="chap-ms-chap-etc">
<name>CHAP, MS-CHAP, etc.</name> <section anchor="chap-ms-chap-etc">
<t>While some attributes such as CHAP-Password, etc. depend on insecure <name>CHAP, MS-CHAP, and Similar Attributes</name>
cryptographic primitives such as MD5, these attributes are treated as opaque blo
bs when sent between a RADIUS client and server. The contents of the attributes <t>While some attributes such as CHAP-Password depend on
are not obfuscated, and they do not depend on the RADIUS shared secret. As a r insecure cryptographic primitives such as MD5, these attributes are
esult, these attributes are unchanged in RADIUS/1.1.</t> treated as opaque blobs when sent between a RADIUS client and server.
<t>Similarly, MS-CHAP depends on MD4, and RADIUS/1.1 does not change the The contents of the attributes are not obfuscated, and they do not
definition of any MS-CHAP attributes. However, MS-CHAP has been broken for dec depend on the RADIUS shared secret. As a result, these attributes are
ades, as noted in <xref target="ASLEAP"/>. The only appropriate use-case for MS unchanged in RADIUS/1.1.</t>
-CHAP is when it is protected by a secure transport such as RADIUS/TLS, RADIUS/D
TLS, or when it is used for "inner tunnel" authentication methods as with PEAP o <t>Similarly, MS-CHAP depends on MD4, and RADIUS/1.1 does not change
r TTLS.</t> the definition of any MS-CHAP attributes. However, MS-CHAP has been
<t>A server implementing this specification can proxy CHAP, MS-CHAP, etc broken for decades, as noted in <xref target="ASLEAP"/>. The only
. without any issue. A server implementing this specification can authenticate appropriate use case for MS-CHAP is when it is protected by a secure
CHAP, MS-CHAP, etc. without any issue. The RADIUS/1.1 protocol changes how RAD transport such as RADIUS/TLS or RADIUS/DTLS, or when it is used for
IUS packets are authenticated, and how "secret" data is obfuscated inside of a R "inner tunnel" authentication methods as with the Protected Extensible
ADIUS packet. It does not change any authentication method which is transported Authentication Protocol (PEAP) or TTLS.</t>
inside of RADIUS.</t>
<t>A server implementing this specification can proxy and
authenticate CHAP, MS-CHAP, etc. without any issue. The RADIUS/1.1
protocol changes how RADIUS packets are authenticated and how "secret"
data is obfuscated inside of a RADIUS packet. It does not change any
authentication method that is transported inside of RADIUS.</t>
</section> </section>
<section anchor="original-packet-code"> <section anchor="original-packet-code">
<name>Original-Packet-Code</name> <name>Original-Packet-Code</name>
<t><xref section="4" sectionFormat="comma" target="RFC7930"/> defines an <t><xref section="4" sectionFormat="comma" target="RFC7930"/> defines
Original-Packet-Code attribute. This attribute is needed because otherwise it an Original-Packet-Code attribute. This attribute is needed because
is impossible to correlate the Protocol-Error response packet with a particular otherwise it is impossible to correlate the Protocol-Error response
request packet. The definition in <xref section="4" sectionFormat="comma" targe packet with a particular request packet. The definition in <xref
t="RFC7930"/> describes the reasoning behind this need:</t> section="4" sectionFormat="comma" target="RFC7930"/> describes the
<ul empty="true"> reasoning behind this need:</t>
<li>
<t>The Original-Packet-Code contains the code <blockquote>The Original-Packet-Code contains the code from the
from the request that generated the protocol error so that clients request that generated the protocol error so that clients can
can disambiguate requests with different codes and the same ID.</t> disambiguate requests with different codes and the same ID.</blockquote>
</li>
</ul> <t>This attribute is no longer needed in RADIUS/1.1. The Identifier
<t>This attribute is no longer needed in RADIUS/1.1. The Identifier fie field is unused, so it impossible for two requests to have the "same"
ld is unused, so it impossible for two requests to have the "same" ID. Instead, ID. Instead, the Token field permits clients and servers to correlate
the Token field permits clients and servers to correlate requests and responses requests and responses, independent of the Code value being used.</t>
, independent of the Code value being used.</t>
<t>Therefore, the Original-Packet-Code attribute (<xref section="4" sect <t>Therefore, the Original-Packet-Code attribute (<xref section="4"
ionFormat="comma" target="RFC7930"/>) MUST NOT be sent over a RADIUS/1.1 connect sectionFormat="comma" target="RFC7930"/>) <bcp14>MUST NOT</bcp14> be
ion. If it is received in a packet, it MUST be treated as "invalid attribute" a sent over a RADIUS/1.1 connection. If it is received in a packet, it
s defined in <xref section="2.8" sectionFormat="comma" target="RFC6929"/>.</t> <bcp14>MUST</bcp14> be treated as an "invalid attribute" as defined in
<xref section="2.8" sectionFormat="comma" target="RFC6929"/>.</t>
</section> </section>
</section> </section>
<section anchor="other-considerations-when-using-alpn"> <section anchor="other-considerations-when-using-alpn">
<name>Other Considerations when using ALPN</name> <name>Other Considerations When Using ALPN</name>
<t>Most of the differences between RADIUS and RADIUS/1.1 are in the packet <t>Most of the differences between RADIUS and RADIUS/1.1 are in the
header and attribute handling, as discussed above. The remaining issues are a packet header and attribute handling, as discussed above. The remaining
small set of unrelated topics, and are discussed here.</t> issues are a small set of unrelated topics, and are discussed here.</t>
<section anchor="protocol-error"> <section anchor="protocol-error">
<name>Protocol-Error</name> <name>Protocol-Error</name>
<t>There are a number of situations where a RADIUS server is unable to r <t>There are a number of situations where a RADIUS server is unable to
espond to a request. One situation is where the server depends on a database, a respond to a request. One situation is where the server depends on a
nd the database is down. While arguably the server should close all incoming co database, and the database is down. While arguably the server should
nnections when it is unable to do anything, this action is not always effective. close all incoming connections when it is unable to do anything, this
A client may aggressively try to open new connections, or send packets to an u action is not always effective. A client may aggressively try to open
nconnected UDP destination where the server is not listening. Another situation new connections or send packets to an unconnected UDP destination
where the server is unable to respond is when the server is proxying packets, a where the server is not listening. Another situation where the server
nd the outbound connections are either full or failed.</t> is unable to respond is when the server is proxying packets, and the
<t>In all RADIUS spercifications prior to this one, there is no way for outbound connections are either full or failed.</t>
the server to send a client the positive signal that it received a request, but
is unable to send a response. Instead, the server usually just discards the req <t>In all RADIUS specifications prior to this one, there is no way
uest, which to the client is indistinguishable from the situation where the serv for the server to send a client the positive signal that it received a
er is down. This failure case is made worse by the fact that perhaps some proxi request but is unable to send a response. Instead, the server
ed packets succeed while others fail. The client can only conclude then that th usually just discards the request, which to the client is
e server is randomly dropping packets, and is unreliable.</t> indistinguishable from the situation where the server is down. This
<t>It would be very useful for servers to signal to clients that they ha failure case is made worse by the fact that perhaps some proxied
ve received a request, but are unable to process it. This specification uses th packets succeed while others fail. The client can only conclude then
e Protocol-Error packet <xref section="4" sectionFormat="comma" target="RFC7930" that the server is randomly dropping packets and is unreliable.</t>
/> as that signal. The use of Protocol-Error allows for both hop-by-hop signali
ng in the case of proxy forwarding errors, and also for end-to-end signaling of <t>It would be very useful for servers to signal to clients that they
server to client. Such signaling should greatly improve the robustness of the R have received a request but are unable to process it. This
ADIUS protocol.</t> specification uses the Protocol-Error packet (<xref section="4"
<t>When a RADIUS/1.1 server determines that it is unable to process an A sectionFormat="comma" target="RFC7930"/>) as that signal. The use of
ccess-Request or Accounting-Request packet, it MUST respond with a Protocol-Erro Protocol-Error allows for both hop-by-hop signaling in the case of
r packet containing an Error-Cause attribute. A proxy which cannot forward the proxy forwarding errors, and also for end-to-end signaling of server
packet MUST respond with either 502 (Request Not Routable (Proxy)), or 505 (Othe to client. Such signaling should greatly improve the robustness of
r Proxy Processing Error). This requirement is to help distinguish failures in the RADIUS protocol.</t>
the proxy chain from failures at the final (i.e. home) server,</t>
<t>For a home server, if none of the Error-Cause values match the reason <t>When a RADIUS/1.1 server determines that it is unable to process an
for the failure, then the value 506 (Resources Unavailable) MUST be used.</t> Access-Request or Accounting-Request packet, it <bcp14>MUST</bcp14>
<t>When a RADIUS proxy receives a Protocol-Error reply, it MUST examine respond with a Protocol-Error packet containing an Error-Cause
the value of the Error-Cause attribute. If there is no Error-Cause attribute, o attribute. A proxy that cannot forward the packet
r its value is something other than 502 (Request Not Routable (Proxy)), 505 (Oth <bcp14>MUST</bcp14> respond with either 502 (Request Not Routable
er Proxy Processing Error), or 506 (Resources Unavailable), the proxy MUST retur (Proxy)) or 505 (Other Proxy Processing Error). This requirement is
n the Protocol-Error response packet to the client, and include the Error-Cause to help distinguish failures in the proxy chain from failures at the
attribute from the response it received. This process allows for full "end to e final (i.e., home) server.</t>
nd" signaling of servers to clients.</t>
<t>In all situations other then outlined in the preceding paragraph, a c <t>For a home server, if none of the Error-Cause values match the
lient which receives a Protocol-Error reply MUST re-process the original outgoin reason for the failure, then the value 506 (Resources Unavailable)
g packet through the client forwarding algorithm. This requirement includes bot <bcp14>MUST</bcp14> be used.</t>
h clients which originate RADIUS traffic, and proxies which see an Error-Cause a
ttribute of 502 (Request Not Routable (Proxy)), or 505 (Other Proxy Processing E <t>When a RADIUS proxy receives a Protocol-Error reply, it
rror).</t> <bcp14>MUST</bcp14> examine the value of the Error-Cause attribute.
<t>The expected result of this processing is that the client forwards th If there is no Error-Cause attribute, or if its value is something other
e packet to a different server. Clients MUST NOT forward the packet over the sa than 502 (Request Not Routable (Proxy)), 505 (Other Proxy Processing
me connection, and SHOULD NOT forward it to over a different connection to the s Error), or 506 (Resources Unavailable), then the proxy <bcp14>MUST</bcp1
ame server.</t> 4>
<t>This process may continue over multiple connections and multiple serv return the Protocol-Error response packet to the client and include
ers, until the client either times out the request, or fails to find a forwardin the Error-Cause attribute from the response it received. This process
g destination for the packet. A proxy which is unable to forward a packet MUST allows for full "end-to-end" signaling of servers to clients.</t>
reply with a Protocol-Error packet containing Error-Cause, as defined above. A
client which originates packets MUST treat such a request as if it had received <t>In all situations other than those outlined in the preceding paragrap
no response.</t> h, a
<t>This behavior is intended to improve the stability of the RADIUS prot client that receives a Protocol-Error reply <bcp14>MUST</bcp14>
ocol by addressing issues first raised in <xref section="2.8" sectionFormat="com reprocess the original outgoing packet through the client forwarding
ma" target="RFC3539"/>.</t> algorithm. This requirement includes both clients that originate
RADIUS traffic and proxies that see an Error-Cause attribute of 502
(Request Not Routable (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 <bcp14>MUST NOT</bcp14>
forward the packet over the same connection and <bcp14>SHOULD
NOT</bcp14> forward it 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 or fails to
find a forwarding destination for the packet. A proxy that is unable
to forward a packet <bcp14>MUST</bcp14> reply with a Protocol-Error
packet containing an Error-Cause, as defined above. A client that
originates packets <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>
<section anchor="status-server"> <section anchor="status-server">
<name>Status-Server</name> <name>Status-Server</name>
<t><xref section="2.6.5" sectionFormat="comma" target="RFC6613"/>, and b
y extension <xref target="RFC7360"/>, suggest that the Identifier value zero (0) <t><xref section="2.6.5" sectionFormat="comma" target="RFC6613"/>, and
be reserved for use with Status-Server as an application-layer watchdog. This by extension <xref target="RFC7360"/>, suggest that the Identifier
practice MUST NOT be used for RADIUS/1.1, as the Identifier field is not used in value zero (0) be reserved for use with Status-Server as an
this transport profile.</t> application-layer watchdog. This practice <bcp14>MUST NOT</bcp14> be
<t>The rationale for reserving one value of the Identifier field was the used for RADIUS/1.1, as the Identifier field is not used in this
limited number of Identifiers available (256), and the overlap in Identifiers b transport profile.</t>
etween 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 Iden <t>The rationale for reserving one value of the Identifier field was
tifier value available for sending a Status-Server packet.</t> the limited number of Identifiers available (256) and the overlap in
<t>In contrast, the Token field allows for 2^32 outstanding packets on o Identifiers between Access-Request packets and Status-Server packets.
ne RADIUS/1.1 connection. If there is a need to send a Status-Server packet, it If all 256 Identifier values had been used to send Access-Request
is nearly always possible to allocate a new value for the Token field. If inst packets, then there would be no Identifier value available for sending
ead there are 2^32 outstanding packets for one connection, then it is likely tha a Status-Server packet.</t>
t something has gone catastrophically wrong. In that case, the safest way forwa
rd is likely to just close the connection.</t> <t>In contrast, the Token field allows for 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<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>
<section anchor="proxies"> <section anchor="proxies">
<name>Proxies</name> <name>Proxies</name>
<t>A RADIUS proxy normally decodes and then re-encodes all attributes, i
ncluded obfuscated ones. A RADIUS proxy will not generally rewrite the content <t>A RADIUS proxy normally decodes and then re-encodes all attributes,
of the attributes it proxies (unless site-local policy requires such a rewrite). including obfuscated ones. A RADIUS proxy will not generally rewrite
While some attributes may be modified due to administrative or policy rules on the content of the attributes it proxies (unless site-local policy
the proxy, the proxy will generally not rewrite the contents of attributes such requires such a rewrite). While some attributes may be modified due
as User-Password, Tunnel-Password, CHAP-Password, MS-CHAP-Password, MS-MPPE key to administrative or policy rules on the proxy, the proxy will
s, etc. All attributes are therefore transported through a RADIUS/1.1 connectio generally not rewrite the contents of attributes such as
n without changing their values or contents.</t> User-Password, Tunnel-Password, CHAP-Password, MS-CHAP-Password,
<t>A proxy may negotiate RADIUS/1.1 (or not) with a particular client or MS-MPPE keys, etc. Therefore, all attributes are transported through a
clients, and it may negotiate RADIUS/1.1 (or not) with a server or servers it c RADIUS/1.1 connection without changing their values or contents.</t>
onnect to, in any combination. As a result, this specification is fully compati
ble with all past, present, and future RADIUS attributes.</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 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> </section>
<section anchor="other-radius-considerations"> <section anchor="other-radius-considerations">
<name>Other RADIUS Considerations</name> <name>Other RADIUS Considerations</name>
<t>This section discusses issues in RADIUS which need to be addressed in o
rder to support ALPN, but which aren't direcly part of the RADIUS/1.1 protocol.< <t>This section discusses issues in RADIUS that need to be addressed in
/t> order to support ALPN, but which aren't directly part of the RADIUS/1.1
protocol.</t>
<section anchor="crypto-agility"> <section anchor="crypto-agility">
<name>Crypto-Agility</name> <name>Crypto-Agility</name>
<t>The crypto-agility requirements of <xref target="RFC6421"/> are addre
ssed in <xref section="C" sectionFormat="comma" target="RFC6614"/>, and in <xref <t>The crypto-agility requirements of <xref target="RFC6421"/> are
section="10.1" sectionFormat="comma" target="RFC7360"/>. This specification ma addressed in <xref section="C" sectionFormat="comma"
kes no changes from, or additions to, those specifications. The use of ALPN, an target="RFC6614"/> and in <xref section="10.1" sectionFormat="comma"
d the removal of MD5 has no impact on security or privacy of the protocol.</t> target="RFC7360"/>. This specification makes no changes or additions
<t>RADIUS/TLS has been widely deployed in at least eduroam <xref target= to those specifications. The use of ALPN and the removal of MD5 has
"RFC7593"/> and <xref target="EDUROAM"/> and in OpenRoaming <xref target="OPENRO no impact on the security or privacy of the protocol.</t>
AMING"/>. RADIUS/DTLS has seen less adoption, but it is known to be supported i
n many RADIUS clients and servers.</t> <t>RADIUS/TLS has been widely deployed in at least eduroam (<xref
<t>It is RECOMMENDED that all implementations of historic RADIUS/TLS be target="RFC7593"/> and <xref target="EDUROAM"/>) and in OpenRoaming
updated to support this specification. Where a system already implements RADIUS <xref target="OPENROAMING"/>. RADIUS/DTLS has seen less adoption, but
over TLS, the additional effort to implement this specification is minimal. On it is known to be supported in many RADIUS clients and servers.</t>
ce implementations support it, administrators can gain the benefit of it with li
ttle or no configuration changes. This specification is backwards compatible wi <t>It is <bcp14>RECOMMENDED</bcp14> that all implementations of
th <xref target="RFC6614"/> and <xref target="RFC7360"/>. It is only potentiall historic RADIUS/TLS be updated to support this specification. Where a
y subject to down-bidding attacks if implementations do not enforce ALPN negotia system already implements RADIUS over TLS, the additional effort to
tion correctly on session resumption.</t> implement this specification is minimal. Once implementations support
<t>All crypto-agility needed or used by this specification is implemente it, administrators can gain the benefit of it with little or no
d in TLS. This specification also removes all cryptographic primitives from the configuration changes. This specification is backwards compatible
application-layer protocol (RADIUS) being transported by TLS. As discussed in with <xref target="RFC6614"/> and <xref target="RFC7360"/>. It is
the following section, this specification also bans the development of all new c only potentially subject to down-bidding attacks if implementations do
ryptographic or crypto-agility methods in the RADIUS protocol.</t> not enforce ALPN 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>
<section anchor="error-cause-attribute"> <section anchor="error-cause-attribute">
<name>Error-Cause Attribute</name> <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 <t>The Error-Cause attribute is defined in <xref
" target="RFC5176"/> permits that attribute to appear in CoA-NAK and Disconnect- target="RFC5176"/>. The "Table of Attributes" section given in <xref
NAK packets. As no other packet type is listed, the implication is that the Err section="3.6" sectionFormat="comma" target="RFC5176"/> permits that
or-Cause attribute cannot appear in any other packet. <xref target="RFC7930"/> attribute to appear in CoA-NAK and Disconnect-NAK packets. As no
also permits Error-Cause to appear in Protocol-Error packets.</t> other packet type is listed, the implication is that the Error-Cause
<t>However, <xref section="2.6.1" sectionFormat="comma" target="RFC5080" attribute cannot appear in any other packet. <xref target="RFC7930"/>
/> suggests that Error-Cause may appear in Access-Reject packets. No explanatio also permits Error-Cause to appear in Protocol-Error packets.</t>
n 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. <t>However, <xref section="2.6.1" sectionFormat="comma"
We correct that issue here.</t> target="RFC5080"/> suggests that Error-Cause may appear in
<t>This specification updates <xref target="RFC5176"/> to allow the Erro Access-Reject packets. No explanation is given for this change from
r-Cause attribute to appear in Access-Reject packets. It is RECOMMENDED that im <xref target="RFC5176"/>. There is not even an acknowledgment that
plementations include the Error-Cause attribute in Access-Reject packets where a this suggestion is a change from any previous specification. We
ppropriate.</t> correct that issue here.</t>
<t>That is, the reason for sending the Access-Reject packet (or Protocol
-Error packet) may match a defined Error-Cause value. In that case, it is usefu <t>This specification updates <xref target="RFC5176"/> to allow the
l for implementations to send an Error-Cause attribute with that value. This be Error-Cause attribute to appear in Access-Reject packets. It is
havior can help RADIUS system administrators debug issues in complex proxy chain <bcp14>RECOMMENDED</bcp14> that implementations include the
s.</t> Error-Cause attribute in Access-Reject packets where appropriate.</t>
<t>For example, a proxy may normally forward Access-Request packets whic
h contain EAP-Message attributes. The proxy can determine if the contents of th <t>That is, the reason for sending the Access-Reject packet (or the
e EAP-Message are invalid. On example of an invalid EAP-Message is where the fi Protocol-Error packet) may match a defined Error-Cause value. In that
rst octet has value larger than 4. In that case, there may be no benefit to for case, it is useful for implementations to send an Error-Cause
warding the packet, as the home server will reject it. It may then then possibl attribute with that value. This behavior can help RADIUS system
e for the proxy (with the knowledge and consent of involved parties) to immediat administrators debug issues in complex proxy chains.</t>
ely reply with an Access-Reject containing an Error-Cause attribute with value 2
02 for "Invalid EAP Packet (Ignored)".</t> <t>For example, a proxy may normally forward Access-Request packets
<t>Another possibility is that if a proxy is configured to forward packe that contain EAP-Message attributes. The proxy can determine if the
ts for a particular realm, but it has determined that there are no available con contents of the EAP-Message are invalid. One example of an invalid
nections to the next hop for that realm. In that case, it may be possible for t EAP-Message is where the first octet has value larger than 4. In that
he proxy (again with the knowledge and consent of involved parties) to reply wit case, there may be no benefit to forwarding the packet, as the home
h an Access-Reject containing an Error-Cause attribute with value 502 for "Reque server will reject it. It may then be possible for the proxy (with
st Not Routable (Proxy)"</t> the knowledge and consent of involved parties) to immediately reply
<t>These examples are given only for illustrative and informational purp with an Access-Reject containing an Error-Cause attribute with value
oses. While it is useful to return an informative value for the Error-Cause att 202 (Invalid EAP Packet (Ignored)).</t>
ribute, proxies can only modify the traffic they forward with the explicit knowl
edge and consent of all involved parties.</t> <t>Another possibility is that 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, with the knowledge and
consent of involved parties) to reply with an Access-Reject containing
an Error-Cause attribute with value 502 (Request Not Routable
(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>
<section anchor="future-standards"> <section anchor="future-standards">
<name>Future Standards</name> <name>Future Standards</name>
<t>Future work may define new attributes, packet types, etc. It is impo
rtant to be able to do such work without requiring that every new standard menti <t>Future work may define new attributes, packet types, etc. It is
on RADIUS/1.1 explicitly. This document defines RADIUS/1.1 as having functional important to be able to do such work without requiring that every new
overlap with legacy RADIUS: the protocol state machine is unchanged, the packet standard mention RADIUS/1.1 explicitly. This document defines
header Code field is unchanged, and the attribute format is largely unchanged. RADIUS/1.1 as having functional overlap with legacy RADIUS: the
As a result, any new packet Code or attribute defined for RADIUS is explicitly protocol state machine is unchanged, the packet header Code field is
compatible with RADIUS/1.1: the field contents and meanings are identical. The unchanged, and the attribute format is largely unchanged. As a
only difference between the two protocols is that obfuscated attributes in RADIU result, any new packet Code or attribute defined for RADIUS is
S are not obfuscated in RADIUS/1.1, and this document defines how that mapping i explicitly compatible with RADIUS/1.1; the field contents and meanings
s done.</t> are identical. The only difference between the two protocols is that
<t>Any future specification needs to mention RADIUS/1.1 only if it adds obfuscated attributes in RADIUS are not obfuscated in RADIUS/1.1, and
fields to the RADIUS/1.1 packet header. Otherwise, transport considerations for this document defines how that mapping is done.</t>
RADIUS/1.1 are identical to RADIUS over (D)TLS.</t>
<t>We reiterate that this specification defines a new transport profile <t>Any future specification only needs to mention RADIUS/1.1 if it
for RADIUS. It does not define a completely new protocol. Any future specifica adds fields to the RADIUS/1.1 packet header. Otherwise, transport
tion which defines a new attribute MUST define it for RADIUS/UDP first, after wh considerations for RADIUS/1.1 are identical to RADIUS over (D)TLS.</t>
ich those definitions can be applied to this transport profile.</t>
<t>New specifications MAY define new attributes which use the obfuscatio <t>We reiterate that this specification defines a new transport
n methods for User-Password as defined in <xref section="5.2" sectionFormat="com profile for RADIUS. It does not define a completely new protocol.
ma" target="RFC2865"/>, or for Tunnel-Password as defined in <xref section="3.5" Any future specification that defines a new attribute
sectionFormat="comma" target="RFC2868"/>. There is no need for those specifica <bcp14>MUST</bcp14> define it for RADIUS/UDP first, and afterwards those
tions to describe how those new attributes are transported in RADIUS/1.1. Since definitions can be applied to this transport profile.</t>
RADIUS/1.1 does not use MD5, any obfuscated attributes will by definition be tr
ansported as their underlying data type, "text" (<xref section="3.4" sectionForm <t>New specifications <bcp14>MAY</bcp14> define new attributes that
at="comma" target="RFC8044"/>) or "string" (<xref section="3.5" sectionFormat="c use the obfuscation methods for User-Password as defined in <xref
omma" target="RFC8044"/>).</t> section="5.2" sectionFormat="comma" target="RFC2865"/> or for
<t>New RADIUS specifications MUST NOT define attributes which can only b Tunnel-Password as defined in <xref section="3.5"
e transported via RADIUS over TLS. The RADIUS protocol has no way to signal the sectionFormat="comma" target="RFC2868"/>. There is no need for those
security requirements of individual attributes. Any existing implementation wi specifications to describe how those new attributes are transported in
ll handle these new attributes as "invalid attributes" (<xref section="2.8" sect RADIUS/1.1. Since RADIUS/1.1 does not use MD5, any obfuscated
ionFormat="comma" target="RFC6929"/>), and could forward them over an insecure l attributes will by definition be transported as their underlying data
ink. As RADIUS security and signaling is hop-by-hop, there is no way for a RADI type "text" (<xref section="3.4" sectionFormat="comma"
US client or server to even know if such forwarding is taking place. For these target="RFC8044"/>) or "string" (<xref section="3.5"
reasons and more, it is therefore inappropriate to define new attributes which a sectionFormat="comma" target="RFC8044"/>).</t>
re only secure if they use a secure transport layer.</t>
<t>The result is that specifications do not need to mention this transpo <t>New RADIUS specifications <bcp14>MUST NOT</bcp14> define attributes
rt profile, or make any special provisions for dealing with it. This specificat that can only be transported via RADIUS over TLS. The RADIUS
ion defines how RADIUS packet encoding, decoding, authentication, and verificati protocol has no way to signal the security requirements of individual
on are performed when using RADIUS/1.1. So long as any future specification use attributes. Any existing implementation will handle these new
s the existing encoding, etc. schemes defined for RADIUS, no additional text in attributes as "invalid attributes" (<xref section="2.8"
future documents is necessary in order to be compatible with RADIUS/1.1.</t> sectionFormat="comma" target="RFC6929"/>) and could forward them over
<t>We note that it is theoretically possible for future standards to def an insecure link. As RADIUS security and signaling is hop-by-hop,
ine new cryptographic primitives for use with RADIUS/UDP. In that case, those d there is no way for a RADIUS client or server to even know if such
ocuments would likely have to describe how to transport that data in RADIUS/1.1. forwarding is taking place. For these reasons and more, it is
We believe that such standards are unlikely to be published, as other efforts therefore inappropriate to define new attributes that are only secure
in the RADEXT working group are forbidding such updates to RADIUS.</t> if they use a secure transport layer.</t>
<t>The result is that specifications do not need to mention this
transport 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 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 are
forbidding such updates to RADIUS.</t>
</section> </section>
</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 Free
RADIUS project which is hosted on GitHub at https://github.com/FreeRADIUS/freera
dius-server/tree/v3.2.x The code implementation "diff" is approximately 1,000 l
ines, including build system changes and changes to configuration parsers.</t>
</section>
<section anchor="privacy-considerations"> <section anchor="privacy-considerations">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>This specification requires secure transport for RADIUS. RADIUS/1.1. h <t>This specification requires secure transport for RADIUS.
as all of the privacy benefits of RADIUS/TLS <xref target="RFC6614"/> and RADIUS RADIUS/1.1 has all of the privacy benefits of RADIUS/TLS <xref
/DTLS <xref target="RFC7360"/>, and none of the privacy or security issues of RA target="RFC6614"/> and RADIUS/DTLS <xref target="RFC7360"/> and none of
DIUS/UDP <xref target="RFC2865"/> or RADIUS/TCP <xref target="RFC6613"/>.</t> the privacy or security issues of RADIUS/UDP <xref target="RFC2865"/> or
RADIUS/TCP <xref target="RFC6613"/>.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The primary focus of this document is addressing security consideration
s for RADIUS. This specification relies on TLS and associated ALPN negotiation <t>The primary focus of this document is addressing security
for much of its security. We refer the reader to <xref target="RFC8446"/> and < considerations for RADIUS. This specification relies on TLS and
xref target="RFC7360"/> for discussions of the security of those protocols. The associated ALPN for much of its security. We refer the
discussion in this section is limited to issues unique to this specification.</ reader to <xref target="RFC8446"/> and <xref target="RFC7360"/> for
t> discussions of the security of those protocols. The discussion in this
<t>Implementations should rely on the underlying TLS library to perform AL section is limited to issues unique to this specification.</t>
PN version negotiation. That is, implementations should supply a list of permit
ted ALPN strings to the TLS library, and let it return the negotiated value.</t> <t>Implementations should rely on the underlying TLS library to perform
<t>There are few other opportunities for security issues. If an implement ALPN version negotiation. That is, implementations should supply a list
ation gets ALPN negotiation wrong, then the wrong application data will be trans of permitted ALPN strings to the TLS library, and let it return the
ported inside of TLS. While RADIUS/1.0 and RADIUS/1.1 share similar packet form negotiated value.</t>
ats, the protocols are not mutually compatible.</t>
<t>When an implementation receives the packets for a RADIUS version which <t>There are few other opportunities for security issues. If an
is not supported by this connection, it will not be able to process the packets. implementation gets ALPN wrong, then the wrong application
Implementations can produce log messages indicating that the application-layer data will be transported inside of TLS. While RADIUS/1.0 and RADIUS/1.1
data is unexpected, and close the connection. In addition, the implementations share similar packet formats, the protocols are not mutually
which see the incorrect application data already have full access to all secrets compatible.</t>
, passwords, etc. being transported, so any protocol differences do not result a
ny security issue. Since all of the application data is protected by TLS, there <t>When an implementation receives the packets for a RADIUS version
is no possibility for an attacker to obtain any extra data as a result of this that is not supported by this connection, it will not be able to
misconfiguration.</t> process the packets. Implementations can produce log messages
<t>RADIUS/1.0 requests sent over a RADIUS/1.1 connection may be accepted b indicating that the application-layer data is unexpected and close the
y the RADIUS/1.1 server, as the server will ignore the ID field, and try to use connection. In addition, the implementations that see the incorrect
portions of the Request Authenticator as a Token. However, the reply from the R application data already have full access to all secrets, passwords,
ADIUS/1.1 server will fail the Response Authenticator validation by the RADIUS/1 etc. being transported, so any protocol differences do not result in any
.0 client. The responses will therefore be dropped. The client will generally security issues. Since all of the application data is protected by TLS,
log these failures, and an administrator will address the issue.</t> there is no possibility for an attacker to obtain any extra data as a
<t>RADIUS/1.1 requests sent over a RADIUS/1.0 connection will generally be result of this misconfiguration.</t>
discarded the the RADIUS/1.0 server, as the packets will fail the Request Authe
nticator checks. That is, all request packets such as Accounting-Request, CoA-R <t>RADIUS/1.0 requests sent over a RADIUS/1.1 connection may be accepted
equest, and Disconnect-Request will be discarded by the server. For Access-Requ by the RADIUS/1.1 server, as the server will ignore the ID field and
est packets containing EAP-Message, the packets will be missing Message-Authenti try to use portions of the Request Authenticator as a Token. However,
cator, and will therefore be discarded by the server. Other Access-Request pack the reply from the RADIUS/1.1 server will fail the Response
ets contain obfuscated attributes such as User-Password will have those attribut Authenticator validation by the RADIUS/1.0 client. Therefore, the respons
es decoded to nonsense, and will thus result in Access-Reject responses.</t> es will
<t>RADIUS/1.1 Access-Request packets containing non-obfuscated attributes be dropped. The client will generally log these failures, and
such as CHAP-Password may be accepted by a RADIUS/1.0 server but the response wi an administrator will address the issue.</t>
ll contain a Response Authenticator (i.e. MD5 hash), and not a Token which match
es the Token in the request. A similar analysis applies for Access-Request pack <t>RADIUS/1.1 requests sent over a RADIUS/1.0 connection will generally
ets containing Service-Type = Authorize-Only.</t> be discarded by the RADIUS/1.0 server, as the packets will fail the
<t>In conclusion, any mismatch of versions between client and server will Request Authenticator checks. That is, all request packets such as
result in most request packets being discarded by the server, and all response p Accounting-Request, CoA-Request, and Disconnect-Request will be
ackets being discarded by the client. The two protocols are therefore incompati discarded by the server. For Access-Request packets containing
ble, and safe from misconfigurations or erroneous implementations.</t> EAP-Message, the packets will be missing 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, thus 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,
but the response will contain a Response Authenticator (i.e., MD5 hash)
and not a Token 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 and
all response packets being discarded by the client. Therefore, the two pr
otocols
are incompatible and safe from misconfigurations or erroneous
implementations.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to update the "TLS Application-Layer Protocol Negotia
tion (ALPN) Protocol IDs" registry with two new entries:</t>
<artwork><![CDATA[
Protocol: RADIUS/1.0
Id. Sequence: 0x72 0x61 0x64 0x69 0x75 0x73 0x2f 0x31 0x2e 0x30
("radius/1.0")
Reference: This document
Protocol: RADIUS/1.1 <t>IANA has updated the "TLS Application-Layer Protocol
Id. Sequence: 0x72 0x61 0x64 0x69 0x75 0x73 0x2f 0x31 0x2e 0x31 Negotiation (ALPN) Protocol IDs" registry with two new entries:</t>
("radius/1.1")
Reference: This document <dl newline="false" spacing="compact">
]]></artwork> <dt>Protocol:</dt><dd>RADIUS/1.0</dd>
</section> <dt>Identification Sequence:</dt><dd>0x72 0x61 0x64 0x69 0x75 0x73 0x2f 0
<section anchor="acknowledgments"> x31 0x2e 0x30 ("radius/1.0")</dd>
<name>Acknowledgments</name> <dt>Reference:</dt><dd>RFC 9765</dd>
<t>Thanks to Bernard Aboba, Karri Huhtanen, Heikki Vatiainen, Alexander Cl </dl>
outer, Michael Richardson, Hannes Tschofenig, Matthew Newton, and Josh Howlett f
or reviews and feedback.</t> <dl newline="false" spacing="compact">
</section> <dt>Protocol:</dt><dd>RADIUS/1.1</dd>
<section anchor="changelog"> <dt>Identification Sequence:</dt><dd>0x72 0x61 0x64 0x69 0x75 0x73 0x2f 0
<name>Changelog</name> x31 0x2e 0x31 ("radius/1.1")</dd>
<t>(This section to be removed by the RFC editor.)</t> <dt>Reference:</dt><dd>RFC 9765</dd>
<t>draft-dekok-radext-sradius-00</t> </dl>
<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 n
ame "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 us
e-cases.</t>
<t>Use "radius/1.0" instead of "radius/1"</t>
<t>Consistently refer to the specification as "RADIUSv11", and consist
ently 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 motivate
s 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-Pass
word.</t>
<t>Give high level summary of ALPN, clear up client / server roles, an
d 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 th
e transport profile.</t>
<t>Clarify that future specifications do not need to make provisions f
or 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), a
nd 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 se
nt 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>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC8174"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 174.xml"/>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
tle> 865.xml"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<date month="May" year="2017"/> 421.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<t>RFC 2119 specifies common key words that may be used in protoco 929.xml"/>
l specifications. This document aims to reduce the ambiguity by clarifying that <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
only UPPERCASE usage of the key words have the defined special meanings.</t> 614.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
</front> 301.xml"/>
<seriesInfo name="BCP" value="14"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<seriesInfo name="RFC" value="8174"/> 360.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</reference> 044.xml"/>
<reference anchor="RFC2865"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 119.xml"/>
<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 wh
ich desires to authenticate its links and a shared Authentication Server. [STAND
ARDS-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="Ne
lson"/>
<date month="November" year="2011"/>
<abstract>
<t>This memo describes the requirements for a crypto-agility solut
ion for Remote Authentication Dial-In User Service (RADIUS). This document is no
t an Internet Standards Track specification; it is published for informational p
urposes.</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) protoco
l 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 Tr
ansport Layer Security (TLS) over TCP as the transport protocol. This enables dy
namic 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 Neg
otiation 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) extens
ion for application-layer protocol negotiation within the TLS handshake. For ins
tances in which multiple application protocols are supported on the same TCP or
UDP port, this extension allows the application layer to negotiate which protoco
l 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 i
n the clear, although some parts of the packets can have obfuscated content. Pac
kets may be replayed verbatim by an attacker, and client-server authentication i
s based on fixed shared secrets. This document specifies how the Datagram Transp
ort Layer Security (DTLS) protocol may be used as a fix for these problems. It a
lso describes how implementations of this proposal can coexist with current RADI
US 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 with
out defining them as managed entities. During this time, RADIUS implementations
have named the data types and have used them in attribute definitions. This docu
ment updates the specifications to better follow established practice. We do thi
s by naming the data types defined in RFC 6158, which have been used since at le
ast 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 fo
r each attribute. Finally, we recommend that authors of RADIUS specifications us
e these types in preference to existing practice. This document updates RFCs 286
5, 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</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC1321"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<front> 321.xml"/>
<title>The MD5 Message-Digest Algorithm</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<author fullname="R. Rivest" initials="R." surname="Rivest"/> 548.xml"/>
<date month="April" year="1992"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<abstract> 866.xml"/>
<t>This document describes the MD5 message-digest algorithm. The a <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
lgorithm takes as input a message of arbitrary length and produces as output a 1 868.xml"/>
28-bit "fingerprint" or "message digest" of the input. This memo provides inform <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
ation for the Internet community. It does not specify an Internet standard.</t> 539.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
</front> 579.xml"/>
<seriesInfo name="RFC" value="1321"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<seriesInfo name="DOI" value="10.17487/RFC1321"/> 176.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<reference anchor="RFC2548"> 151.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<title>Microsoft Vendor-specific RADIUS Attributes</title> 218.xml"/>
<author fullname="G. Zorn" initials="G." surname="Zorn"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<date month="March" year="1999"/> 613.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<t>This document describes the set of Microsoft vendor-specific RA 585.xml"/>
DIUS attributes. This memo provides information for the Internet community.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
</abstract> 593.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<seriesInfo name="RFC" value="2548"/> 930.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC2548"/>
</reference> <reference anchor="FIPS-140-3" target="https://nvlpubs.nist.gov/nistpubs/
<reference anchor="RFC2866"> FIPS/NIST.FIPS.140-3.pdf">
<front> <front>
<title>RADIUS Accounting</title> <title>Security Requirements for Cryptographic Modules</title>
<author fullname="C. Rigney" initials="C." surname="Rigney"/> <author>
<date month="June" year="2000"/> <organization abbrev="NIST">National Institute of Standards and Technolog
<abstract> y</organization>
<t>This document describes a protocol for carrying accounting info </author>
rmation between a Network Access Server and a shared Accounting Server. This mem <date month="March" year="2019"/>
o provides information for the Internet community.</t> </front>
</abstract> <seriesInfo name="NIST FIPS" value="140-3"/>
</front> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.140-3"/>
<seriesInfo name="RFC" value="2866"/> </reference>
<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 Di
al In User Service) attributes designed to support the provision of compulsory t
unneling in dial-up networks. This memo provides information for the Internet co
mmunity.</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 prot
ocols for Authentication, Authorization and Accounting (AAA). It also provides r
ecommendations 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 F
or 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 Servic
e (RADIUS) support for the Extensible Authentication Protocol (EAP), an authenti
cation framework which supports multiple authentication mechanisms. In the propo
sed scheme, the Network Access Server (NAS) forwards EAP packets to and from the
RADIUS server, encapsulated within EAP-Message attributes. This has the advanta
ge of allowing the NAS to support any EAP authentication method, without the nee
d for method- specific code, which resides on the RADIUS server. While EAP was o
riginally 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">
<front>
<title>Dynamic Authorization Extensions to Remote Authentication Dia
l 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 R
emote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic ch
anges 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 an
d 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 m
essage digest algorithm. It also updates the security considerations for HMAC-MD
5. This document is not an Internet Standards Track specification; it is publish
ed 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 for the Delivery of K
eying 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 Attribute
s designed to allow both the secure transmission of cryptographic keying materia
l and strong authentication of any RADIUS message. These attributes have been al
located from the Cisco vendor-specific space and have been implemented by multip
le vendors. This document is not an Internet Standards Track specification; it i
s 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 tra
nsport layer. This document defines RADIUS over the Transmission Control Protoco
l (RADIUS/TCP), in order to address handling issues related to RADIUS over Trans
port Layer Security (RADIUS/TLS). It permits TCP to be used as a transport proto
col for RADIUS only when a transport layer such as TLS or IPsec provides confide
ntiality and security. This document defines an Experimental Protocol for the In
ternet 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 o
n the Network Access Identifier (NAI)</title>
<author fullname="S. Winter" initials="S." surname="Winter"/>
<author fullname="M. McCauley" initials="M." surname="McCauley"/>
<date month="October" year="2015"/>
<abstract>
<t>This document specifies a means to find authoritative RADIUS se
rvers for a given realm. It is used in conjunction with either RADIUS over Trans
port Layer Security (RADIUS/TLS) or RADIUS over Datagram Transport Layer Securit
y (RADIUS/DTLS).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7585"/>
<seriesInfo name="DOI" value="10.17487/RFC7585"/>
</reference>
<reference anchor="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 80
2.1X, the Extensible Authentication Protocol (EAP), and RADIUS that is used in e
duroam provides a secure, scalable, and deployable service for roaming network a
ccess. The successful deployment of eduroam over the last decade in the educatio
nal sector may serve as an example for other sectors, hence this document. In pa
rticular, the initial architectural choices and selection of standards are descr
ibed, 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"/>
<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 pac
ket proves problematic. This specification extends the RADIUS-over-TCP experimen
t (RFC 6613) to permit larger RADIUS packets. This specification compliments oth
er ongoing work to permit fragmentation of RADIUS authorization information. Thi
s document registers a new RADIUS code, an action that required IESG approval.</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="7930"/>
<seriesInfo name="DOI" value="10.17487/RFC7930"/>
</reference>
<reference anchor="EDUROAM" target="https://eduroam.org"> <reference anchor="EDUROAM" target="https://eduroam.org">
<front> <front>
<title>eduroam</title> <title>eduroam</title>
<author initials="" surname="eduroam" fullname="eduroam"> <author initials="" surname="eduroam" fullname="eduroam">
<organization/> <organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="OPENROAMING" target="https://wballiance.com/openroami ng/"> <reference anchor="OPENROAMING" target="https://wballiance.com/openroami ng/">
<front> <front>
<title>OpenRoaming: One global Wi-Fi network</title> <title>OpenRoaming: One global Wi-Fi network</title>
<author initials="W. B." surname="Alliance" fullname="Wireless Broad <author>
band Alliance"> <organization>Wireless Broadband Alliance</organization>
<organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="ASLEAP" target="https://github.com/joswr1ght/asleap"> <reference anchor="ASLEAP" target="https://github.com/joswr1ght/asleap">
<front> <front>
<title>asleap - recovers weak LEAP and PPTP passwords</title> <title>asleap - recovers weak LEAP and PPTP passwords</title>
<author initials="J." surname="Wright" fullname="Joshua Wright"> <author/>
<organization/> <date month="November" year="2020"/>
</author>
<date>n.d.</date>
</front>
</reference>
<reference anchor="RFC5077">
<front>
<title>Transport Layer Security (TLS) Session Resumption without Ser
ver-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"/
>
<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 sess
ion state. The TLS server encapsulates the session state into a ticket and forwa
rds it to the client. The client can subsequently resume a session using the obt
ained 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, l
ike a dictionary, which is available to an attacker. The underlying key exchange
is resistant to active attack, passive attack, and dictionary attack. This docu
ment is not an Internet Standards Track specification; it is published for infor
mational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5931"/>
<seriesInfo name="DOI" value="10.17487/RFC5931"/>
</reference>
<reference anchor="RFC5281">
<front>
<title>Extensible Authentication Protocol Tunneled Transport Layer S
ecurity Authenticated Protocol Version 0 (EAP-TTLSv0)</title>
<author fullname="P. Funk" initials="P." surname="Funk"/>
<author fullname="S. Blake-Wilson" initials="S." surname="Blake-Wils
on"/>
<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 hand
shake phase and a data phase. During the handshake phase, the server is authenti
cated to the client (or client and server are mutually authenticated) using stan
dard TLS procedures, and keying material is generated in order to create a crypt
ographically secure tunnel for information exchange in the subsequent data phase
. During the data phase, the client is authenticated to the server (or client an
d server are mutually authenticated) using an arbitrary authentication mechanism
encapsulated within the secure tunnel. The encapsulated authentication mechanis
m may itself be EAP, or it may be another authentication protocol such as PAP, C
HAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authent
ication protocols to be used against existing authentication databases, while pr
otecting the security of these legacy protocols against eavesdropping, man-in-th
e-middle, and other attacks. The data phase may also be used for additional, arb
itrary data exchange. This memo provides information 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) Im
plementation 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 Authentica
tion Dial In User Service (RADIUS) implementations and suggests some fixes. Wher
e applicable, ambiguities and errors in previous RADIUS specifications are clari
fied. [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</titl
e>
<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 Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="8446"/> <refcontent>commit 254acab</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
077.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
931.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
281.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
080.xml"/>
</references> </references>
</references> </references>
</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==
<section anchor="acknowledgments" numbered="false">
<name>Acknowledgments</name>
<t>Thanks to <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
reviews and feedback.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 107 change blocks. 
2448 lines changed or deleted 1748 lines changed or added

This html diff was produced by rfcdiff 1.48.