rfc9813.original.xml   rfc9813.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.21 (Ruby 2.6. -ietf-radext-tls-psk-12" number="9813" category="bcp" consensus="true" submissio
10) --> nType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3" xml:la
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ng="en" updates="" obsoletes="">
-ietf-radext-tls-psk-12" category="bcp" consensus="true" submissionType="IETF" t
ocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.24.0 -->
<front> <front>
<title abbrev="RADIUS and TLS-PSK">Operational Considerations for RADIUS and <title abbrev="RADIUS and TLS-PSK">Operational Considerations for Using TLS
TLS-PSK</title> Pre-Shared Keys (TLS-PSKs) with RADIUS</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-radext-tls-psk-12"/> <seriesInfo name="RFC" value="9813"/>
<seriesInfo name="BCP" value="243"/>
<author initials="A." surname="DeKok" fullname="Alan DeKok"> <author initials="A." surname="DeKok" fullname="Alan DeKok">
<organization>InkBridge Networks</organization> <organization>InkBridge Networks</organization>
<address> <address>
<email>alan.dekok@inkbridge.io</email> <email>alan.dekok@inkbridge.io</email>
</address> </address>
</author> </author>
<date year="2025" month="January" day="21"/> <date year="2025" month="July"/>
<area>Internet</area> <area>SEC</area>
<workgroup>RADEXT Working Group</workgroup> <workgroup>radext</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 49?>
<t>This document provides implementation and operational considerations for usin <keyword>example</keyword>
g TLS-PSK with RADIUS/TLS (RFC6614) and RADIUS/DTLS (RFC7360). The purpose of t
he document is to help smooth the operational transition from the use of the RAD <abstract>
IUS/UDP to RADIUS/TLS.</t> <t>This document provides implementation and operational considerations
for using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS/TLS (RFC 6614) and RA
DIUS/DTLS (RFC 7360).
The purpose of the document is to help smooth the operational transition
from the use of RADIUS/UDP to RADIUS/TLS.</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-tls-psk/"/>.
</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/radext-tls-psk.git"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 53?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The previous specifications "Transport Layer Security (TLS) Encryption
for RADIUS" <xref target="RFC6614"/> and "Datagram Transport Layer Security (DT <t>The previous specifications "Transport Layer Security (TLS)
LS) as a Transport Layer for RADIUS" <xref target="RFC7360"/> defined how (D)TLS Encryption for RADIUS" <xref target="RFC6614"/> and "Datagram Transport
can be used as a transport protocol for RADIUS. However, those documents do no Layer Security (DTLS) as a Transport Layer for RADIUS" <xref
t provide guidance for using TLS-PSK with RADIUS. This document provides that m target="RFC7360"/> defined how (D)TLS can be used as a transport
issing guidance, and gives implementation and operational considerations.</t> protocol for RADIUS. However, those documents do not provide guidance
<t>To clearly distinguish the various secrets and keys, this document uses for using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS. This document provi
"shared secret" to mean "RADIUS shared secret", and Pre-Shared Key (PSK) to mea des that missing
n secret keys which are used with TLS-PSK.</t> guidance, and gives implementation and operational considerations.</t>
<t>The purpose of the document is to help smooth the operational transitio
n from the use of the insecure RADIUS/UDP to the use of the much more secure RAD <t>To clearly distinguish the various secrets and keys, this document
IUS/TLS. While using PSKs is often less preferable to using public / private ke uses "shared secret" to mean "RADIUS shared secret", and "Pre-Shared Key
ys, the operational model of PSKs follows the legacy RADIUS "shared secret" mode (PSK)" to mean "secret keys that are used with TLS-PSK".</t>
l. As such, it can be easier for implementers and operators to transition to TL <t>The purpose of the document is to help smooth the operational
S when that transition is offered as a series of small changes.</t> transition from the use of the insecure RADIUS/UDP to the use of the
<t>The intent for TLS-PSK is to be used in networks where the addresses of much more secure RADIUS/TLS. While using PSKs is often less preferable
client and server are known, as with RADIUS/UDP. This situation is similar to to using public or private keys, the operational model of PSKs follows
the use-case of RADIUS/UDP with shared secrets. TLS-PSK is not suitable for sit the legacy RADIUS "shared secret" model. As such, it can be easier for
uations where clients dynamically discover servers, as there is no way for the c implementers and operators to transition to TLS when that transition is
lient to dynamically determine which PSK should be used with a new server (or vi offered as a series of small changes.</t>
ce versa). In contrast, <xref target="RFC7585"/> dynamic discovery allows for <t>TLS-PSK is intended to be used in networks where the
a client or server to authenticate previously unknown server or client, as the p addresses of clients and servers are known, as with RADIUS/UDP. This
arties can be issued a certificate by a known Certification Authority (CA).</t> situation is similar to the use case of RADIUS/UDP with shared secrets.
<t>TLS-PSKs have the same issue of symmetric information between client an TLS-PSK is not suitable for situations where clients dynamically
d server: both parties know the secret key. A client could, in theory, pretend discover servers, as there is no way for the client to dynamically
to be a server. In contrast, certificates are asymmetric, where it is impossibl determine which PSK should be used with a new server (or vice versa).
e for the parties to assume the others identity. Further discussion of this top In contrast, dynamic discovery <xref target="RFC7585"/> allows for
ic is contained in []{#sharing}.</t> a client or server to authenticate a previously unknown server or client,
as the parties can be issued a certificate by a known Certification
Authority (CA).</t>
<t>TLS-PSKs have the same issue of symmetric information between client
and server: both parties know the secret key. A client could, in
theory, pretend to be a server. In contrast, certificates are
asymmetric, where it is impossible for the parties to assume the other's
identity. Further discussion of this topic is contained in <xref target="
sharing"/>.</t>
<t>Unless it is explicitly called out that a recommendation applies to <t>Unless it is explicitly called out that a recommendation applies to
TLS alone or to DTLS alone, each recommendation applies to both TLS TLS or DTLS alone, each recommendation applies to both TLS and
and DTLS.</t> DTLS.</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
<ul spacing="normal"> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<li> target="RFC8174"/> when, and only when, they appear in all capitals, as
<t>External PSK</t> shown here.
</li> </t>
</ul> <dl spacing="normal" newline="true">
<ul empty="true"> <dt>External PSK</dt><dd>A PSK (along with a related PSK Identity)
<li> that is administratively configured. That is, one that is
<t>A PSK (along with a related PSK Identity) which is administratively external to TLS and is not created by the TLS subsystem.</dd>
configured. That is, one which is external to TLS, and is not created by the T <dt>Resumption PSK</dt><dd>A PSK (along with a related PSK Identity)
LS subsystem.</t> that is created by the TLS subsystem and/or application, for use
</li> with resumption.</dd>
</ul> </dl>
<ul spacing="normal">
<li>
<t>Resumption PSK</t>
</li>
</ul>
<ul empty="true">
<li>
<t>A PSK (along with a related PSK Identity) which is created by the T
LS subsystem and/or application, for use with resumption.</t>
</li>
</ul>
</section> </section>
<section anchor="justification-of-psk"> <section anchor="justification-of-psk">
<name>Justification of PSK.</name> <name>Justification of PSK</name>
<t>TLS deployments usually rely on certificates in most common uses. Howev <t>TLS deployments usually rely on certificates in most common
er, we recognize that it may be difficult to fully upgrade client implementation uses. However, we recognize that it may be difficult to fully upgrade
s to allow for certificates to be used with RADIUS/TLS and RADIUS/DTLS. These u client implementations to allow for certificates to be used with
pgrades involve not only implementing TLS, but can also require significant chan RADIUS/TLS and RADIUS/DTLS. These upgrades involve not only
ges to administration interfaces and application programming interfaces (APIs) i implementing TLS, but can also require significant changes to
n order to fully support certificates.</t> administration interfaces and application programming interfaces (APIs)
<t>For example, unlike shared secrets, certificates expire. This expirati in order to fully support certificates.</t>
on means that a working system using TLS can suddenly stop working. Managing th <t>For example, unlike shared secrets, certificates expire. This
is expiration can require additional notification APIs on RADIUS clients and ser expiration means that a working system using TLS can suddenly stop
vers which were previously not required when shared secrets were used.</t> working. Managing this expiration can require additional notification
<t>Certificates also require the use of certification authorities (CAs), a APIs on RADIUS clients and servers that were previously not required
nd chains of certificates. RADIUS implementations using TLS therefore have to t when shared secrets were used.</t>
rack not just a small shared secret, but also potentially many large certificate <t>Certificates also require the use of certification authorities (CAs)
s. The use of TLS-PSK can therefore provide a simpler upgrade path for implemen and chains of certificates. RADIUS implementations using TLS therefore
tations to transition from RADIUS shared secrets to TLS.</t> have to track not just a small shared secret, but also potentially many
<t>In terms of ongoing maintenance, it is generally simpler to maintain se large certificates. The use of TLS-PSK can therefore provide a simpler
rvers than clients. For one, there are many fewer servers than clients. Server upgrade path for implementations to transition from RADIUS shared
s are also typically less resource constrained, and often run on general-purpose secrets to TLS.</t>
operating systems, where maintenance can be automated using widely-available to <t>In terms of ongoing maintenance, it is generally simpler to maintain
ols.</t> servers than clients. For one, there are many fewer servers than
<t>In contrast, clients are often numerous, resource constrained, and are clients. Servers are also typically less resource constrained, and
more likely to be closed or proprietary systems with limited interfaces. As a r often run on general-purpose operating systems, where maintenance can be
esult, it can be difficult to update these clients when a root CA expires. The automated using widely available tools.</t>
use of TLS-PSK in such an environment may therefore offer management efficiencie <t>In contrast, clients are often numerous, resource constrained, and
s.</t> likely to be closed or proprietary systems with limited interfaces. As
a result, it can be difficult to update these clients when a root CA
expires. The use of TLS-PSK in such an environment may therefore offer
management efficiencies.</t>
</section> </section>
<section anchor="general-discussion-of-psks-and-psk-identities"> <section anchor="general-discussion-of-psks-and-psk-identities">
<name>General Discussion of PSKs and PSK Identities</name> <name>General Discussion of PSKs and PSK Identities</name>
<t>Before we define any RADIUS-specific use of PSKs, we must first review <t>Before we define any RADIUS-specific use of PSKs, we must first
the current standards for PSKs, and give general advice on PSKs and PSK Identiti review the current standards for PSKs, and give general advice on PSKs
es.</t> and PSK Identities.</t>
<t>The requirements in this section apply to both client and server implem <t>The requirements in this section apply to both client and server
entations which use TLS-PSK. Client-specific and server-specific issues are dis implementations that use TLS-PSK. Client-specific and server-specific
cussed in more detail later in this document.</t> issues are discussed in more detail later in this document.</t>
<section anchor="guidance-for-psks"> <section anchor="guidance-for-psks">
<name>Guidance for PSKs</name> <name>Guidance for PSKs</name>
<t>We first give requirements for creating and managing PSKs, followed b <t>We first give requirements for creating and managing PSKs, followed
y usability guidance, and then a discussion of RADIUS shared secrets and their i by usability guidance, and then a discussion of RADIUS shared secrets
nteraction with PSKs.</t> and their interaction with PSKs.</t>
<section anchor="psk-requirements"> <section anchor="psk-requirements">
<name>PSK Requirements</name> <name>PSK Requirements</name>
<t>Reuse of a PSK in multiple versions of TLS (e.g., TLS 1.2 and TLS 1 <t>Reuse of a PSK in multiple versions of TLS (e.g., TLS 1.2 and TLS
.3) is considered unsafe (<xref section="E.7" sectionFormat="comma" target="RFC8 1.3) is considered unsafe (see <xref section="E.7" sectionFormat="comm
446"/>). Where TLS 1.3 binds the PSK to a particular key derivation function, T a"
LS 1.2 does not. This binding means that it is possible to use the same PSK in target="RFC8446"/>). Where TLS 1.3 binds the PSK to a particular
different hashes, leading to the potential for attacking the PSK by comparing th key derivation function (KDF), TLS 1.2 does not. This binding means t
e hash outputs. While there are no known insecurities, these uses are not known hat
to be secure, and should therefore be avoided. For this reason, an implementat it is possible to use the same PSK in different hashes, leading to
ion MUST NOT use the same PSK for TLS 1.3 and for earlier versions of TLS. The e the potential for attacking the PSK by comparing the hash outputs.
xact manner in which this requirement is enforced is implementation-specific. On While there are no known insecurities, these uses are not known to
e possibility is to have two different PSKs. Another possibility is to forbid th be secure, and should therefore be avoided. For this reason, an
e use of TLS versions less than TLS 1.3</t> implementation <bcp14>MUST NOT</bcp14> use the same PSK for TLS 1.3
<t><xref target="RFC9258"/> adds a key derivation function (KDF) to th and for earlier versions of TLS. The exact manner in which this
e import interface of (D)TLS 1.3, which binds the externally provided PSK to the requirement is enforced is implementation-specific. One possibility
protocol version. That process is preferred to any TOFU mechanism. In particu is to have two different PSKs. Another possibility is to forbid the
lar, that document:</t> use of TLS versions less than TLS 1.3</t>
<ul empty="true"> <t><xref target="RFC9258"/> adds a KDF to the import interface of
<li> (D)TLS 1.3, which binds the externally provided PSK to the protocol
<t>... describes a mechanism for importing PSKs derived from exter version. That process is preferred to any trust-on-first-use (TOFU) m
nal PSKs by including the target KDF, (D)TLS protocol version, and an optional c echanism. In
ontext string to ensure uniqueness. This process yields a set of candidate PSKs, particular, that document:</t>
each of which are bound to a target KDF and protocol, that are separate from th
ose used in (D)TLS 1.2 and prior versions. This expands what would normally have <blockquote>
been a single PSK and identity into a set of PSKs and identities.</t> <t>... describes a mechanism for importing PSKs derived from
</li> external PSKs by including the target KDF, (D)TLS protocol
</ul> version, and an optional context string to ensure
<t>An implementation MUST NOT use the same PSK for TLS 1.3 and for ear uniqueness. This process yields a set of candidate PSKs, each of
lier versions of TLS. This requirement prevents reuse of a PSK with multiple TL which are bound to a target KDF and protocol, that are separate
S versions, which prevents the attacks discussed in <xref section="E.7" sectionF from those used in (D)TLS 1.2 and prior versions. This expands
ormat="comma" target="RFC8446"/>. The exact manner in which this requirement is what would normally have been a single PSK and identity into a
enforced is implementation-specific. One possibility is to have two different set of PSKs and identities.</t>
PSKs. Another possibility is to forbid the use of TLS versions less than TLS 1. </blockquote>
3.</t>
<t>Implementations MUST follow the directions of <xref section="6" sec <t>An implementation <bcp14>MUST NOT</bcp14> use the same PSK for
tionFormat="comma" target="RFC9257"/> for the use of external PSKs in TLS. That TLS 1.3 and for earlier versions of TLS. This requirement prevents
document provides extremely useful guidance on generating and using PSKs.</t> reuse of a PSK with multiple TLS versions, which prevents the
<t>Implementations MUST support PSKs of at least 32 octets in length, attacks discussed in <xref section="E.7" sectionFormat="comma"
and SHOULD support PSKs of 64 octets or more. As the PSKs are generally hashed target="RFC8446"/>. The exact manner in which this requirement is
before being used in TLS, the useful entropy of a PSK is limited by the size of enforced is implementation-specific. One possibility is to have two
the hash output. This output may be 256, 384, or 512 bits in length. Neverthel different PSKs. Another possibility is to forbid the use of TLS
ess, it is good practice for implementations to allow entry of PSKs of more than versions less than TLS 1.3.</t>
64 octets, as the PSK may be in a form other than bare binary data. Implementa <t>Implementations <bcp14>MUST</bcp14> follow the directions of
tions which limit the PSK to a maximum of 64 octets are likely to use PSKs which <xref section="6" sectionFormat="comma" target="RFC9257"/> for the
have much less than 512 bits of entropy. That is, a PSK with high entropy may use of external PSKs in TLS. That document provides extremely
be expanded via some construct (e.g., base32 as in the example below) in order t useful guidance on generating and using PSKs.</t>
o make it easier for people to interact with. Where 512 bits of entropy are inp <t>Implementations <bcp14>MUST</bcp14> support PSKs of at least 32
ut to an encoding construct, the output may be larger than 64 octets.</t> octets in length, and <bcp14>SHOULD</bcp14> support PSKs of 64
<t>Implementations MUST require that PSKs be at least 16 octets in len octets or more. As the PSKs are generally hashed before being used
gth. That is, short PSKs MUST NOT be permitted to be used, and PSKs MUST be ran in TLS, the useful entropy of a PSK is limited by the size of the
dom. The strength of the PSK is not determined by the length of the PSK, but i hash output. This output may be 256, 384, or 512 bits in length.
nstead by the number of bits of entropy which it contains. People are not good Nevertheless, it is good practice for implementations to allow entry
at creating data with high entropy, so a source of cryptographically secure rand of PSKs of more than 64 octets, as the PSK may be in a form other
om numbers MUST be used.</t> than bare binary data. Implementations that limit the PSK to a
<t>Where user passwords are generally intended to be remembered and en maximum of 64 octets are likely to use PSKs that have much less
tered by people on a regular basis, PSKs are intended to be entered once, and t than 512 bits of entropy. That is, a PSK with high entropy may be
hen automatically saved in a system configuration. As such, due to the limited expanded via some construct (e.g., base32 as seen in <xref target="usa
entropy of passwords, they are not acceptable for use with TLS-PSK, and would on bility-guidance"/>)
ly be acceptable for use with a password-authenticated key exchange (PAKE) TLS m in order to make it easier for people to interact with. Where 512
ethod <xref target="RFC8492"/>. Implementations MUST therefore support entry an bits of entropy are input to an encoding construct, the output may
d storage of PSKs as undistinguished octets.</t> be larger than 64 octets.</t>
<t>We also incorporate by reference the requirements of <xref section= <t>Implementations <bcp14>MUST</bcp14> require that PSKs be at least
"10.2" sectionFormat="comma" target="RFC7360"/> when using PSKs.</t> 16 octets in length. That is, short PSKs <bcp14>MUST NOT</bcp14> be
<t>It may be tempting for servers to implement a "trust on first use" permitted to be used, and PSKs <bcp14>MUST</bcp14> be random. The
(TOFU) policy with respect to clients. Such behavior is NOT RECOMMENDED. When strength of the PSK is not determined by the length of the PSK, but
servers receive a connection from an unknown client, they SHOULD log the PSK Ide instead by the number of bits of entropy that it contains. People
ntity, source IP address, and any other information which may be relevant. An a are not good at creating data with high entropy, so a source of
dministrator can then later look at the logs and determine the appropriate actio cryptographically secure random numbers <bcp14>MUST</bcp14> be
n to take.</t> used.</t>
<t>Where user passwords are generally intended to be remembered and
entered by people on a regular basis, PSKs are intended to be
entered once, and then automatically saved in a system
configuration. As such, due to the limited entropy of passwords,
they are not acceptable for use with TLS-PSK, and would only be
acceptable for use with a password-authenticated key exchange (PAKE)
TLS method <xref target="RFC8492"/>. Implementations
<bcp14>MUST</bcp14> therefore support entry and storage of PSKs as
undistinguished octets.</t>
<t>We also incorporate by reference the requirements of <xref
section="10.2" sectionFormat="comma" target="RFC7360"/> when using
PSKs.</t>
<t>It may be tempting for servers to implement a TOFU policy with
respect to clients. Such behavior is <bcp14>NOT RECOMMENDED</bcp14>.
When servers receive a connection from an
unknown client, they <bcp14>SHOULD</bcp14> log the PSK Identity,
source IP address, and any other information that may be relevant.
An administrator can then later look at the logs and determine the
appropriate action to take.</t>
</section> </section>
<section anchor="usability-guidance"> <section anchor="usability-guidance">
<name>Usability Guidance</name> <name>Usability Guidance</name>
<t>PSKs are in their purest form are opaque tokens, represented as an <t>PSKs in their purest form are opaque tokens, represented as
undistinguished series of octets. Where PSKs are expected to be managed automat an undistinguished series of octets. Where PSKs are expected to be
ically by scripted methods, this format is acceptable. However, in some cases i managed automatically by scripted methods, this format is
t is necessary for administrators to share PSKs, in which case humanly readable acceptable. However, in some cases it is necessary for
formats may be useful. Implementations SHOULD support entering PSKs as both bin administrators to share PSKs, in which case human-readable formats
ary data, and via a humanly readable form such as hex encoding.</t> may be useful. Implementations <bcp14>SHOULD</bcp14> support
<t>Implementations SHOULD use a humanly readable form of PKSs for inte entering PSKs as both binary data and via a human-readable form
rfaces which are intended to be used by people, and SHOULD allow for binary data such as hex encoding.</t>
to be entered via an application programming interface (API). Implementations <t>Implementations <bcp14>SHOULD</bcp14> use a human-readable form
SHOULD also allow for PSKs to be displayed in the above-mentioned hex encoding, of PSKs for interfaces that are intended to be used by people, and
so that administrators can manually verify that a particular PSK is being used.< <bcp14>SHOULD</bcp14> allow for binary data to be entered via an
/t> application programming interface (API). Implementations
<t>When using PSKs, administrators SHOULD use PSKs of at least 24 octe <bcp14>SHOULD</bcp14> also allow for PSKs to be displayed in the hex
ts, generated using a source of cryptographically secure random numbers. Implem encoding mentioned above, so that administrators can manually verify
enters needing a secure random number generator should see <xref target="RFC8937 that a particular PSK is being used.</t>
"/> for for further guidance. PSKs are not passwords, and administrators should <t>When using PSKs, administrators <bcp14>SHOULD</bcp14> use PSKs of
not try to manually create PSKs.</t> at least 24 octets that are generated using a source of cryptographica
<t>In order to guide implementers and administrators, we give example lly
commands below which generate random PSKs from a locally secure source. While s secure random numbers. Implementers needing a secure random number
ome commands may not work on some systems one of the commands should succeed. T generator should see <xref target="RFC8937"/> for further
he intent here is to document a concise and simple example of creating PSKs whic guidance. PSKs are not passwords, and administrators should not try
h are both secure, and humanly manageable. This document does not mandate that to manually create PSKs.</t>
the PSKs follow this format, or any other format.</t> <t>In order to guide implementers and administrators, we give
<artwork><![CDATA[ example commands below that generate random PSKs from a locally
secure source. While some commands may not work on some systems, one
of the commands should succeed. The intent here is to document a
concise and simple example of creating PSKs that are both secure
and human-manageable. This document does not mandate that the
PSKs follow this format or any other format.</t>
<sourcecode type="shell"><![CDATA[
openssl rand -base64 16 openssl rand -base64 16
dd if=/dev/urandom bs=1 count=16 | base64 dd if=/dev/urandom bs=1 count=16 | base64
dd if=/dev/urandom bs=1 count=16 | base32 dd if=/dev/urandom bs=1 count=16 | base32
dd if=/dev/urandom bs=1 count=16 | (hexdump -ve '/1 "%02x"' && echo) dd if=/dev/urandom bs=1 count=16 | (hexdump -ve '/1 "%02x"' && echo)
]]></artwork> ]]></sourcecode>
<t>Only one of the above commands should be run, there is no need to r
un all of them. Each command reads 128 bits (16 octets) of random data from a s <t>Only one of the above commands should be run; there is no need to
ecure source, and encodes it as printable / readable ASCII. This form of PSK wi run all of them. Each command reads 128 bits (16 octets) of random
ll be accepted by any implementation which supports at least 32 octets for PSKs. data from a secure source, and encodes it as printable and readable
Larger PSKs can be generated by changing the "16" number to a larger value. T ASCII. This form of PSK will be accepted by any implementation
he above derivation assumes that the random source returns one bit of entropy fo that supports at least 32 octets for PSKs. Larger PSKs can be
r every bit of randomness which is returned. Sources failing that assumption ar generated by changing the "16" number to a larger value. The above
e NOT RECOMMENDED.</t> derivation assumes that the random source returns one bit of entropy
for every bit of randomness that is returned. Sources failing that
assumption are <bcp14>NOT RECOMMENDED</bcp14>.</t>
</section> </section>
<section anchor="interaction-between-psks-and-radius-shared-secrets"> <section anchor="interaction-between-psks-and-radius-shared-secrets">
<name>Interaction between PSKs and RADIUS Shared Secrets</name> <name>Interaction Between PSKs and RADIUS Shared Secrets</name>
<t>Any shared secret used for RADIUS/UDP or RADIUS/TLS MUST NOT be use
d for TLS-PSK.</t> <t>Any shared secret used for RADIUS/UDP or RADIUS/TLS <bcp14>MUST
<t>It is RECOMMENDED that RADIUS clients and servers track all used sh NOT</bcp14> be used for TLS-PSK.</t>
ared secrets and PSKs, and then verify that the following requirements all hold <t>It is <bcp14>RECOMMENDED</bcp14> that RADIUS clients and servers
true:</t> track all used shared secrets and PSKs, and then verify that the
following requirements all hold true:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>no shared secret is used for more than one RADIUS client</t> <t>no shared secret is used for more than one RADIUS client</t>
</li> </li>
<li> <li>
<t>no PSK is used for more than one RADIUS client</t> <t>no PSK is used for more than one RADIUS client</t>
</li> </li>
<li> <li>
<t>no shared secret is used as a PSK</t> <t>no shared secret is used as a PSK</t>
</li> </li>
</ul> </ul>
<t>Note that the shared secret of "radsec" given in <xref target="RFC6 <t>Note that the shared secret of "radsec" given in <xref
614"/> can be used across multiple clients, as that value is mandated by the spe target="RFC6614"/> can be used across multiple clients, as that
cification. The intention here is to recommend best practices for administrator value is mandated by the specification. The intention here is to
s who enter site-local shared secrets.</t> recommend best practices for administrators who enter site-local
<t>There may be use-cases for using one shared secret across multiple shared secrets.</t>
RADIUS clients. There may similarly be use-cases for sharing a PSK across multi <t>There may be use cases for using one shared secret across
ple RADIUS clients. Details of the possible attacks on reused PSKs are given i multiple RADIUS clients. There may similarly be use cases for
n <xref section="4.1" sectionFormat="comma" target="RFC9257"/>.</t> sharing a PSK across multiple RADIUS clients. Details of the
<t>There are no known use-cases for using a PSK as a shared secret, or possible attacks on reused PSKs are given in <xref section="4.1"
vice-versa.</t> sectionFormat="comma" target="RFC9257"/>.</t>
<t>Implementations MUST reject configuration attempts that try to use <t>There are no known use cases for using a PSK as a shared secret,
the or vice versa.</t>
same value for PSK and shared secret. To prevent administrative errors, impleme <t>Implementations <bcp14>MUST</bcp14> reject configuration attempts
ntations should not have interfaces which confuse PSKs and shared secrets, or wh that try to use the same value for the PSK and shared secret. To
ich allow both PSKs and shared secrets to be entered at the same time. There is prevent administrative errors, implementations should not have
too much of a temptation for administrators to enter the same value in both fie interfaces that confuse PSKs and shared secrets or that allow
lds, which would violate the limitations given above. Similarly, using a "share both PSKs and shared secrets to be entered at the same time. There
d secret" field as a way for administrators to enter PSKs is bad practice. The is too much of a temptation for administrators to enter the same
PSK entry fields need to be labeled as being related to PSKs, and not to shared value in both fields, which would violate the limitations given
secrets.</t> above. Similarly, using a "shared secret" field as a way for
administrators to enter PSKs is bad practice. The PSK entry fields
need to be labeled as being related to PSKs, and not to shared
secrets.</t>
</section> </section>
</section> </section>
<section anchor="psk-identities"> <section anchor="psk-identities">
<name>PSK Identities</name> <name>PSK Identities</name>
<t><xref section="5.1" sectionFormat="comma" target="RFC4279"/> requires <t><xref section="5.1" sectionFormat="comma" target="RFC4279"/>
that PSK Identities be encoded in UTF-8 format. However, <xref section="4.2.11 requires that PSK Identities be encoded in UTF-8 format. However,
" sectionFormat="comma" target="RFC8446"/> describes the "Pre-Shared Key Extensi <xref section="4.2.11" sectionFormat="comma" target="RFC8446"/>
on" and defines the ticket as an opaque string: "opaque identity&lt;1..2^16-1&gt describes the "Pre-Shared Key Extension" and defines the ticket as an
;;". This PSK is then used in <xref section="4.6.1" sectionFormat="comma" targe opaque string: "opaque identity&lt;1..2<sup>16</sup>-1&gt;;". This PSK
t="RFC8446"/> for resumption.</t> is then
<t>These definitions appear to be in conflict. This conflict is address used in <xref section="4.6.1" sectionFormat="comma" target="RFC8446"/>
ed in <xref section="6.1.1" sectionFormat="comma" target="RFC9257"/>, which disc for resumption.</t>
usses requirements for encoding and comparison of PSK Identities. Systems MUST <t>These definitions appear to be in conflict. This conflict is
follow the directions of <xref section="6.1.1" sectionFormat="comma" target="RFC addressed in <xref section="6.1.1" sectionFormat="comma"
9257"/> when using or comparing PSK Identities for RADIUS/TLS. Implementations target="RFC9257"/>, which discusses requirements for encoding and
MUST follow the recommendations of <xref target="RFC8265"/> for handling PSK Ide comparison of PSK Identities. Systems <bcp14>MUST</bcp14> follow the
ntity strings.</t> directions of <xref section="6.1.1" sectionFormat="comma"
<t>In general, implementers should allow for external PSK Identities to target="RFC9257"/> when using or comparing PSK Identities for
follow <xref target="RFC4279"/> and be UTF-8, while PSK Identities provisioned a RADIUS/TLS. Implementations <bcp14>MUST</bcp14> follow the
s part of resumption are automatically provisioned, and therefore follow <xref t recommendations of <xref target="RFC8265"/> for handling PSK Identity
arget="RFC8446"/>.</t> strings.</t>
<t>Note that the PSK Identity is sent in the clear, and is therefore vis <t>In general, implementers should allow for external PSK Identities
ible to attackers. Where privacy is desired, the PSK Identity could be either a to follow <xref target="RFC4279"/> and be UTF-8, while PSK Identities
n opaque token generated cryptographically, or perhaps in the form of a Network provisioned as part of resumption are automatically provisioned, and
Access Identifier (NAI) <xref target="RFC7542"/>, where the "user" portion is an therefore follow <xref target="RFC8446"/>.</t>
opaque token. For example, an NAI could be "68092112@example.com". If the att <t>Note that the PSK Identity is sent in the clear, and is therefore
acker already knows that the client is associated with "example.com", then using visible to attackers. Where privacy is desired, the PSK Identity
that domain name in the PSK Identity offers no additional information. In cont could be either an opaque token generated cryptographically, or
rast, the "user" portion needs to be both unique to the client and private, so u perhaps in the form of a Network Access Identifier (NAI) <xref
sing an opaque token there is a more secure approach.</t> target="RFC7542"/>, where the "user" portion is an opaque token. For
<t>Implementations MUST support PSK Identities of 128 octets, and SHOULD example, an NAI could be "68092112@example.com". If the attacker
support longer PSK Identities. We note that while TLS provides for PSK Identit already knows that the client is associated with "example.com", then
ies of up to 2^16-1 octets in length, there are few practical uses for extremely using that domain name in the PSK Identity offers no additional
long PSK Identities.</t> information. In contrast, the "user" portion needs to be both unique
<t>It is up to administrators and implementations as to how they differe to the client and private, so using an opaque token is a more
ntiate external PSK Identities from session resumption PSK Identities used in TL secure approach.</t>
S 1.3 session tickets. While <xref section="6.1.2" sectionFormat="comma" target <t>Implementations <bcp14>MUST</bcp14> support PSK Identities of 128
="RFC9257"/> suggests the identities should be unique, it offers no concrete ste octets, and <bcp14>SHOULD</bcp14> support longer PSK Identities. We
ps for how this differentiation may be done.</t> note that while TLS provides for PSK Identities of up to 2<sup>16</sup>-
<t>One approach could be to have externally provisioned PSK Identities c 1 octets
ontain an NAI such as described above, while session resumption PSK Identities c in length, there are few practical uses for extremely long PSK
ontain large blobs of opaque, encrypted, and authenticated text. It should then Identities.</t>
be relatively straightforward to differentiate the two types of identities. On <t>It is up to administrators and implementations as to how they
e is UTF-8, the other is not. One is unauthenticated, the other is authenticate differentiate external PSK Identities from session resumption PSK
d.</t> Identities used in TLS 1.3 session tickets. While <xref
<t>Servers MUST assign and/or track session resumption PSK Identities in section="6.1.2" sectionFormat="comma" target="RFC9257"/> suggests the
a identities should be unique, it offers no concrete steps for how this
way which facilities the ability to distinguish those identities from differentiation may be done.</t>
externally configured PSK Identities, and which enables them to both find and va <t>One approach could be to have externally provisioned PSK Identities
lidate contain an NAI such as what is described above, while session resumption
the session resumption PSK. See {}(#resumption) below for more discussion of is PSK
sues around resumption.</t> Identities contain large blobs of opaque, encrypted, and authenticated
<t>A sample validation flow for TLS-PSK Identities could be performed vi text. It should then be relatively straightforward to differentiate
a the following steps:</t> the two types of identities. One is UTF-8, the other is not. One is
<ul empty="true"> unauthenticated, the other is authenticated.</t>
<t>Servers <bcp14>MUST</bcp14> assign and/or track session resumption
PSK Identities in a way that facilities the ability to distinguish
those identities from externally configured PSK Identities, and that
enables them to both find and validate the session resumption PSK.
See <xref target="resumption"/> below for more discussion of issues arou
nd
resumption.</t>
<t>A sample validation flow for TLS-PSK Identities could be performed
via the following steps:</t>
<ol spacing="normal" type="1">
<li>PSK Identities provided via an administration interface are
enforced to be only UTF-8 on both client and server.</li>
<li>The client treats session tickets received from the server as
opaque blobs.</li>
<li>When the server issues session tickets for resumption, the
server ensures that they are not valid UTF-8.</li>
<li>One way to do this is to use stateless resumption with a forced
non-UTF-8 key_name per <xref section="4.6.1" sectionFormat="comma"
target="RFC8446"/>, such as by setting one octet to 0x00.</li>
<li> <li>
<ol spacing="normal" type="1"><li> <t>When receiving TLS, the server receives a Client-Hello containing
<t>PSK Identities provided via an administration interface are e a PSK, and checks if the identity is valid UTF-8:</t>
nforced to be only UTF-8 on both client and server.</t>
</li> <ol type="%p%d.">
<li>
<t>The client treats session tickets received from the server as
opaque blobs.</t>
</li>
<li> <li>
<t>When the server issues session tickets for resumption, the se <t>If yes, it searches for a preconfigured client that matches th
rver ensures that they are not valid UTF-8.</t> at identity.</t>
</li> <ol type="5.1.%d.">
<li>If the identity is found, it authenticates the client via
PSK.</li>
<li>Else, the identity is invalid, and the server closes the c
onnection.</li>
</ol>
</li>
<li> <li>
<t>One way to do this is to use stateless resumption with a forc <t>If not, try resumption, which is usually handled by a TLS libr
ed non-UTF-8 key_name per <xref section="4" sectionFormat="comma" target="RFC507 ary.</t>
7"/>, such as by setting one octet to 0x00.</t> <ol type="5.2.%d.">
</li> <li>If the TLS library verifies the session ticket, then resum
ption has happened, and the connection is established.</li>
<li>Else, the server ignores the session ticket, and performs
a normal TLS handshake with a certificate.</li>
</ol>
</li>
</ol> </ol>
<t>5 When receiving TLS, the server receives Client-Hello containing </li>
a PSK, and checks if the identity is valid UTF-8.</t> </ol>
<ul empty="true">
<li>
<t>5.1. If yes, it searches for a pre-configured client which ma
tches that identity.</t>
<ul empty="true">
<li>
<t>5.1.1. If the identity is found, authenticates the client
via PSK.</t>
<t>5.1.2. else the identity is invalid, and the server close
s the connection.</t>
</li>
</ul>
<t>5.2 If the identity is not UTF-8, try resumption, which is us
ually be handled by a TLS library.</t>
<ul empty="true">
<li>
<t>5.2.1 If the TLS library verifies the session ticket, res
umption has happened, and the connection is established.</t>
<t>5.2.2. else the server ignores the session ticket, and pe
rforms normal TLS handshake with a certificate.</t>
</li>
</ul>
</li>
</ul>
</li>
</ul>
<t>This validation flow is only suggested. Other validation methods are possible.</t> <t>This validation flow is only suggested. Other validation methods are possible.</t>
<section anchor="security-of-psk-identities"> <section anchor="security-of-psk-identities">
<name>Security of PSK Identities</name> <name>Security of PSK Identities</name>
<t>We note that the PSK Identity is a field created by the connecting <t>We note that the PSK Identity is a field created by the
client. Since the client is untrusted until both the identity and PSK have been connecting client. Since the client is untrusted until both the
verified, both of those fields MUST be treated as untrusted. That is, a well-f identity and PSK have been verified, both of those fields
ormed PSK Identity is likely to be in UTF-8 format, due to the requirements of < <bcp14>MUST</bcp14> be treated as untrusted. That is, a well-formed
xref section="5.1" sectionFormat="comma" target="RFC4279"/>. However, implement PSK Identity is likely to be in UTF-8 format, due to the
ations MUST support managing PSK Identities as a set of undistinguished octets.< requirements of <xref section="5.1" sectionFormat="comma"
/t> target="RFC4279"/>. However, implementations <bcp14>MUST</bcp14>
<t>It is not safe to use a raw PSK Identity to look up a corresponding support managing PSK Identities as a set of undistinguished
PSK. The PSK may come from an untrusted source, and may contain invalid or mal octets.</t>
icious data. For example, the identity may have incorrect UTF-8 format; or it m
ay contain data which forms an injection attack for SQL, LDAP, REST or shell met <t>It is not safe to use a raw PSK Identity to look up a
a characters; or it may contain embedded NUL octets which are incompatible with corresponding PSK. The PSK may come from an untrusted source and
APIs which expect NUL terminated strings. The identity may also be up to 65535 may contain invalid or malicious data. For example, the identity
octets long.</t> may:</t>
<t>As such, implementations MUST validate the identity prior to it bei <ul>
ng used as a lookup key. When the identity is passed to an external API (e.g., <li>have an incorrect UTF-8 format,</li>
database lookup), implementations MUST either escape any characters in the ident <li>contain data that forms an injection attack for SQL, the
ity which are invalid for that API, or else reject the identity entirely. The e Lightweight Directory Access Protocol (LDAP), Representational
xact form of any escaping depends on the API, and we cannot document all possibl State Transfer (REST), or shell meta characters, or</li>
e methods here. However, a few basic validation rules are suggested, as outline <li>contain embedded NUL octets that are incompatible with APIs
d below. Any identity which is rejected by these validation rules MUST cause th that expect NUL terminated strings.</li>
e server to close the TLS connection.</t> </ul>
<t>The identity may also be up to 65535 octets long.</t>
<t>As such, implementations <bcp14>MUST</bcp14> validate the
identity prior to it being used as a lookup key. When the identity
is passed to an external API (e.g., database lookup),
implementations <bcp14>MUST</bcp14> either escape any characters in
the identity that are invalid for that API, or else reject the
identity entirely. The exact form of any escaping depends on the
API, and we cannot document all possible methods here. However, a
few basic validation rules are suggested, as outlined below. Any
identity that is rejected by these validation rules
<bcp14>MUST</bcp14> cause the server to close the TLS
connection.</t>
<t>The suggested validation rules for identities used outside of resum ption are as follows:</t> <t>The suggested validation rules for identities used outside of resum ption are as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Identities MUST be checked to see if they have been provisioned <t>Identities <bcp14>MUST</bcp14> be checked to see if they have
as a resumption PSK. If so, then the session can be resumed, subject to any po been provisioned as a resumption PSK. If so, then the session
licies around resumption.</t> can be resumed, subject to any policies around resumption.</t>
</li> </li>
<li> <li>
<t>Identities longer than a fixed maximum SHOULD be rejected. The <t>Identities longer than a fixed maximum <bcp14>SHOULD</bcp14>
limit is implementation dependent, but SHOULD NOT be less than 128, and SHOULD be rejected. The limit is implementation dependent, but
NOT be more than 1024. There is no purpose to allowing extremely long identitie <bcp14>SHOULD NOT</bcp14> be less than 128, and <bcp14>SHOULD
s, and allowing them does little more than complicate implementations.</t> NOT</bcp14> be more than 1024. There is no purpose to allowing
extremely long identities, and allowing them does little more
than complicate implementations.</t>
</li> </li>
<li> <li>
<t>Identities configured by administrators SHOULD be in UTF-8 form <t>Identities configured by administrators <bcp14>SHOULD</bcp14>
at, and SHOULD be in the <xref target="RFC7542"/> NAI format. While <xref secti be in UTF-8 format, and <bcp14>SHOULD</bcp14> be in the NAI
on="4.2.11" sectionFormat="comma" target="RFC8446"/> defines the PSK Identity as format from <xref target="RFC7542"/>. While <xref
"opaque identity&lt;1..2^16-1&gt;", it is useful for administrators to manage h section="4.2.11" sectionFormat="comma" target="RFC8446"/>
umanly-readable identities in a recognizable format. defines the PSK Identity as "opaque identity&lt;1..2<sup>16</sup>-
<br/><br/> 1&gt;",
This suggestion makes it easier to distinguish TLS-PSK Identities from TLS 1.3 r it is useful for administrators to manage human-readable
esumption identities. It also allows implementations to more easily filter out identities in a recognizable format.</t>
unexpected or bad identities, and then to close inappropriate TLS connections.</ <t>This suggestion makes it easier to distinguish TLS-PSK
t> Identities from TLS 1.3 resumption identities. It also allows
implementations to more easily filter out unexpected or bad
identities, and then to close inappropriate TLS connections.</t>
</li> </li>
</ul> </ul>
<t>It is RECOMMENDED that implementations extend these rules with any <t>It is <bcp14>RECOMMENDED</bcp14> that implementations extend
additional validation which are found to be useful. For example, implementation these rules with any additional validation that is found to be
s and/or deployments could both generate PSK Identities in a particular format f useful. For example, implementations and/or deployments could both
or passing to client systems, and then also verify that any received identity ma generate PSK Identities in a particular format for passing to client
tches that format. For example, a site could generate PSK Identities which are systems, and then also verify that any received identity matches
composed of characters in the local language. The site could then reject identi that format. For example, a site could generate PSK Identities
ties which contain characters from other languages, even if those characters are that are composed of characters in the local language. The site
valid UTF-8.</t> could then reject identities that contain characters from other
<t>The purpose of these rules is to help administrators and implemente languages, even if those characters are valid UTF-8.</t>
rs more easily manage systems using TLS-PSK, while also minimizing complexity an <t>The purpose of these rules is to help administrators and
d protecting from potential attackers traffic. The rules follow a principle of implementers more easily manage systems using TLS-PSK, while also
"discard bad traffic quickly", which helps to improve system stability and perfo minimizing complexity and protecting from potential attackers'
rmance.</t> traffic. The rules follow a principle of "discard bad traffic
quickly", which helps to improve system stability and
performance.</t>
</section> </section>
</section> </section>
<section anchor="sharing"> <section anchor="sharing">
<name>PSK and PSK Identity Sharing</name> <name>PSK and PSK Identity Sharing</name>
<t>While administrators may desire to share PSKs and/or PSK Identities a <t>While administrators may desire to share PSKs and/or PSK Identities
cross multiple systems, such usage is NOT RECOMMENDED. Details of the possible across multiple systems, such usage is <bcp14>NOT RECOMMENDED</bcp14>.
attacks on reused PSKs are given in <xref section="4.1" sectionFormat="comma" ta Details of the possible attacks on reused PSKs are given in <xref
rget="RFC9257"/>.</t> section="4.1" sectionFormat="comma" target="RFC9257"/>.</t>
<t>Implementations MUST support the ability to configure a unique PSK an <t>Implementations <bcp14>MUST</bcp14> support the ability to
d PSK Identity for each possible client-server relationship. This configuration configure a unique PSK and PSK Identity for each possible
allows administrators desiring security to use unique PSKs for each such relati client-server relationship. This configuration allows administrators
onship. This configuration is also compatible with the practice of administrato desiring security to use unique PSKs for each such relationship. This
rs who wish to re-use PSKs and PSK Identities where local policies permit.</t> configuration is also compatible with the practice of administrators
<t>Implementations SHOULD warn administrators if the same PSK Identity a who wish to reuse PSKs and PSK Identities where local policies
nd/or PSK is used for multiple client-server relationships.</t> permit.</t>
<t>Implementations <bcp14>SHOULD</bcp14> warn administrators if the
same PSK Identity and/or PSK is used for multiple client-server
relationships.</t>
</section> </section>
<section anchor="psk-lifetimes"> <section anchor="psk-lifetimes">
<name>PSK Lifetimes</name> <name>PSK Lifetimes</name>
<t>Unfortunately, <xref target="RFC9257"/> offers no guidance on PSK lif <t>Unfortunately, <xref target="RFC9257"/> offers no guidance on PSK
etimes other than to note Section 4.2 that:</t> lifetimes other than to note in Section <xref target="RFC9257" sectionFo
<ul empty="true"> rmat="bare" section="4.2"/> that:</t>
<li> <blockquote>
<t>Forward security may be achieved by using a PSK-DH mode or by usi <t>Forward security may be achieved by using a PSK-DH mode or by
ng PSKs with short lifetimes.</t> using PSKs with short lifetimes.</t>
</li> </blockquote>
</ul> <t>It is <bcp14>RECOMMENDED</bcp14> that PSKs be rotated regularly.
<t>It is RECOMMENDED that PSKs be rotated regularly. We offer no additi We offer no additional guidance on how often this process should
onal guidance on how often this process should occur. Changing PSKs has a non-z occur. Changing PSKs has a non-zero cost. It is therefore up to
ero cost. It is therefore up to administrators to determine how best to balance administrators to determine how best to balance the cost of changing
the cost of changing the PSK against the cost of a potential PSK compromise.</t the PSK against the cost of a potential PSK compromise.</t>
> <t>TLS-PSK <bcp14>MUST</bcp14> use modes such as PSK-DH or ECDHE_PSK
<t>TLS-PSK MUST use modes such as PSK-DH or ECDHE_PSK <xref target="RFC5 <xref target="RFC5489"/> that provide forward secrecy. Failure to
489"/> which provide forward secrecy. Failure to use such modes would mean that use such modes would mean that compromise of a PSK would allow an
compromise of a PSK would allow an attacker to decrypt all sessions which had u attacker to decrypt all sessions that had used that PSK.</t>
sed that PSK.</t> <t>As the PSKs are looked up by identity, the PSK Identity
<t>As the PSKs are looked up by identity, the PSK Identity MUST also be <bcp14>MUST</bcp14> also be changed when the PSK changes.</t>
changed when the PSK changes.</t> <t>Servers <bcp14>SHOULD</bcp14> track when a connection was last
<t>Servers SHOULD track when a connection was last received for a partic received for a particular PSK Identity, and <bcp14>SHOULD</bcp14>
ular PSK Identity, and SHOULD automatically invalidate credentials when a client automatically invalidate credentials when a client has not connected
has not connected for an extended period of time. This process helps to mitiga for an extended period of time. This process helps to mitigate the
te the issue of credentials being leaked when a device is stolen or discarded.</ issue of credentials being leaked when a device is stolen or
t> discarded.</t>
</section> </section>
</section> </section>
<section anchor="guidance-for-radius-clients"> <section anchor="guidance-for-radius-clients">
<name>Guidance for RADIUS Clients</name> <name>Guidance for RADIUS Clients</name>
<t>Client implementations MUST allow the use of a pre-shared key (PSK) for <t>Client implementations <bcp14>MUST</bcp14> allow the use of a
RADIUS/TLS. The client implementation can then expose a user interface flag wh Pre-Shared Key (PSK) for RADIUS/TLS. The client implementation can then
ich is "TLS yes / no", and then also fields which ask for the PSK Identity and P provide a user interface flag that is "TLS yes / no", and also provide
SK itself.</t> fields that ask for the PSK Identity and PSK itself.</t>
<t>For TLS 1.3, Implementations MUST support "psk_dhe_ke" Pre-Shared Key E
xchange Mode in TLS 1.3 as discussed in <xref section="4.2.9" sectionFormat="com <t>For TLS 1.3, implementations <bcp14>MUST</bcp14> support the "psk_dhe_k
ma" target="RFC8446"/> and in <xref section="6" sectionFormat="comma" target="RF e" PSK Exchange Mode as discussed in <xref target="RFC8446"
C9257"/>. Implementations MUST implement the recommended cipher suites in <xref sectionFormat="comma" section="4.2.9"/> and in <xref target="RFC9257"
section="4.2" sectionFormat="comma" target="RFC9325"/> for TLS 1.2, and in <xre sectionFormat="comma" section="6"/>. Implementations <bcp14>MUST</bcp14>
f section="9.1" sectionFormat="comma" target="RFC8446"/> for TLS 1.3. In order implement the
to future-proof these recommendations, we give the following recommendations:</t recommended cipher suites in <xref target="RFC9325"
> sectionFormat="comma" section="4.2"/> for TLS 1.2 and in <xref
target="RFC8446" sectionFormat="comma" section="9.1"/> for TLS 1.3. In
order to future-proof these recommendations, we give the following
recommendations.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Implementations SHOULD use the "Recommended" cipher suites listed i <t>Implementations <bcp14>SHOULD</bcp14> use the "Recommended"
n the IANA "TLS Cipher Suites" registry, cipher suites listed in the IANA "TLS Cipher Suites" registry:</t>
</t> <ul spacing="normal">
<ul spacing="normal"> <li>
<li> <t>For TLS 1.3, use the "psk_dhe_ke" PSK key exchange mode.</t>
<t>for TLS 1.3, the use "psk_dhe_ke" PSK key exchange mode,</t> </li>
</li> <li>
<li> <t>For TLS 1.2 and earlier, use cipher suites that require ephemera
<t>for TLS 1.2 and earlier, use cipher suites which require epheme l keying.</t>
ral keying.</t> </li>
</li> </ul>
</ul> </li>
</li>
</ul> </ul>
<t>If a client initiated a connection using a PSK with TLS 1.3 by includin
g the pre-shared key extension, it MUST close the connection if the server did n <t>If a client initiated a connection using a PSK with TLS 1.3 by
ot also select the pre-shared key to continue the handshake.</t> including the PSK extension, it <bcp14>MUST</bcp14> close the
connection if the server did not also select the PSK to
continue the handshake.</t>
<section anchor="psk-identities-1"> <section anchor="psk-identities-1">
<name>PSK Identities</name> <name>PSK Identities</name>
<t>This section offers advice on both requirements for PSK Identities, a nd on usability.</t> <t>This section offers advice on both requirements for PSK Identities an d on usability.</t>
<section anchor="psk-identity-requirements"> <section anchor="psk-identity-requirements">
<name>PSK Identity Requirements</name> <name>PSK Identity Requirements</name>
<t><xref target="RFC6614"/> is silent on the subject of PSK Identities <t><xref target="RFC6614"/> is silent on the subject of PSK
, which is an issue that we correct here. Guidance is required on the use of PS Identities, which is an issue that we correct here. Guidance is
K Identities, as the need to manage identities associated with PSK is a new requ required on the use of PSK Identities, as the need to manage
irement for NAS management interfaces, and is a new requirement for RADIUS serve identities associated with PSKs is a new requirement for both Network
rs.</t> Access Server (NAS)
<t>RADIUS systems implementing TLS-PSK MUST support identities as per management interfaces and RADIUS
<xref section="5.3" sectionFormat="comma" target="RFC4279"/>, and MUST enable co servers.</t>
nfiguring TLS-PSK Identities in management interfaces as per <xref section="5.4" <t>RADIUS systems implementing TLS-PSK <bcp14>MUST</bcp14> support
sectionFormat="comma" target="RFC4279"/>.</t> identities as per <xref section="5.3" sectionFormat="comma"
<t>The historic methods of signing RADIUS packets have not yet been br target="RFC4279"/> and <bcp14>MUST</bcp14> enable configuring
oken, but they are believed to be much less secure than modern TLS. Therefore, TLS-PSK Identities in management interfaces as per <xref
when a RADIUS shared secret is used to sign RADIUS/UDP or RADIUS/TCP packets, th section="5.4" sectionFormat="comma" target="RFC4279"/>.</t>
at shared secret MUST NOT be used with TLS-PSK. If the secrets were to be reuse <t>The historic methods of signing RADIUS packets have not yet been
d, then an attack on historic RADIUS cryptography could be trivially leveraged t broken, but they are believed to be much less secure than modern
o decrypt TLS-PSK sessions.</t> TLS. Therefore, when a RADIUS shared secret is used to sign
<t>With TLS-PSK, RADIUS/TLS clients MUST permit the configuration of a RADIUS/UDP or RADIUS/TCP packets, that shared secret <bcp14>MUST
RADIUS server IP address or host name, because dynamic server lookups <xref tar NOT</bcp14> be used with TLS-PSK. If the secrets were to be reused,
get="RFC7585"/> can only be used if servers use certificates.</t> then an attack on historic RADIUS cryptography could be trivially
leveraged to decrypt TLS-PSK sessions.</t>
<t>With TLS-PSK, RADIUS/TLS clients <bcp14>MUST</bcp14> permit the
configuration of a RADIUS server IP address or host name, because
dynamic server lookups <xref target="RFC7585"/> can only be used if
servers use certificates.</t>
</section> </section>
<section anchor="usability-guidance-1"> <section anchor="usability-guidance-1">
<name>Usability Guidance</name> <name>Usability Guidance</name>
<t>In order to prevent confusion between shared secrets and TLS-PSKs, <t>In order to prevent confusion between shared secrets and
management interfaces and APIs need to label PSK fields as "PSK" or "TLS-PSK", r TLS-PSKs, management interfaces and APIs need to label PSK fields as
ather than as "shared secret".</t> "PSK" or "TLS-PSK", rather than as "shared secret".</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="guidance-for-radius-servers"> <section anchor="guidance-for-radius-servers">
<name>Guidance for RADIUS Servers</name> <name>Guidance for RADIUS Servers</name>
<t>In order to support clients with TLS-PSK, server implementations MUST a <t>In order to support clients with TLS-PSK, server implementations
llow the use of a pre-shared key (TLS-PSK) for RADIUS/TLS.</t> <bcp14>MUST</bcp14> allow the use of a PSK (TLS-PSK) for
<t>Systems which act as both client and server at the same time MUST NOT s RADIUS/TLS.</t>
hare or reuse PSK Identities between incoming and outgoing connections. Doing s <t>Systems that act as both client and server at the same time
o would open up the systems to attack, as discussed in <xref section="4.1" secti <bcp14>MUST NOT</bcp14> share or reuse PSK Identities between incoming
onFormat="comma" target="RFC9257"/>.</t> and outgoing connections. Doing so would open up the systems to attack,
<t>For TLS 1.3, Implementations MUST support "psk_dhe_ke" Pre-Shared Key E as discussed in <xref section="4.1" sectionFormat="comma"
xchange Mode in TLS 1.3 as discussed in <xref section="4.2.9" sectionFormat="com target="RFC9257"/>.</t>
ma" target="RFC8446"/> and in <xref section="6" sectionFormat="comma" target="RF <t>For TLS 1.3, implementations <bcp14>MUST</bcp14> support the "psk_dhe_k
C9257"/>. Implementations MUST implement the recommended cipher suites in <xref e"
section="4.2" sectionFormat="comma" target="RFC9325"/> for TLS 1.2, and in <xre PSK Exchange Mode as discussed in <xref
f section="9.1" sectionFormat="comma" target="RFC8446"/> for TLS 1.3. In order section="4.2.9" sectionFormat="comma" target="RFC8446"/> and in <xref
to future-proof these recommendations, we give the following recommendations:</t section="6" sectionFormat="comma" target="RFC9257"/>. Implementations
> <bcp14>MUST</bcp14> implement the recommended cipher suites in <xref
section="4.2" sectionFormat="comma" target="RFC9325"/> for TLS 1.2 and
in <xref section="9.1" sectionFormat="comma" target="RFC8446"/> for TLS
1.3. In order to future-proof these recommendations, we give the
following recommendations.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Implementations SHOULD use the "Recommended" cipher suites listed i <t>Implementations <bcp14>SHOULD</bcp14> use the "Recommended"
n the IANA "TLS Cipher Suites" registry, cipher suites listed in the IANA "TLS Cipher Suites" registry:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>for TLS 1.3, use "psk_dhe_ke" PSK key exchange mode,</t> <t>For TLS 1.3, use the "psk_dhe_ke" PSK key exchange mode.</t>
</li> </li>
<li> <li>
<t>for TLS 1.2 and earlier, use cipher suites which require epheme ral keying.</t> <t>For TLS 1.2 and earlier, use cipher suites that require ephemer al keying.</t>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>The following section(s) describe guidance for RADIUS server implementa <t>The following section(s) describe guidance for RADIUS server
tions and deployments. We first give an overview of current practices, and then implementations and deployments. We first give an overview of current
extend and/or replace those practices for TLS-PSK.</t> practices, and then extend and/or replace those practices for
TLS-PSK.</t>
<section anchor="current-practices"> <section anchor="current-practices">
<name>Current Practices</name> <name>Current Practices</name>
<t>RADIUS identifies clients by source IP address (<xref target="RFC2865 <t>RADIUS identifies clients by source IP address (see <xref
"/> and <xref target="RFC6613"/>) or by client certificate (<xref target="RFC661 target="RFC2865"/> and <xref target="RFC6613"/>) or by client
4"/> and <xref target="RFC7585"/>). Neither of these approaches work for TLS-PS certificate (see <xref target="RFC6614"/> and <xref target="RFC7585"/>).
K. This section describes current practices and mandates behavior for servers w Neither of these approaches work for TLS-PSK. This section describes
hich use TLS-PSK.</t> current practices and mandates behavior for servers that use
<t>A RADIUS/UDP server is typically configured with a set of information TLS-PSK.</t>
per client, which includes at least the source IP address and shared secret. W <t>A RADIUS/UDP server is typically configured with a set of
hen the server receives a RADIUS/UDP packet, it looks up the source IP address, information per client, which includes at least the source IP address
finds a client definition, and therefore the shared secret. The packet is then and shared secret. When the server receives a RADIUS/UDP packet, it
authenticated (or not) using that shared secret.</t> looks up the source IP address, finds a client definition, and
<t>That is, the IP address is treated as the clients identity, and the s therefore the shared secret. The packet is then authenticated (or
hared secret is used to prove the clients authenticity and shared trust. The se not) using that shared secret.</t>
t of clients forms a logical database "client table", with the IP address as the <t>That is, the IP address is treated as the client's identity, and the
key.</t> shared secret is used to prove the client's authenticity and shared
<t>A server may be configured with additional site-local policies associ trust. The set of clients forms a logical database "client table"
ated with that client. For example, a client may be marked up as being a WiFi A with the IP address as the key.</t>
ccess Point, or a VPN concentrator, etc. Different clients may be permitted to <t>A server may be configured with additional site-local policies
send different kinds of requests, where some may send Accounting-Request packets associated with that client. For example, a client may be marked up
, and other clients may not send accounting packets.</t> as being a Wi-Fi Access Point, a VPN concentrator, etc. Different
clients may be permitted to send different kinds of requests, where
some may send Accounting-Request packets, and other clients may not
send accounting packets.</t>
</section> </section>
<section anchor="practices-for-tls-psk"> <section anchor="practices-for-tls-psk">
<name>Practices for TLS-PSK</name> <name>Practices for TLS-PSK</name>
<t>We define practices for TLS-PSK by analogy with the RADIUS/UDP use-ca <t>We define practices for TLS-PSK by analogy with the RADIUS/UDP
se, and by extending the additional policies associated with the client. The PS use case and by extending the additional policies associated with the
K Identity replaces the source IP address as the client identifier. The PSK rep client. The PSK Identity replaces the source IP address as the client
laces the shared secret as proof of client authenticity and shared trust. Howev identifier. The PSK replaces the shared secret as proof of client
er, systems implementing RADIUS/TLS <xref target="RFC6614"/> and RADIUS/DTLS <xr authenticity and shared trust. However, systems implementing
ef target="RFC7360"/> MUST still use the shared secret as discussed in those spe RADIUS/TLS <xref target="RFC6614"/> and RADIUS/DTLS <xref
cifications. Any PSK is only used by the TLS layer, and has no effect on the RA target="RFC7360"/> <bcp14>MUST</bcp14> still use the shared secret as
DIUS data which is being transported. That is, the RADIUS data transported in a discussed in those specifications. Any PSK is only used by the TLS
TLS tunnel is the same no matter if client authentication is done via PSK or by layer and has no effect on the RADIUS data that is being
client certificates. The encoding of the RADIUS data is entirely unaffected by transported. That is, the RADIUS data transported in a TLS tunnel is
the use (or not) of PSKs and client certificates.</t> the same no matter if client authentication is done via PSK or by
<t>In order to securely support dynamic source IP addresses for clients, client certificates. The encoding of the RADIUS data is entirely
we also require that servers limit clients based on a network range. The alter unaffected by the use (or not) of PSKs and client certificates.</t>
native would be to suggest that RADIUS servers allow any source IP address to co <t>In order to securely support dynamic source IP addresses for
nnect and try TLS-PSK, which could be a security risk. When RADIUS servers do n clients, we also require that servers limit clients based on a network
o source IP address filtering, it is easier for attackers to send malicious traf range. The alternative would be to suggest that RADIUS servers allow
fic to the server. An issue with a TLS library or even a TCP/IP stack could per any source IP address to connect and try TLS-PSK, which could be a
mit the attacker to gain unwarranted access. In contrast, when IP address filte security risk. When RADIUS servers do no source IP address filtering,
ring is done, attackers generally must first gain access to a secure network bef it is easier for attackers to send malicious traffic to the server.
ore attacking the RADIUS server.</t> An issue with a TLS library or even a TCP/IP stack could permit the
<t>Even where <xref target="RFC7585"/> dynamic discovery is not used, th attacker to gain unwarranted access. In contrast, when IP address
e use of TLS-PSK across unrelated organizations requires that those organization filtering is done, attackers generally must first gain access to a
s share PSKs. Such sharing makes it easier for a client to impersonate a server secure network before attacking the RADIUS server.</t>
, and vice versa. In contrast, when certificates are used, such impersonations <t>Even where dynamic discovery <xref target="RFC7585"/> is not used,
are impossible. It is therefore NOT RECOMMENDED to use TLS-PSK across organizati the use of TLS-PSK across unrelated organizations requires that those
onal boundaries.</t> organizations share PSKs. Such sharing makes it easier for a client
<t>When TLS-PSK is used in an environment where both client and server a to impersonate a server, and vice versa. In contrast, when
re part of the same organization, then impersonations only affect that organizat certificates are used, such impersonations are impossible. It is
ion. As TLS offers significant advantages over RADIUS/UDP, it is RECOMMENDED th therefore <bcp14>NOT RECOMMENDED</bcp14> to use TLS-PSK across
at organizations use RADIUS/TLS with TLS-PSK to replace RADIUS/UDP for all syste organizational boundaries.</t>
ms managed within the same organization. While such systems are generally locat <t>When TLS-PSK is used in an environment where both client and server
ed inside of private networks, there are no known security issues with using TLS are part of the same organization, then impersonations only affect
-PSK for RADIUS/TLS connections across the public Internet.</t> that organization. As TLS offers significant advantages over
<t>If a client system is compromised, its complete configuration is expo RADIUS/UDP, it is <bcp14>RECOMMENDED</bcp14> that organizations use
sed to the attacker. Exposing a client certificate means that the attacker can RADIUS/TLS with TLS-PSK to replace RADIUS/UDP for all systems managed
pretend to be the client. In contrast, exposing a PSK means that the attacker c within the same organization. While such systems are generally
an not only pretend to be the client, but can also pretend to be the server.</t> located inside of private networks, there are no known security issues
<t>The main benefit of TLS-PSK, therefore, is that its operational proce with using TLS-PSK for RADIUS/TLS connections across the public
sses are similar to that used for managing RADIUS/UDP, while gaining the increas Internet.</t>
ed security of TLS. However, it is still beneficial for servers to perform IP <t>If a client system is compromised, its complete configuration is
address filtering, in order to further limit their exposure to attacks.</t> exposed to the attacker. Exposing a client certificate means that the
attacker can pretend to be the client. In contrast, exposing a PSK
means that the attacker cannot only pretend to be the client, but can
also pretend to be the server.</t>
<t>The main benefit of TLS-PSK, therefore, is that its operational
processes are similar to that used for managing RADIUS/UDP, while
gaining the increased security of TLS. However, it is still
beneficial for servers to perform IP address filtering, in order to
further limit their exposure to attacks.</t>
<section anchor="ip-filtering"> <section anchor="ip-filtering">
<name>IP Filtering</name> <name>IP Filtering</name>
<t>A server supporting this specification MUST perform IP address filt <t>A server supporting this specification <bcp14>MUST</bcp14>
ering on incoming connections. There are few reasons for a server to have a def perform IP address filtering on incoming connections. There are few
ault configuration which allows connections from any source IP address.</t> reasons for a server to have a default configuration that allows
<t>A TLS-PSK server MUST be configurable with a set of "allowed" netwo connections from any source IP address.</t>
rk ranges from which clients are permitted to connect. Any connection from outs <t>A TLS-PSK server <bcp14>MUST</bcp14> be configurable with a set
ide of the allowed range(s) MUST be rejected before any PSK Identity is checked. of "allowed" network ranges from which clients are permitted to
It is RECOMMENDED that servers support IP address filtering even when TLS-PSK connect. Any connection from outside of the allowed range(s)
is not used.</t> <bcp14>MUST</bcp14> be rejected before any PSK Identity is checked.
<t>The "allowed" network ranges could be implemented as a global list, It is <bcp14>RECOMMENDED</bcp14> that servers support IP address
or one or more network ranges could be tied to a client or clients. The intent filtering even when TLS-PSK is not used.</t>
here is to allow connections to be filtered by source IP address, and to allow <t>The "allowed" network ranges could be implemented as a global
clients to be limited to a subset of network addresses. The exact method and re list, or one or more network ranges could be tied to a client or
presentation of that filtering is up to an implementation.</t> clients. The intent here is to allow connections to be filtered by
<t>Conceptually, the set of IP addresses and ranges, along with permit source IP address and to allow clients to be limited to a subset of
ted clients and their credentials forms a logical "client table" which the serve network addresses. The exact method and representation of that
r uses to both filter and authenticate clients. The client table should contain filtering is up to an implementation.</t>
information such as allowed network ranges, PSK Identity and associated PSK, cr <t>Conceptually, the set of IP addresses and ranges, along with
edentials for another TLS authentication method, or flags which indicate that th permitted clients and their credentials, form a logical "client
e server should require a client certificate.</t> table" that the server uses to both filter and authenticate
<t>Once a server receives a connection, it checks the source IP addres clients. The client table should contain information such as
s against the list of all allowed IP addresses or ranges in the client table. I allowed network ranges, PSK Identity and associated PSK, credentials
f none match, the connection MUST be rejected. That is, the connection MUST be for another TLS authentication method, or flags that indicate that
from an authorized source IP address.</t> the server should require a client certificate.</t>
<t>Once a connection has been established, the server MUST NOT process <t>Once a server receives a connection, it checks the source IP
any application data inside of the TLS tunnel until the client has been authent address against the list of all allowed IP addresses or ranges in
icated. Instead, the server normally receives a TLS-PSK Identity from the clien the client table. If none match, the connection <bcp14>MUST</bcp14>
t. The server then uses this identity to look up the client in the client table be rejected. That is, the connection <bcp14>MUST</bcp14> be from an
. If there is no matching client, the server MUST close the connection. The se authorized source IP address.</t>
rver then also checks if this client definition allows this particular source IP <t>Once a connection has been established, the server <bcp14>MUST
address. If the source IP address is not allowed, the server MUST close the co NOT</bcp14> process any application data inside of the TLS tunnel
nnection.</t> until the client has been authenticated. Instead, the server
<t>Where the server does not receive TLS-PSK from the client, it proce normally receives a TLS-PSK Identity from the client. The server
eds with another authentication method such as client certificates. Such requir then uses this identity to look up the client in the client table.
ements are discussed elsewhere, most notably in <xref target="RFC6614"/> and <xr If there is no matching client, the server <bcp14>MUST</bcp14> close
ef target="RFC7360"/>.</t> the connection. The server then also checks if this client
<t>An implementation may perform two independent IP address lookups. definition allows this particular source IP address. If the source
First, to check if the connection allowed at all, and second to check if the con IP address is not allowed, the server <bcp14>MUST</bcp14> close the
nection is authorized for this particular client. One or both checks may be use connection.</t>
d by a particular implementation. The two sets of IP addresses can overlap, and <t>Where the server does not receive TLS-PSK from the client, it
implementations SHOULD support that capability.</t> proceeds with another authentication method such as client
<t>Depending on the implementation, one or more clients may share a li certificates. Such requirements are discussed elsewhere, most
st of allowed network ranges. Alternately, the allowed network ranges for two c notably in <xref target="RFC6614"/> and <xref
lients can overlap only partially, or not at all. All of these possibilities MU target="RFC7360"/>.</t>
ST be supported by the server implementation.</t> <t>An implementation may perform two independent IP address lookups:
<t>For example, a RADIUS server could be configured to be accept conne first to check if the connection is allowed at all, and second to
ctions from a source network of 192.0.2.0/24 or 2001:DB8::/32. The server could check if the connection is authorized for this particular client.
therefore discard any TLS connection request which comes from a source IP addre One or both checks may be used by a particular implementation. The
ss outside of that network. In that case, there is no need to examine the PSK I two sets of IP addresses can overlap, and implementations
dentity or to find the client definition. Instead, the IP source filtering poli <bcp14>SHOULD</bcp14> support that capability.</t>
cy would deny the connection before any TLS communication had been performed.</t <t>Depending on the implementation, one or more clients may share a
> list of allowed network ranges. Alternately, the allowed network
<t>As some clients may have dynamic IP addresses, it is possible for a ranges for two clients can overlap only partially, or not at all.
one PSK Identity to appear at different source IP addresses over time. In addi All of these possibilities <bcp14>MUST</bcp14> be supported by the
tion, as there may be many clients behind one NAT gateway, there may be multiple server implementation.</t>
RADIUS clients using one public IP address. RADIUS servers MUST support multip <t>For example, a RADIUS server could be configured to accept
le PSK Identifiers at one source IP address.</t> connections from a source network of 192.0.2.0/24 or 2001:DB8::/32.
<t>That is, a server needs to support multiple different clients withi The server could therefore discard any TLS connection request that
n one network range, multiple clients behind a NAT, and one client having differ comes from a source IP address outside of that network. In that
ent IP addresses over time. All of those use-cases are common and necessary.</t case, there is no need to examine the PSK Identity or to find the
> client definition. Instead, the IP source filtering policy would
deny the connection before any TLS communication had been
performed.</t>
<t>As some clients may have dynamic IP addresses, it is possible for
one PSK Identity to appear at different source IP addresses over
time. In addition, as there may be many clients behind one NAT
gateway, there may be multiple RADIUS clients using one public IP
address. RADIUS servers <bcp14>MUST</bcp14> support multiple PSK
Identifiers at one source IP address.</t>
<t>That is, a server needs to support multiple different clients
within one network range, multiple clients behind a NAT, and one
client having different IP addresses over time. All of those
use cases are common and necessary.</t>
<t>The following section describes these requirements in more detail.< /t> <t>The following section describes these requirements in more detail.< /t>
</section> </section>
<section anchor="psk-authentication"> <section anchor="psk-authentication">
<name>PSK Authentication</name> <name>PSK Authentication</name>
<t>Once the source IP address has been verified to be allowed for this <t>Once the source IP address has been verified to be allowed for
particular client, the server authenticates the TLS connection via the PSK take this particular client, the server authenticates the TLS connection
n from the client definition. If the PSK is verified, the server then accepts t via the PSK taken from the client definition. If the PSK is
he connection, and proceeds with RADIUS/TLS as per <xref target="RFC6614"/>.</t> verified, the server then accepts the connection and proceeds with
<t>If the PSK is not verified, then the server MUST close the connecti RADIUS/TLS as per <xref target="RFC6614"/>.</t>
on. While TLS provides for fallback to other authentication methods such as cli <t>If the PSK is not verified, then the server <bcp14>MUST</bcp14>
ent certificates, there is no reason for a client to be configured simultaneousl close the connection. While TLS provides for fallback to other
y with multiple authentication methods.</t> authentication methods such as client certificates, there is no
<t>A client MUST use only one authentication method for TLS. An authe reason for a client to be configured simultaneously with multiple
ntication method is either TLS-PSK, client certificates, or some other method su authentication methods.</t>
pported by TLS.</t> <t>A client <bcp14>MUST</bcp14> use only one authentication method
<t>That is, client configuration is relatively simple: use a particula for TLS. An authentication method is either TLS-PSK, client
r set of credentials to authenticate to a particular server. While clients may certificates, or some other method supported by TLS.</t>
support multiple servers and fail-over or load-balancing, that configuration is <t>That is, client configuration is relatively simple: use a
generally orthogonal to the choice of which credentials to use.</t> particular set of credentials to authenticate to a particular
server. While clients may support multiple servers and fail-over or
load-balancing, that configuration is generally orthogonal to the
choice of which credentials to use.</t>
</section> </section>
<section anchor="resumption"> <section anchor="resumption">
<name>Resumption</name> <name>Resumption</name>
<t>It is NOT RECOMMENDED that servers enable resumption for sessions w <t>It is <bcp14>NOT RECOMMENDED</bcp14> that servers enable
hich use TLS-PSK. There are few practical benefits to supporting resumption, an resumption for sessions that use TLS-PSK. There are few practical
d many complexities.</t> benefits to supporting resumption and many complexities.</t>
<t>However, some systems will need to support both TLS-PSK, and other <t>However, some systems will need to support both TLS-PSK and
TLS-based authentication methods such as certificates, while also supporting ses other TLS-based authentication methods such as certificates, while
sion resumption. It is therefore vital for servers to be able to distinguish th also supporting session resumption. It is therefore vital for
e use-case of TLS-PSK with pre-configured identities from TLS-PSK which is being servers to be able to distinguish the use case of TLS-PSK with
used for resumptions.</t> preconfigured identities from TLS-PSK that is being used for
<t>The above discussion of PSK Identities is complicated by the use of resumptions.</t>
PSKs for resumption in TLS 1.3. A server which receives a PSK Identity via TLS <t>The above discussion of PSK Identities is complicated by the use
typically cannot query the TLS layer to see if this identity is for a resumed s of PSKs for resumption in TLS 1.3. A server that receives a PSK
ession (which is possibly for another TLS authentication method), or is instead Identity via TLS typically cannot query the TLS layer to see if this
a static pre-provisioned identity. This confusion complicates server implementa identity is for a resumed session (which is possibly for another TLS
tions.</t> authentication method), or is instead a static pre-provisioned
<t>One way for a server to tell the difference between the two kinds o identity. This confusion complicates server implementations.</t>
f identities is via construction. Identities used for resumption can be constru <t>One way for a server to tell the difference between the two kinds
cted via a fixed format, such as recommended by <xref section="4" sectionFormat= of identities is via construction. Identities used for resumption
"comma" target="RFC5077"/>. A static pre-provisioned identity could be in forma can be constructed via a fixed format, such as what is recommended by
t of an NAI, as given in <xref target="RFC7542"/>. An implementation could ther <xref
efore examine the incoming identity, and determine from the identity alone what section="4.6.1" sectionFormat="comma" target="RFC8446"/>. A static
kind of authentication was being performed.</t> pre-provisioned identity could be in the format of an NAI, as given in
<t>An alternative way for a server to distinguish the two kinds of ide <xref target="RFC7542"/>. An implementation could therefore examine
ntities is to maintain two tables. One table would contain static identities, a the incoming identity and determine from the identity alone what
s the logical client table described above. Another table could be the table of kind of authentication was being performed.</t>
identities handed out for resumption. The server would then look up any PSK Id <t>An alternative way for a server to distinguish the two kinds of
entity in one table, and if not found, query the other one. An identity would b identities is to maintain two tables. One table would contain
e found in a table, in which case it can be authenticated. Or, the identity wou static identities, as the logical client table described above.
ld not be found in either table, in which case it is unknown, and the server MUS Another table could be the table of identities handed out for
T close the connection.</t> resumption. The server would then look up any PSK Identity in one
<t>As suggested in <xref target="RFC8446"/>, TLS-PSK peers MUST NOT st table, and if it is not found, query the other one. Either an identit
ore resumption PSKs or tickets (and associated cached data) for longer than 6048 y would be
00 seconds (7 days) regardless of the PSK or ticket lifetime.</t> found in a table, in which case it can be authenticated, or the
<t>Since resumption in TLS 1.3 uses PSK Identies and keys, it is NOT R identity would not be found in either table, in which case it is
ECOMMENDED to permit resumption of sessions when TLS-PSK is used. The use of re unknown, and the server <bcp14>MUST</bcp14> close the
sumption offers additional complexity with minimal addition benefit.</t> connection.</t>
<t>Where resumption is allowed with TLS-PSK, systems MUST cache data d <t>As suggested in <xref target="RFC8446"/>, TLS-PSK peers
uring the initial full handshake sufficient to allow authorization decisions to <bcp14>MUST NOT</bcp14> store resumption PSKs or tickets (and
be made during resumption. If the cached data cannot be retrieved securely, resu associated cached data) for longer than 604800 seconds (7 days),
mption MUST NOT be done. Instead, the system MUST perform a full handshake.</t> regardless of the PSK or ticket lifetime.</t>
<t>The data which needs to be cached is typically information such as <t>Since resumption in TLS 1.3 uses PSK Identities and keys, it is
the original PSK Identity, along with any policies associated with that identity <bcp14>NOT RECOMMENDED</bcp14> to permit resumption of sessions when
.</t> TLS-PSK is used. The use of resumption offers additional complexity
<t>Information from the original TLS exchange (e.g., the original PSK with minimal additional benefits.</t>
Identity) as well as related information (e.g., source IP addresses) may change <t>Where resumption is allowed with TLS-PSK, systems
between the initial full handshake and resumption. This change creates a "time-o <bcp14>MUST</bcp14> cache data during the initial full handshake
f-check time-of-use" (TOCTOU) security vulnerability. A malicious or compromised sufficiently enough to allow authorization decisions to be made during
client could supply one set of data during the initial authentication, and a di resumption. If the cached data cannot be retrieved securely,
fferent set of data during resumption, potentially allowing them to obtain acces resumption <bcp14>MUST NOT</bcp14> be done. Instead, the system
s that they should not have.</t> <bcp14>MUST</bcp14> perform a full handshake.</t>
<t>If any authorization or policy decisions were made with information <t>The data that needs to be cached is typically information such
that has changed between the initial full handshake and resumption, and if chan as the original PSK Identity, along with any policies associated
ge may lead to a different decision, such decisions MUST be reevaluated. System with that identity.</t>
s MUST also reevaluate authorization and policy decisions during resumption, bas <t>Information from the original TLS exchange (e.g., the original
ed on the information given in the new connection. Servers MAY refuse to perfor PSK Identity) as well as related information (e.g., source IP
m resumption where the information supplied during resumption does not match the addresses) may change between the initial full handshake and
information supplied during the original authentication. If a safe decision is resumption. This change creates a "time-of-check time-of-use"
not possible, servers MUST instead continue with a full handshake.</t> (TOCTOU) security vulnerability. A malicious or compromised client
could supply one set of data during the initial authentication and
a different set of data during resumption, potentially allowing them
to obtain access that they should not have.</t>
<t>If any authorization or policy decisions were made with
information that has changed between the initial full handshake and
resumption, and if changes may lead to a different decision, such
decisions <bcp14>MUST</bcp14> be reevaluated. Systems
<bcp14>MUST</bcp14> also reevaluate authorization and policy
decisions during resumption, based on the information given in the
new connection. Servers <bcp14>MAY</bcp14> refuse to perform
resumption where the information supplied during resumption does not
match the information supplied during the original authentication.
If a safe decision is not possible, servers <bcp14>MUST</bcp14>
instead continue with a full handshake.</t>
</section> </section>
<section anchor="interaction-with-other-tls-authentication-methods"> <section anchor="interaction-with-other-tls-authentication-methods">
<name>Interaction with other TLS authentication methods</name> <name>Interaction with Other TLS Authentication Methods</name>
<t>When a server supports both TLS-PSK and client certificates, it MUS <t>When a server supports both TLS-PSK and client certificates, it
T be able to accept authenticated connections from clients which may use either <bcp14>MUST</bcp14> be able to accept authenticated connections from
type of credentials, perhaps even from the same source IP address and at the sam clients that may use either type of credentials, perhaps even from
e time. That is, servers are required to both authenticate the client, and also the same source IP address and at the same time. That is, servers
to filter clients by source IP address. These checks both have to match in ord are required to both authenticate the client and also to filter
er for a client to be accepted.</t> clients by source IP address. These checks both have to match in
order for a client to be accepted.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="privacy-considerations"> <section anchor="privacy-considerations">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>We make no changes over <xref target="RFC6614"/> and <xref target="RFC7 360"/>.</t> <t>We make no changes to <xref target="RFC6614"/> and <xref target="RFC736 0"/>.</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.</t> <t>The primary focus of this document is addressing security consideration s for RADIUS.</t>
<t>Previous specifications discuss security considerations for TLS-PSK in <t>Previous specifications discuss security considerations for TLS-PSK
detail. We refer the reader to <xref section="E.7" sectionFormat="comma" target in detail. We refer the reader to <xref section="E.7"
="RFC8446"/>, <xref target="RFC9257"/>, sectionFormat="of" target="RFC8446"/>, <xref target="RFC9257"/>, and
and <xref target="RFC9258"/>. Those documents are newer than <xref target="RFC6 <xref target="RFC9258"/>. Those documents are newer than <xref
614"/> and target="RFC6614"/> and <xref target="RFC7360"/>, and therefore raise
<xref target="RFC7360"/>, andtherefore raise issues which were not considered issues that were not considered during the initial design of RADIUS/TLS
during the initial design of RADIUS/TLS and RADIUS/DTLS.</t> and RADIUS/DTLS.</t>
<t>Using TLS-PSK across the wider Internet for RADIUS can have different s <t>Using TLS-PSK across the wider Internet for RADIUS can have different
ecurity considerations than for other protocols. For example, if TLS-PSK was fo security considerations than for other protocols. For example, if
r client/server communication with HTTPS, then having a PSK be exposed or broken TLS-PSK was for client/server communication with HTTPS, then having a
could affect one users traffic. In contrast, RADIUS contains credentials and p PSK be exposed or broken could affect one user's traffic. In contrast,
ersonally identifiable information (PII) for many users. As a result, an attack RADIUS contains credentials and personally identifiable information
er being able to see inside of a TLS-PSK connection for RADIUS would result in s (PII) for many users. As a result, an attacker being able to see inside
ubstantial amounts of PII being leaked, possibly including passwords.</t> of a TLS-PSK connection for RADIUS would result in substantial amounts
<t>When modes providing forward secrecy are used (e.g. ECDHE_PSK <xref tar of PII being leaked, possibly including passwords.</t>
get="RFC5489"/> and <xref target="RFC8442"/>), such attacks are limited to futur
e sessions, and historical sessions are still secure.</t> <t>When modes providing forward secrecy are used (e.g., ECDHE_PSK as seen
in <xref
target="RFC5489"/> and <xref target="RFC8442"/>), such attacks are
limited to future sessions, and historical sessions are still
secure.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>There are no IANA considerations in this document.</t> <t>This document has no IANA actions.</t>
<t>RFC Editor: This section may be removed before final publication.</t>
</section>
<section anchor="acknowledgments">
<name>Acknowledgments</name>
<t>Thanks to the many reviewers in the RADEXT working group for positive f
eedback.</t>
</section>
<section anchor="changelog">
<name>Changelog</name>
<ul spacing="normal">
<li>
<t>00 - initial version</t>
</li>
<li>
<t>01 - update examples</t>
</li>
</ul>
</section> </section>
</middle> </middle>
<back> <back>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC6614"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<front> 614.xml"/>
<title>Transport Layer Security (TLS) Encryption for RADIUS</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<author fullname="S. Winter" initials="S." surname="Winter"/> 360.xml"/>
<author fullname="M. McCauley" initials="M." surname="McCauley"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<author fullname="S. Venaas" initials="S." surname="Venaas"/> 865.xml"/>
<author fullname="K. Wierenga" initials="K." surname="Wierenga"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<date month="May" year="2012"/> 279.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<t>This document specifies a transport profile for RADIUS using Tr 174.xml"/>
ansport Layer Security (TLS) over TCP as the transport protocol. This enables dy <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
namic trust relationships between RADIUS servers. [STANDARDS-TRACK]</t> 265.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</front> 257.xml"/>
<seriesInfo name="RFC" value="6614"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<seriesInfo name="DOI" value="10.17487/RFC6614"/> 325.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<reference anchor="RFC7360"> 119.xml"/>
<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="RFC2865">
<front>
<title>Remote Authentication Dial In User Service (RADIUS)</title>
<author fullname="C. Rigney" initials="C." surname="Rigney"/>
<author fullname="S. Willens" initials="S." surname="Willens"/>
<author fullname="A. Rubens" initials="A." surname="Rubens"/>
<author fullname="W. Simpson" initials="W." surname="Simpson"/>
<date month="June" year="2000"/>
<abstract>
<t>This document describes a protocol for carrying authentication,
authorization, and configuration information between a Network Access Server 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="RFC4279">
<front>
<title>Pre-Shared Key Ciphersuites for Transport Layer Security (TLS
)</title>
<author fullname="P. Eronen" initials="P." role="editor" surname="Er
onen"/>
<author fullname="H. Tschofenig" initials="H." role="editor" surname
="Tschofenig"/>
<date month="December" year="2005"/>
<abstract>
<t>This document specifies three sets of new ciphersuites for the
Transport Layer Security (TLS) protocol to support authentication based on pre-s
hared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance a
mong the communicating parties. The first set of ciphersuites uses only symmetri
c key operations for authentication. The second set uses a Diffie-Hellman exchan
ge authenticated with a pre-shared key, and the third set combines public key au
thentication of the server with pre-shared key authentication of the client. [ST
ANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4279"/>
<seriesInfo name="DOI" value="10.17487/RFC4279"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8265">
<front>
<title>Preparation, Enforcement, and Comparison of Internationalized
Strings Representing Usernames and Passwords</title>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<author fullname="A. Melnikov" initials="A." surname="Melnikov"/>
<date month="October" year="2017"/>
<abstract>
<t>This document describes updated methods for handling Unicode st
rings representing usernames and passwords. The previous approach was known as S
ASLprep (RFC 4013) and was based on Stringprep (RFC 3454). The methods specified
in this document provide a more sustainable approach to the handling of interna
tionalized usernames and passwords. This document obsoletes RFC 7613.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8265"/>
<seriesInfo name="DOI" value="10.17487/RFC8265"/>
</reference>
<reference anchor="RFC9257">
<front>
<title>Guidance for External Pre-Shared Key (PSK) Usage in TLS</titl
e>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<author fullname="J. Hoyland" initials="J." surname="Hoyland"/>
<author fullname="M. Sethi" initials="M." surname="Sethi"/>
<author fullname="C. A. Wood" initials="C. A." surname="Wood"/>
<date month="July" year="2022"/>
<abstract>
<t>This document provides usage guidance for external Pre-Shared K
eys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. It list
s TLS security properties provided by PSKs under certain assumptions, then it de
monstrates how violations of these assumptions lead to attacks. Advice for appli
cations to help meet these assumptions is provided. This document also discusses
PSK use cases and provisioning processes. Finally, it lists the privacy and sec
urity properties that are not provided by TLS 1.3 when external PSKs are used.</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="9257"/>
<seriesInfo name="DOI" value="10.17487/RFC9257"/>
</reference>
<reference anchor="RFC9325">
<front>
<title>Recommendations for Secure Use of Transport Layer Security (T
LS) and Datagram Transport Layer Security (DTLS)</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<author fullname="T. Fossati" initials="T." surname="Fossati"/>
<date month="November" year="2022"/>
<abstract>
<t>Transport Layer Security (TLS) and Datagram Transport Layer Sec
urity (DTLS) are used to protect data exchanged over a wide range of application
protocols and can also form the basis for secure transport protocols. Over the
years, the industry has witnessed several serious attacks on TLS and DTLS, inclu
ding attacks on the most commonly used cipher suites and their modes of operatio
n. This document provides the latest recommendations for ensuring the security o
f deployed services that use TLS and DTLS. These recommendations are applicable
to the majority of use cases.</t>
<t>RFC 7525, an earlier version of the TLS recommendations, was pu
blished when the industry was transitioning to TLS 1.2. Years later, this transi
tion is largely complete, and TLS 1.3 is widely available. This document updates
the guidance given the new environment and obsoletes RFC 7525. In addition, thi
s document updates RFCs 5288 and 6066 in view of recent attacks.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="195"/>
<seriesInfo name="RFC" value="9325"/>
<seriesInfo name="DOI" value="10.17487/RFC9325"/>
</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="RFC5077"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<front> 613.xml"/>
<title>Transport Layer Security (TLS) Session Resumption without Ser <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
ver-Side State</title> 585.xml"/>
<author fullname="J. Salowey" initials="J." surname="Salowey"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="H. Zhou" initials="H." surname="Zhou"/> 446.xml"/>
<author fullname="P. Eronen" initials="P." surname="Eronen"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/ 937.xml"/>
> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<date month="January" year="2008"/> 258.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<t>This document describes a mechanism that enables the Transport 492.xml"/>
Layer Security (TLS) server to resume sessions and avoid keeping per-client sess <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
ion state. The TLS server encapsulates the session state into a ticket and forwa 542.xml"/>
rds it to the client. The client can subsequently resume a session using the obt <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
ained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]</t> 489.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</front> 442.xml"/>
<seriesInfo name="RFC" value="5077"/>
<seriesInfo name="DOI" value="10.17487/RFC5077"/>
</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="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>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC8937">
<front>
<title>Randomness Improvements for Security Protocols</title>
<author fullname="C. Cremers" initials="C." surname="Cremers"/>
<author fullname="L. Garratt" initials="L." surname="Garratt"/>
<author fullname="S. Smyshlyaev" initials="S." surname="Smyshlyaev"/
>
<author fullname="N. Sullivan" initials="N." surname="Sullivan"/>
<author fullname="C. Wood" initials="C." surname="Wood"/>
<date month="October" year="2020"/>
<abstract>
<t>Randomness is a crucial ingredient for Transport Layer Security
(TLS) and related security protocols. Weak or predictable "cryptographically se
cure" pseudorandom number generators (CSPRNGs) can be abused or exploited for ma
licious purposes. An initial entropy source that seeds a CSPRNG might be weak or
broken as well, which can also lead to critical and systemic security problems.
This document describes a way for security protocol implementations to augment
their CSPRNGs using long-term private keys. This improves randomness from broken
or otherwise subverted CSPRNGs.</t>
<t>This document is a product of the Crypto Forum Research Group (
CFRG) in the IRTF.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8937"/>
<seriesInfo name="DOI" value="10.17487/RFC8937"/>
</reference>
<reference anchor="RFC9258">
<front>
<title>Importing External Pre-Shared Keys (PSKs) for TLS 1.3</title>
<author fullname="D. Benjamin" initials="D." surname="Benjamin"/>
<author fullname="C. A. Wood" initials="C. A." surname="Wood"/>
<date month="July" year="2022"/>
<abstract>
<t>This document describes an interface for importing external Pre
-Shared Keys (PSKs) into TLS 1.3.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9258"/>
<seriesInfo name="DOI" value="10.17487/RFC9258"/>
</reference>
<reference anchor="RFC8492">
<front>
<title>Secure Password Ciphersuites for Transport Layer Security (TL
S)</title>
<author fullname="D. Harkins" initials="D." role="editor" surname="H
arkins"/>
<date month="February" year="2019"/>
<abstract>
<t>This memo defines several new ciphersuites for the Transport La
yer Security (TLS) protocol to support certificateless, secure authentication us
ing only a simple, low-entropy password. The exchange is called "TLS-PWD". The c
iphersuites are all based on an authentication and key exchange protocol, named
"dragonfly", that is resistant to offline dictionary attacks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8492"/>
<seriesInfo name="DOI" value="10.17487/RFC8492"/>
</reference>
<reference anchor="RFC7542">
<front>
<title>The Network Access Identifier</title>
<author fullname="A. DeKok" initials="A." surname="DeKok"/>
<date month="May" year="2015"/>
<abstract>
<t>In order to provide inter-domain authentication services, it is
necessary to have a standardized method that domains can use to identify each o
ther's users. This document defines the syntax for the Network Access Identifier
(NAI), the user identifier submitted by the client prior to accessing resources
. This document is a revised version of RFC 4282. It addresses issues with inter
national character sets and makes a number of other corrections to RFC 4282.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7542"/>
<seriesInfo name="DOI" value="10.17487/RFC7542"/>
</reference>
<reference anchor="RFC5489">
<front>
<title>ECDHE_PSK Cipher Suites for Transport Layer Security (TLS)</t
itle>
<author fullname="M. Badra" initials="M." surname="Badra"/>
<author fullname="I. Hajjeh" initials="I." surname="Hajjeh"/>
<date month="March" year="2009"/>
<abstract>
<t>This document extends RFC 4279, RFC 4492, and RFC 4785 and spec
ifies a set of cipher suites that use a pre-shared key (PSK) to authenticate an
Elliptic Curve Diffie-Hellman exchange with Ephemeral keys (ECDHE). These cipher
suites provide Perfect Forward Secrecy (PFS). This memo provides information fo
r the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5489"/>
<seriesInfo name="DOI" value="10.17487/RFC5489"/>
</reference>
<reference anchor="RFC8442">
<front>
<title>ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2
and DTLS 1.2</title>
<author fullname="J. Mattsson" initials="J." surname="Mattsson"/>
<author fullname="D. Migault" initials="D." surname="Migault"/>
<date month="September" year="2018"/>
<abstract>
<t>This document defines several new cipher suites for version 1.2
of the Transport Layer Security (TLS) protocol and version 1.2 of the Datagram
Transport Layer Security (DTLS) protocol. These cipher suites are based on the E
phemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key excha
nge together with the Authenticated Encryption with Associated Data (AEAD) algor
ithms AES-GCM and AES-CCM. PSK provides light and efficient authentication, ECDH
E provides forward secrecy, and AES-GCM and AES-CCM provide encryption and integ
rity protection.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8442"/>
<seriesInfo name="DOI" value="10.17487/RFC8442"/>
</reference>
</references> </references>
</references> </references>
<section anchor="acknowledgments" numbered="false">
<name>Acknowledgments</name>
<t>Thanks to the many reviewers in the RADEXT Working Group for positive
feedback.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIADP/j2cAA+1963IcyXXm/36KWkysTSi6QQK809JIEEF66OGQMAnu2OHw
KrK7sxslVFe16gJMS8t9ln2WfbI918yT2dWYkcOK/WOFZRFAVVbmyZPn+p2T
s9ls0pd95V8VH7e+dX3Z1K4qXjd1Vy7l565YNW3x6fzi3ZfPhauXxdX7z7PL
z99P3Hze+ttXY39aNovabWDUZetW/az0/WrWuqX/qZ/1VTfbdjez07PJpOvh
pT+4qqnh0b4d/KTctvSvrj979Ojlo7OJa717Vbyre9/Wvp/crel7b/7lqvix
aW/Kel38Y9sM28nNXXxqdoFfnSxc/6qYL7aTbphvyq6DtVzttvCld2+u3k4m
2/JVAf/5pli4uhg6X7i2dbviQbkqXFUVO98dF7Dwa9ddF9e+9ZOi6JvFK/wD
/LNr2r71q+4VDbH0KzdUfQdP6N93G/4z/jhxQ3/dtK8mk1lR1vDL85Piwn/f
3MCDTKfzCiahv2raNS7m5vdtuVz74oPv72CtOKrfuLJ6BfNz9cnS3zQ3vyvr
mzk9dlI2k0ndtBvYtFv/Ch7+9Pb1s2enT+Sfzx8/eyT/PHvx7Kn888nZ85fy
zxenz/XZF2fhgZdnT5/rPx+fwW8nZb3KvvL00fPn8YOP9YNPX+ggL548eab/
fPn4eRz6BYx36+uBRlrjRur2ws+8Vmab3yELnQBh8Lmyvx7m+pfZ3fphylon
8ABQejYr3LzrW7eAn66uy64Arhw2vu6LbdvcAn93RbnZVh5/RZxOLNyYc7DY
PwdDhzwnfF7cwVSE/x/C74oHQvNjGkr+cKF/wS04PimKq2tfbId22wDTNaui
hx/D1ErioWtfbYtu0zQwPP7ZTgpWBLOi+a7aZkN/H+JI8tEvF5c4UJzbCZNk
Uy6XlZ9MvsHT0jbLYYEjIYFgTnCcy2boim7rF+WqXMi6j67wk1vg+OK92/m2
+OwXQ1v2cFhg4OPiTb1od1ueURAVR0Xxl78IOb5+JXocXbjerVu3KQ4PeEEj
uq5wew/ZsWlopCcMDYevrP2yuG7u4P1jpDYe6TmRZclj9WEs2Hs4xk1lhoMt
+a6587e+nQIJcVd0O5BniroJHFOsh3Lp6oW/nxdoj0cZrr92fUHCCN7UwaZE
nTUcqL+SI2FPr5piUXnXVrtiWXY9DDuUHTPNrWt5N/2i9bAUHOvG7zpcpJ0c
UAn2uLsGUbuUh4+QdzYeqHgk0j39M8/4svWzz/z77z3sHVDhOLzIT9IHi7vr
cnEN8lV2hCglZDsR1vtbHQcQt8hb+bnIntoMML9NA4+lT+O5KYofr8vKy27D
lDucVbPqfV1Uvuvw2KxgPnN4Bkbmx7bDvCoXxUP4Y3nreh8In05+0yx9hZOg
YVdNVTV3HT1V+bVb7FS35rtD78HMzmF3YerTouyV573rSjksgZd82xlOaloi
qiEc/ISn5u4alkQcav5Ga4X16UnqfFt6/B1sCOrJxbWr176TfSzhY7Bt+HU9
F7yFehrLuqhFn+H3gNS4WrdctkBKHndRlTgGThg+BqeSOOembu7qKc7BCl3Y
Tj1sMN/B6ZS7clNWrjVbPVs43m/DCDRSQtoOR4sTx6PfDWVPm4uLCh/R2fNk
4TTtQJGDxKz4IC4anDdPv6NZ9/Q4jVncgZ2Bo+HUZLUw0WQID5u2AbEmZwfn
0103Q7UMlKTJO6DmnZLpAQx5W4Jwwo861DQg5FFkwHZ2/bT4N9HK/66fCjPd
ocmDrIezcjqnRleAs0MTBn6JSiFqCpjpUNPO6JPwDr+tiy62ru2RY4Q/QfYN
yEvFwsPvVzzeHCbAO1y8Dr/GrTwnw4k0w+vzY2Qy3pwO7LJb5p0ODCgelZhy
t9n4voW1BTulwe/2dx6Ye4+1wEBEoaJzxCnwoEF64SnT9xa4AVPkYXimaXdT
JAQw/FI43MmoJxnhzVI7YmYXpjkVPipJ1sGJbUA3KLdZ8uEWwCI3vOgG2Qme
X+KW9DjJt0OLv6MtHcjYZeFGx2+L9OhoRo50JSzh3/79L98g74O4+gqE/VKT
MON5+J+2IL7AMdgVyI/wQjP0LBpc0fpFA7Ovl6KitvAsTRA3pyBrHtkAJnwR
fjEFuQRsfPBV3gZ4fIJ7c8H2yjfFFR2CpmrWO5YvsCEFCI8lKKwfvny+AkVE
/1t8+Ej//vTmn7+8+/TmAv/9+bvz9+/DPybyxOfvPn55fxH/Fd98/fGHH958
uOCX4bdF8qvJ0Q/n/yp67+jj5dW7jx/O3x8xK1hlirvLzICisCX+QMk5Ae2/
aMs50/73ry//7/85fQJmzH9De/z09CXYMfwDmuHwA8pi/lpTwy7wj7DBuwkQ
DfQ9jkLi121BPFUsY0BCwAlCfjqZ/Pq3FYqP2bPffjuZTH5VvPkJnSPQOeif
Tb4FpkaZ8gB3Z62ypPWVw+niX94Jax2LBIJFuiVsRokmNRr/yBtNvSrXoC+X
JIQd8s60aILUIk6Sz7KO4SWJZIUjRp+D0488jcwCrlq363q/OcE5f/LA8GxY
/sdnfd9XcDYPUeQhI7LImYpp53n4NkyBGPKfwDON0okVN0slENnbqtmx1Th0
A4nxFqkEDyYCAHZu03QoTTabhlxP0DrBAL3zdErWdflnzycOjuQGFAaw1LJc
wSDgaCI1VwN+Ydiu0ftRCZWajyw1ULLTopJZGJ2cezGZ78IeCxBEvoUruG0q
EL+4icSe4bNiEE+L+cAWCbBmAwv601CicVXCsnACKEvZbqAZGr5C9Y0HZ+UW
no0WszdoR6P/sMHPmMcenF++A28dCAuigdUVU6cbtmT025XDdr0FYvifHE56
CgqsKm98ZgZkMhvkIcxfLQ36iSeEpm6ngvFOIhLCW8E9IEJ0wxJ4E+cE4lgf
hRF/cLVb44N9NjS+pIQD+6gUkxFobtQjrBv5S8xENUaiflPb+w51jNHauHMy
+JLtvnT9/AJyB5DrdaK+7IYaM3qR6G0nehulO2ju7pgPPmw6GOTp48j9uoCc
fSMJyXxaoYXOip/s18UNLeSPcChR95I9mqyD+ZCmvG3QMi3pWG5cvSvAPFz7
fB5XcUFqBuI+xK+rI+jQxITJtuEEbh2cosTsjmcwd1LGnKpORCQQHIwHNP+I
UCDoGiTCxpFtzf4ia+m1r8GeJz6XuaDzhc/BfwMDAHOq4YMrRN4nhcwGKeor
IsfK30WLNX/ps/yabBekZr/biqVKVgNIyWZowfJE/xQWizaGaC/yk9qhRjaV
Cc+Ct8euUDgynVpDZrFqNwJHNRsS5MwUd7AL1W7mbh0Y+ux7NVXHxDOWl56I
1stUatDTLRyC6T2TJqLgbqNkgDWyrFxUDUpLoB8wAfh1vndgOMvMWYhW4Hb0
pOJVNrGT5kiPVL111BJhPmyXaAf3JGd10nQu4VXwe4vX5yKEDnApbjg6sTC2
r2/LtqnJHEHFEZmXHDncbrcmBi08TgE+Bv/tSL/9I+9QcZFYkWRwk8cfVWyJ
cc3f87igszgIUyAnMXPPNIikM8VBSL1t8LiuyrZDEXRbera4we1ucUoUE3Zo
4eFZ4pc0PKIMBPKQ/By2C8amJu6oyClWymqrwXEL1ucu2J77Xmd+jlmS4mo0
dlEUr+mtuNb4evwd+SbMgmKcsxFIHAaOHjBwgRZMu2dN4pbAntiYE653MvnR
CwGJKskqSdGjyYOHBKezUQXDtOQgA9tDQ+fmZYXeVRqK6pnxUldiXGbJ42XL
PO+YtHQY8Hu0gm9ocz6ZWU4mn7ywhSuEfTdwFEqgOHmvRHBm7+KBP1mfTOmf
pydnmmeAfz8+FqeGQmIoGerOrXzxgKKDGHSeYmSRZvTm5PnXr8cUzEEBIwMU
87JespuKs0BbhB0uOJdgY6O3ASNjBIdE91Av2ETUuSwbT6asWgY4HAnraBaw
qA5uHUWIjOMqi0dh4In/Md/gYZ8q72goiWAE9cUuet+D8mOrgceYozW+2ZI7
R7+kvAV4bduBJDjHsKLMrxvxtyVARqdmKgKIIoL8VC+PsQjk6BgziYQjonRB
IX3bwFYsRc0QLwMrdg25MnlsUx23fYJI+Ih2CD+FP2OMEwNbGXeckDAEY26B
wq6u+RTxUZXvB7YjfwSjAgu/FG/bzCcc2JPiY+1lx/h0SBSSDI+7xmwWsXhx
XpM7PvIKfGteLq2ZhMsKSyDdSapWVjuZEOtiZgRj5sslqo4DXFg8+P7i7bHy
B0YOwNANige/JcFwGHcqFInsrn4ZSEAxaZZ6BIjdNEouc1X/Dn6/oDCBhj3x
2OGxAbl/9fHtF+B8NOzLbsMxkHiYpnwcVLS9Qm/u5OSkUL8YVxpeVjsKlhSC
rkQC+BoZUN54sx0yf1kvqmGpzN+jbdcXQKCpUiFfkWh6EG3bGFvvYVzQQK0c
PF93GAwe6vJPA2ierjvhY65U2JW+WnJQtCejFoYsSZGzrKWYB/w+xr/nzcDR
ImfmSDPR+QmdHMWigXw4mgS2my4GUcPensnbZRPPxknwUxzu9x0OeEenlRKE
uOnEzHNPch7tqYpPHnnn4kMjMzVxcUHTllbLnv+tjjUvwZ5edF9IxbWp7iBl
E7SHPWDK9uFNijWT7OxSXXxIY4ix9Z8sX/5aAfOfKGHQQM7sGtowNgs4+QLL
WfS6GSqQnkfKPAPZpOFJ+Wh6Hss67KE58jELBk8jxTB80Xnw1GNaLTgJwXyJ
aZdDU1cnnz6NXNGj8gTj6PFZ0Sx6z6Zf5et1f82nXkJ/+YvPnujzsDi0zth4
FxXLGjH6XKSoMRwvyg+nqaeTQiBCHlyfx1zrdmfsnS74ChKX6jDeI+koo7v1
IPBPGgg6ewqM+vjFkynO9OnpGQh2u0p46QNGk2AsZIDgLzYNSgq00cSaPBgu
wgnvwqmH/yVjlRgpUClE+HFBMjGMSuLIG45Q8xtzknxlje4SSEeHqmHUtiaS
pNbYxv1UboZNuj0ucc2QBWmaPAidIkroReYPJEJW5b2wEUsjR67L9XXYLlkU
y1HYqtsSpGGzUY9xAJkgxuncdR7YzYmX4TW8BK8DOdPQ1MbdULzfZOq2vtmy
cahWNM0mmKsj8ycilDUyBelf+P2iIQUYJif5xoRzKOrRZjt56GTFMI+TU4I2
nh6v02d7x8sSFexDPVtBJcDrWwzp971fmgjkVD04eRR+3cJvGjQiSP7Cemh8
PSAmPRcyZeEkVfmjHAUCQ7cHm1qfqofNHPNVqz3CSuS413QJCuBL3iC1iekk
uT46WsjW+wwERCAFymEGNBAQJ4EhzO21hE8k38zLlUlFKkgAjpkAfgBOcV3H
CZBUGlG8ZBmoiuIVh8LcA5CWcsBMIWG1hiILfk1+DnAv7liUctlo+nqTeYgc
ktGVuFsWfk4DoJoeIJay2erl4NXQVCloJGRYIic8AtHdYuG3MRUbQvTijfPE
2MyhoDTy6oFXXPjIzOY1CR8BR5dj08WDy/Pv3xyT5tx4ML+WoAx/S3bCyzMy
DUYPTXSIVL+wMCWfqW9at/bRnOrAuDS4DaSxnsgfJdQGlm3TwjiSJyWr26Ou
7PMAh2prxMVEbX366ORMEkqZMg1CATZrS2y8akwIsInqAQh2RKg85BuOPAAt
j4oHaPMfg1lSlYtdSJiAnUNCycQPURzPPYhmNFPh5Gb5NRZ0MWYJBojHyIZD
HqplIWQFI1ZPMs6aZyYmEZVeNdEl1lzQVA/gu0sFGqjxvxM1ZXPFfPyFMi0o
0FtX92SD2UQFRlk4MFxL8KZqmhuUCcTVzZpt5ZjHJ9Nzy5FD3EqJlOAxAH0g
cZIvISCjQZ/JxBxKibRsQWJ0PatZCmxu3Z/oRN34muKaYO92eGYZslHv8VjE
cAi3qZ4J3wKVB1QPAoBDhsvsxAM3ou+2xef4gCi2iKlJOcNwAi3KCqOVpEcd
RhrYOoFthp1BG4EiHJbUxIwUeBLHKpjgBOq4HmB+lG1zSz3r8PlON5GNsJHz
mtmBJOaCvwmko8CgMVyYbdAKcOMflRhsV1z7n4JCHtGu8mFCnR4YCUXE9585
nmdSXdGVzGQ0mZ5Bvid2bswAmrVkop0WVf98so1ybceHaUkiK36QKMlfAhbc
Vm7HOoJOw7y59TPKGjaE3zM0I83JjnDKCHjogFycXgVeKlc7Tb+ZwJ3YB9Eo
ZyVqBeA0H9nsyZ4ncRZtXnFPQh7iP6DeLfVQ2tXeL2Wokcf1iyiaOeTWeS8O
68vHz8UXo/8KBES9qROj0QnEGBUrib90/TI4PojqigxVoTOn0IPeMLYsfsrv
A83SoSnqT5FqtYox9U2hCTKPhamVsrp8xsSR0AeBmtCTSR7CmmKTy5h46nEV
mGNFfUV/1TQNgVPYMgwvKFkHkFUCZQhINkVtIT4rYDxQKy1KPLyo02n1YWnE
BmIVGq+Egz8INzMhVD35LF5FSKbIUY0w4zOSInLBReqi2x6ELrmEUbPxL2HX
/jf8Z9JsQUN0FVG4mKHTAj7A6bPJZAmncvWbh0t/+3AQ8s+735wi4qnufwOW
/v8q+Olf/Ojjs1/06AM49cthsy1mwB5///C0OPrvj85+Ovr74u/+rvCL6+aY
Jz75WBOSImweCY+9LUSNPdSa22SwHZ4u3D7MQWKCmAdA1+INhudkCJK+XXF6
9oL9gQfBuznGN2T2JDiFJRNWnIqZDdKLFZrDKCFmYlGgP4yy/fzz63fvdJeD
oCfvE+YWTFaW5biNWXSNuUk0VjcW61CxCx95z84ecYpkHaP4wowB2rkaMz06
fXakIodcb3EVb101eDkUTHUTjGZIWhe5UgglMrH1/dDWfOqArNbLouAfQQ/l
D/wmRlkjdoffpzP5mUaE5TkwkGjKKPS7ABDCA5ZblWxUvTOJKQUChmCmZLUE
xvyZs1oY1tylmS7WrxEzTvjR+BP6CNbLDU+HVCHZ27AkMz9ewz3YDYY4INPS
eCOpt5gfJUvUKkTcDRYPSK7EUcARrxtM3rRYejH5FZ6TdLllF9cQYz+4j8l8
+VVRt7/8hfFvEb6YgF4fGivp0qeBVY5aOKt+cURKpQ7xWyk1SMD/i7YBhgrR
YaGyhK5gfOJunIHI1xiPszUQiU5APjJqIWAa4aNdH+Jr3ZgZe3fdsMWFQGI/
I62WA5Apc00YCDVeZ2wmx5IDpGpKlHydKVPx9GVMgUZXI6MLHFTiYT87ZnFB
yetOZXJIcmqIvak5Vr808dNkx9K48pOT069fw/qTLOUYFWSWlH9JQT+Cg54R
DvpwcOuP6KcmQQqcOfrCKtDaEGCE9U0okcEMI0JWEqHm40jqRhMOGWKy8G1L
5lAedjWmF0Uv9+x9nGQwTPe+2dGKxc4ge4AsjQMPZ4a/njFcW19ufOAV4u6G
I6kUtybKuFDms++hMWeH0eRo1TybFeXKNCPDYZrbsqkE9sKBIKEHMwkpG5T8
yrDTsPF5PQQNzqyg2PpD09MCjrmLsXA53rihHKvhyQbTgeKmYKqyjGKvQlGn
fWOEMBnPzf6JFgiEhc4Q/2P5XeT/p8j/Kqm7EHU1r/HGoZFBXtSXq7ezF2ri
Gfd6JJv15OTs5PSUqqU030pKP6vhQZRwjamjIwlfIKqHHwVC3fheIgoScuBU
6aviSH7W1OGvT09Ozv7n6bPZ6bf/cKTWjhaDsB92MO/25OQZ0QE3MUHfMgiV
plQynwgUWvHWdEzAfQ1JE/2ZwctcYrI8IHzgo/hZZVDNDnb76JoQaCdEI4Mu
ugCUsiAk4F1xO/76HBtPx4btMOQUIB4ZX6wSU+RQaNJMIEXix1lg6acQH/T3
ssq+tZMtFz9Q4s/T1AMUcRajADY7aGdN+Ut6KpwGKRWE/STmpu2ofP4iZRI7
DhugpQ2eP5mQPjEH02iVeSdYTBKotZNAZiQtlNogCQ0IRIb53lpKeDziGwTZ
HofFzwnmhzUi+/4caqPCsAWNBUcScbjT/Q8t1KvxJXlz8eRRsM9Y83uhB9IJ
W99eu21ISqm/4bSmuDhfEJCBP7jCdNSDD+fvjiXQ/fzpkzM+ElqodYRJiKOC
gBlcaZVNSaA/AV0Nf4YB40KOnr149PLs9PTsd/LICfAhioh3K5Odx6VW6DPt
SP8b/0Jx7hif65pFSYunwPORHXCqYia4CuBbICq2pmqhep/UhI0kh9GArU1c
OK/pGaEGqgtVr6TzGDiiqQ6DMJSqQIpyiU7LdjZ4sC6pS6QIMritvyAXbs8L
7Dl6tiFvu58Dx4IK1o6pAPuRQkdyEPgsCpqGU/lqCKUfG7a4aNYAIzn4CENb
+TvVwq5i3JkIDAEIUKHHHraTXSn+Sqbo6RRmpHEMr2DRt4vwCgrEHxJO5ObD
hAj/2CaVKPYxk/InYIu+weoyQu8OyHhMzXTDeg2uA6vZiK6xBX/ESJTHj3yK
QSgsLwKR7LdMt2uNBdklUp2CFJCA9DvBYErkpHg0FYGSQ8NEzmbrluSoHnAN
fMcyJzLfVH7/PB11PIblz6tmzgkKOhRTVLoo4QJCO8naIWwLz2dvQIm1pG+0
VokQ3uvrHsh051qy21I+IBvnjqDtzMSlPQdIMqCrKKVQgidZ6PjAUCdTyx5N
/gYbobh6Orsg0Mp1rSVJ7Pv/PN1wCyZo9LLdAl4DJpBKMdo0nUSrteXhiCUr
U2afmI2PlV3Z9yTLSt/yNYa06EObgKMG64xzzmD+ExZuQg7B6DqosgCOxtcH
38Q/HEtQOAQSUhhyQFMTki4xEM/R7yAEMX+aPBUdSoHyCcsJ54OaRDkvaZA0
cEKHi9CKpyejZogCQ1x9sJCJU2qKDGMFQSlqNuCb+gAE/WTyLXz3jDGuWiiM
weUuFzOaMV3GInitne5UsdCZ4iEfn3C+1TwndM3HTa3wqX2D0ZFRN8dMPdGf
F8ffe8KYWmRTCqSzkOL4Cfq1HUhqr5UkyiCSqReq1U09Y3Ld+N0fSI3DtrFY
xQYkxoFAk0XlEeYofd9r1IR0EX710U+PHvHcnjIpmIChfs2sU0jbKdj/Ow+8
ofIqBCK0wMlj4KNcWVlORl5Ok2/R3TtBs2fnGaHVgRUJ72sR9hY8M3MMZfs1
O93Tk4ww1yJgGBT+jwfmofNJrPDQTBMx1FnbBPmYKhq/NUMB//lKsJx2sLKm
NQVjWulFdTIybMjey+RgwLOxiSHXqGxtdwnHhWCwFlXOPbsmEiMnzVuV89a1
lgTg7uqHzAMcIVXpmDL71DLfNSZx0b+07oJFIyDWs8PwPqXULcXOEorp8VrX
TXvgs2QRsgjqBKFLc8ZVdteIFpOjYIrVTqSnTS7qECpIVYZsU1Do/COpH/Ok
JOvpvGrQToLloRPLnjdLiJT6XqfISSAmK7lVqiE2jfiMgjoKYYkW/VATxoQK
OfqyYqGYcIoW+kT0suwn7BE9TZFI1G0SwVEgVS8zcuYrKQLwDk71TLRAvq6k
DCyLuyRoplE4zkiQJ8FC3GfH2+Idq3mcQZ0fRBCxlUw9LLAsRmStK1p3ly4R
/kLoFTCoMbfZIoan4UoW1tIaHUMzcoHp1IjF0S2zeTB+jO05kRIEqXXYVABb
0ggKNPEUk43GESQUSvNZ9AnR/wGHk7po/RBD8NgIopOEFSf1H7XYi/xKEq2f
//n9tHh/cX45LT69AVpT4Bt2H4+Fw5wY+iNglY19BEF1S9T4H768V8fGQjIo
QNOT109nlgp0xVoiSA29yJggYkgNp0iCwa6foBRo/JOb8+zp08dP9ZPoFaHB
E9q/jPGQGmApZblSAMFdvQUtE0MhE8DXuOtFMBCsnEYIgVZ8RM8JVqlAWNwF
TP/KWMcH5ibxDHAW3JarBiPd1T0P37UEZmZi9DmcXfgyBTpI3EpEP3kX/wer
8BMgf4iDwHdpCgTh9CDsl5S0wBFoZLJ1qQSVoKYBAADMEpIdKkyp7YI5146c
W4RWLqzsbYdKiquCiKZsVDP0FaNY0folvNkuJwFlRP/IwCyWrZ3fH5sIvHBD
qoAIj9fI76go3ehmKpYM89kfkkBImc8LE8a6u7G4W2hlRLlFI7ZUHJOZxHyE
YBY2l2xRShbgc/uOA+j2rpEwj1Wqkv2j55G03TD/o+ARcbsJqlgecCCSuUpE
hNKYqNh+QpSboNEleDL3YT+EvxjBvlf7IcxFcEXEIsfeI5RbCDj107MXSXRG
Hoj51NNHZ09shqZuQussxe4jL2fxkzJz38Jz5LkRxAS8xL6yX0JJVnF3nuwE
54QyRiraY6OoqjG9adY5DzE5G3ikwELIbpgwysHURsxWJPoNOOieDMWR1kdI
scZ49ogxOgrZmQVAR5m64qF5hwEinkx+PW+Lh9/y/2e7TQ4bx2ZuGDMiBQGZ
rz7iuJL21YCTORlJxOJdb8B4OUPyknCz8aMVZrwqzI5hm5+hDuhPhAy65R7/
8KFTgQKazOBaU9ESzZA93EM+IdQmPDaKchI7bPbWOxuSNbIp6oWVltVZtGdi
XeyFBDnKYpu2SDgAzcgARRsJtlicoeBcqYTDcVO/gHuOPQ0iYB73IwEt1rvo
uRvlb7y7wP9pWJ0ABDLlQ7ON9MHDzM0LViOKlmEIlQOGAxYXSWbG79k/JjFa
5sOrZWSGJfbkmJcOisWQlPhX+9w8jhNMvOORjoCBJUxDwPsCvziuZW85vYoC
TDo3aoySdgeH3JR/5joaHO0n9TuwQFO8GFpgrMgOyR0M2q24wg+XoLqTkkuO
8GCLUjCCRxjVwjgkni95rQDnYXFT7Y7U6cVlKhC/ReSVFFag38lxPeM6EuIz
pJqzlgg7Qjjh3GPTL4TE0rpTOqLpyRmpFHWtRyb3RDKUSOB6isAMHZJ9FPD/
NwKP3JsWyUKiQXPB7kiuZpR2XKiKhaQ6yYX0fdAIUcVfuy63NvdscCUshDNS
E5kpyKhet/hocTJd/DgR9Oc/VUqPntwVISJr8R8av/vQpDuKDSOkaZagTfbk
ClofLDWCPcV1XYex7neurfNvSpgsFAi/M36+slqCK0thXGPkN2iL9+XKI6Kl
w+Z28Ho/oMuFmdHAPmA0xHyKLULF9yt939Yy9g3HQIzxQXKaIsRvJbcQtlPS
LrB7pb/VnhshZDi7+I46eZKa1b8wZpgbU1JiTmdxWJNqZR4IKPIppayLnJ4f
tetLmti0a8WkEffG6W1xu6RSmgWsBTudKFb0krsvolGOMdk/+xZ5rZMETJIA
H03QoXkTqmLw2wSbQ92Nba01KIQN0lhZRYQqnc01VuT1yUPOyGJ8BjkfJHTZ
+dgwkuUAcvWGILoaH5ZtgB148/riuzd/wEfZBn365MVLAmBwBTm3fVrFHQa9
TX0XQYgNbYiudNxJFj/BGCdqhkvbFKdlatcNUsLVMftNRKKMFzmb4tzEEtcl
Hwrdfo4FBFQ41ceC/42RtC11RwilUHu2MaeeJNTAhW9L7QTLj8YOr5qukiPN
KSrpUmRCo3dA18pRex9NSnBEOy3QiPVZtlYlwWyIv4+2DdB7yXscGiOJnYW8
SO0EeQb6uVosSk8asmzI+AkIN8PoQcuC/CrXIWCiHUXthzlgUnl3o0RysE/U
iwht+r6pPBZHFKLcKceXNfARFCXnEkA0vR5v3CfbonCd0PAAswICL7sJPZf3
0D8mX5Q5oqFoDWz8hqKBVFYaU1Wryq1juOEIzfkdMPNDIPFRbspKkFXszO4m
dAXIhTlL8r7z1Ura74XGJPfq66Ntd/OH5bX/w40/yttNv9EyzR9QhJoMvPv5
3g7oMirU6AAc7HCBZ6yKTIBUmKMpt6gosGMwOws88OOzp8mnBV8l/TumySzS
eb4MSDht30AoFNPlsAfZMwNOjmZyCuyKtTc5Hjx5jAM1h6vUCO3yKS71KFtr
VXZ9rOx6d/7hnFnnNT/1mZ46Qs2EimA3nRTFr+y6QreEbMuBbZKSXJSs+cvc
AUUaiUxpkHRyzJ9azO7hTxvqIgYjS3neKkoTAhdyrsDKNAs51qpj7iCV957J
TqhXRCVFGTg2F+JwNp+0stG6ZclgUjpmcGw0rpkNzjYs+CQDjxcyRuOY0yvb
/kwMn9hKjTzfPbTjWPqf6CF2tOnwFU582urLYvOpNXeFdJYwq4bn9tJNJvGH
gXySxgxC8oWmBCTkGuRrbMey1PFj87l0FawtFeAr7qFxbnN0mZii3G/b9nxB
Gn04/2y76kX4dgAFjr+nLdVYrQIl9RfipuZtVaMhowIymXFMiOcpp8eYEsep
cPCdcBvBbbCDp7GO0TXd+6EnCuAvgNXA3AOnVuPj2Jwb+7/C12SZW8cYAwr7
IrfvfM/h33mLIDiOlQZkwdxXbEVLTXJo8SHYOLLPUUC0sf2MWKJTVdZjTeyC
i4HuLiJwxit8Xl/qhKVFUzrIXvVPcstBwDcm/VW1VwP3wGC9GlJVaJkrDbX0
IoI8DTa0b8vbUnpxAh9RobaxH3Vr1YbEUtikbYIpYdIiJFoMe3Qqp4yHSYZI
wrumtJ7uzEHDHCEasIOeMxHacV6e5+xQJ/0Knr54KnU72riBUXWrUAlFQj1t
4nuoXt7qR63D4PoJWwA2UkulreWnh/genqF8nkoNqgngzlbSCAwMJvjxCGlw
JMOB0QRkC/6j27tq46CJKNZ2uqLQ0Vh7hCZbeaBz5S81JmWcPYMSLH/tcsqm
3qIP5fEjtzVkFSXxaHAwiRBFEl9Iaxt4ayiLqvj6Zui5/62NKRfFBf0OdKP0
+9gi2HfL35WpBtT1dNwiHA8f/Zdt+l+26Z5t+v/LLr1KkYhM+AfdcUDZpvcR
pSJ5JONh0x0cGzJdZFH6wnvUkBfdXunHG+oZjfMnqRqJ0rUwqKO4DZq1af1j
vOUHpPVrGfJSHwkGT6n1B10QbAjcy9u2SGdXvL9MDojalmDgHEsYTe/qMNeL
PMhvojJq55iapTEcITCqgqMpitPepJW8RWJGx3qqPYpp+90lwexC+xvbZGe/
pzDCWI0BEtCZpuW2SbgKMEyQQLaNzdbHm1jEkiY3xZuicRKXe0Qeq2nM0aIB
E+nsZNk+IkcHFXwXRPJ+/50VdSINXles6sprc/q8AFgvUKNvhYKyFBCON+GA
QXlsC0DSQfBwCfaLpEJcPo4Y0WIRodaZKFpAPB6yIzldY18OE9SQiLxL+CnN
uUkbUXlFYEzYTYjKIwK25kixwGjHY7ZI4/t2F3nuiOUhZDTvmwSk9zgoRoZN
YXLESmTOEIczFcqXJSZlbvKljWslDBkqJ13xY/m21NKjS9Dk0rSi+B+XH6iq
wdccLJ4Wvsdk2kXoh6mkkdGTZnIdyqTYOvOGOIzQKX8asLxC65ioHwhVQuML
MA3sRgETm33iB6OZTwYISQb7XQLUkfwLr+or4naPiUCCT0qX9FEZyQ0fHN51
EzfUHC4tgeZpzSWyEMIOZgvv2Tcft00xfcFrFzneHRILCVI4SOzWDJWOkBao
U7wVCzriBV8/cyICkmrUHTZeSy7d7b2L9qJANt/6kvspjE8ysc5Yo6W3IQoy
S+IB5K9o66WANcbrCqXDC8Wmsc8+BTlqs6kWsBh6FYV7ClN4av6WeYwxCXRF
xgAWciUSkc3vGkMbPbWW3yd7SBdiVZBCvw8qUYUohurX5L5Jnhb1v2W8HRbC
0KIjaZDmQTDbhsJjH8u8HvLwzYUuwZ3M2VTOVOjzcOfzG0tQFYj2ZbRWsDhc
x3Ejp1fUYU+SAIhwFaEdqZD/ztRMCZKnsM089AOa2BmzZTh2hz4Nq5N2lwAS
bGWWixnFtuxuVB9nH6OrKkc+xNAeaqolt3vFxqMGuiACNIJ0FZUg2OZwtdm5
huPE+LDwem7qQhz5+vIhTKKjWAavxAQUbKILM3rALnd4/y43rSPNkBdcUgRn
bFnKwlOzmtgY09w2QR/iwQvpbE2BI91taeWbNtdPiAxs+QaXx4rkvvv0BHgd
Ijv5fR0Cmxhq7SPQtGuHsDE21tMmACyH0iciMEP7K2r3jhxPxsm3eM8giFEg
UVNTF0JZmHa208sDR4m/d40dr45SnnFQdjZaby6zO9nLDGdwEM2eZtSxK3YV
N093LZeA0gkwVzVqHWZ2AQrv1KFIRetD7XiQmfajEpTLFkdCn6Ub7499hfuc
4pmQALu99MotsZkk4qHI1zLqXc/mXnI/3XUkktF8NvrDwA12xYzZQLuPKWRR
otrKEV8Vl3hv2bGxGvGVvJk2nEUTkdWPooD1qlO939PW+YZGLkGQSb0ZrSC9
SDcNPtnAj/IFZUL4hlW98zvL4ghQisAxmnXHmxv7TmBdfR7U5H75jdjvVkZh
pzD8C9uuI+6lue0jkW0Y0EwviEwMsOSA+fgFKrS4Z8hw69qhsbPb1/YfC8IM
9RqVxc9hX1fchysooT5Gz8twmUmX3F8rKXQFtNtLV51pmRWqWCy/M+huLTV0
lHLHemZSwp2pQuJQvqmX6TnXzv3ScNoLvRbFtK4VUNwhPZjEqbhrYmg+Xra8
G4LqEDyaNhO7LN7qOMavErsk3OOW2IwhnH5wRkVjwp5ppPMqqZXn21S0RDBC
+ymF4vQe+oy1TWegLjlOUsUzYp2QzxgzB/SZAN7XwQO0LAQgjhxfLnSUWlDy
JbFqzJVcif8mMxMDO2/8a8oN6ETILUY0PobEQuPwUCAh2lyMdVvPJeUHAbG0
J3SVkdTcHN0zL5ZAooZU6cvhOkiQYNtFyKpUOqyrZo5w3LJjt1iuUyU066FB
+lKKcszVvUnvr5F2lmybWnZgAcELZLP9QOPk+LbspfRIkl7ebFsNc2EKnXSw
0NNLNbizNrdglMbFIc3ECGhr6AmkLL91BG8pxMDBth+4+UkfwymJc0DfIepN
C3OLaGRE24ePhYEFAOUhmTQSE+4FCXEy6mgRS+MJY5/3L8h2yo6oILxYTBcD
fIpg05OQ8sZ0H4NjogEk37N1wTMc66ArQFMnkTeJ2BHxQaFDY73kFcRWfSIO
edrh+soRrUltKBbRArUhxciUfGEeF1UfCEsYQCCeGcpsgWpQsiS7j9FqPjqh
dU8kNidpazxvhMCf5hCNXMTkHvrIo1onKfdh/jkUSqayVihhBrimcBnG2mOR
cVKVHpJqCmOjOgnTvpk98toKTRMl4ApbQ4LwwbRHBZopdG9C8vFwjZDZtAxC
sIudCJKQk+os6QLWsb4MtQ+mFNVGmw7tVm8KoWjTYpHxPrXGcDcjs2L0tCnk
LzUrYcLUqk4ZMhuBjfu7G1P/e7wr+kJY9RdOWK+DsGghbRKsffODKZ1uAZ0m
4hdsVCTVNXzoRw98kDHj4aDPwyIDDKV3HGJRJvlfU77wGD4FO7fL+3XGhAyF
6UYvlcK4qxpQ2KQFJI9W1FmCCqwAg9Lo8U/JrMCdVHiVOWEqIBxtgNxp5+GB
5X1vSRMXOcuMd0w5IHD7R1bc7HsyO8WentK7wLyXKTTmS1xr57mYPJFkC0nX
VW47He15lPV34pC920bU1gURUIxPMr+TEaaJ4WHj3xx5cFbajiggNOMkYuZV
IY8/yVS8C/dF2LWJo4NUCk3N6MjQptE3qpi2i9dj2WJTIUEMRI4mSPNroXOE
S7C1TO6EzR7u2DxiWOuJ1+ViF66XZyePTuC/D7GlfFucPXp0+uri9y9evXr4
+CyVRYvsekUtGKKr9hK/WDMcIWy48fkULD7HGtJAR5kdO6TCJl24HzjtoY3U
0css0u5p7EqV2icjF5e5HsHIIM8sWnd6iwitGwbe5WfPWPRMgM1mqFViISae
S4e1mY8UyFNveMO+5CppwM6eqWl+Vyc7WXgM8m4J0ngS28qFfNNYKJqCPII5
f1eHHI3iD2OXX7qCOQSi/XVJKEtffDi/KhCSfud20+yN8ba8pkOwRkisKspC
xmmvCR0xrhbzO5Qvpo7DI4aLaaChpoE2wdsbdrmXxZMYFA6eiITpXsNmpYlD
iigI1dgu1LgnfuDgJgRxIXcpSlNhqZHcNDW3cdWrSA5hMNIuqt3+RcPmbl8D
kD1PlKyYfeOmQTDHtMGJChsRoYc1T2JG7Hf6yUSHNryiAKLDzoOZzZAd4uT+
rdh8pc9tKJKJeROgqRZSGgPERPossJRtA47qmS9Sdyn71QSVcJ+V9+N478IV
EHSOKQog7z2WUHefKZTKSg7R7EXdU83RlcjhrvbN0FW77ArL8RlQSEbGC8VM
jV6LMG6/SXpZbi8afQTjnqX6fRz4G10ihtdQlDKRgn1oVCsjBYNE0FHyKKvt
yUcq+JW0pbFWtAAhjIeKUtc6zX2TvyLpKd7oxGDJJVFIz+ElpHBEZyQiGoSl
uuWM69AoTih1W9kKYhAcRr1u1hQK1Saf143UV4oyTpcwdNpo6VMs2/+L6X73
Vav89jIkNi4lCG5T+s/hz6RKLL2pPI0jxp6bEvm1IpsxeLEDl8CYdrEimlMw
MUFvb1ihiyzUYFDSkxGcXNQWYg0zzrv+3LFLmNEUbJs57zcZHKlJvC37/Wgx
Clbp1Ju2SYxKwibvOGSU9mfLminGZ9MEf4iJx0nqZfVyuUbS7TDH5HemL0eS
WNd8ejq0gZ6iDFA5qcDD4Lsn9g2qBIoURMAZ978BI7PNUA5JBxfrx5cao5ZG
LGFzHgSCiJ21+2XBp2MSQdR2ju9xdNQ1EAycLaNMQ7+Y0A/PlEcz+DvSrjuA
kpTmqKGJvAmx99giChevZsbCB8hyL65awByVyZ4hRcOtnMKWWTedbN+ki014
SXtMSh8abaGip8MCfYEppIA174rILHA/0Uxgutb2FtQpCZuxkN2aFuFzpxZB
BWSlhpkDY52HkOxIMXWxMDhYIbH3W4V6ju6yviHzeJUzyl2AmCU+QJ1CN0a2
Nj/z92wlFQuVHI2lbrHUAlW8fY7Z3iUhW6F30kKF7SKNIScB36x/7km8+7mX
oh0N+V/r99I5YgkYd2fKO+gn3uVd7OwRWr/tZUrYNKevSJBhRRaYtJGM8oBn
iM2FmRFC2yqdLTdoIaiSDJde4Vf2yvJ5+PFjm7WG04vM+2RcsWEODU7dBSkD
vdeu8r5I23lo1JPB9bGeSiX81gdXioocemT2tF8VRZ61peqDLBi/QKDxkuK1
XHlhO089e/TkxaNHEpiCd5/Dc7vuGNHqrl1S+ZO5Ezd8JbQNwNoNarU4qhQ4
Ahs3XRIkN34XvOERpIbgeMyIWNsVjY99YIbwniiq5EUpQgzgRdN1ha1ibMiC
TVbkETVYQhzULixmQ7K6GHsNA9Gbw+NLrn5jiVRSA4HVgJcjhc6b3YAYKDXi
Bc8lAUBt7bUoO5M/27il14Ht6RNHxuy26lVKKfQtF7cp1C3pRmqLy5Z8zNKw
PMMdkjyzy5YiVoZBHdp+9TKtBGc+lm2i096W6zLrmL5L0mlpp7Ux9HBsWjt5
Zz4TxH74BnJqvJGXmwwenMQxThE7ebJSrAShEseXAUZiNcfc55G/Y/X6AcZw
afM4MTX4de5/2tGtuXAGZ81qxvFk/Ukvz3199fHLcUQ73A4VehYSogVlHcF4
cvmHIFmic8UXF2634gaK43SIuVOFKc3gbAxr/3XrCIQ2G4h/SnrIofc87y2+
LjSFzi43EqAOJquSY4QttDgAGA/UHce7lgIzsBtJ42OQRFtW/NVbFjSalvA4
LKB0kr6ONNHpiLUVZxfTgR6vOhJ9ldz4ItBT/Xu2ZAqG5GseIXsApvLaIhGC
KYZ/wALjJOIRmsuf/yveGj1wj0AVD7bRdsgnpScek4koqvIZ2Uspe8l33/dm
clxTFuSQkuMGtUoEDfRoIHaaxivVAQiV79ooPBd3+eV/9NzPuBmdIAuDeRiu
WrQu7CHYcqzxNx6l5AfSCpW9bEGIiYbrp3HD1KzZbfNeJNNwuQvhUGLbdwTz
jRf1jF71JdGaEBJpQzBzGYALaeDFpBO5mSRe1dsouuG++i02Azqv6TAanOLx
vaRvIzJrJH6mV2NSxeyl3J/zuqEUN0dnuEk1AmDpggxuXMMB4PszjqbxdT4g
Ks1tCzYI3Uy9GMTgKs0lrfF6qaSZ1yIZyeAa4YOXrb8lwZ5WF6j7f+8gwbiq
JxJiplo+uhmetgebU7JnM1K3+ebkOVqvpgfWdBIIAr94Qe7cFUXIdYVyh7C/
U7M0o+bEUJO4Inp9rcOGR4r25MvfvNwToGvzy8mIssLuaGuyLW2MOK3vAEp+
ScCjBiF6h0MHgKitkERXg9NARvON05tWi6+y3MAmgM2iqbq9/pImOuRsDcLD
kM6z2SoSRd9dXV1+lii2pDA4FDP3AYuKCWRqhiC63mklCVnTScvBBE+qK2Uv
tEvikNI0EAHNZOZJqofbmVpj6fLdu2MFcO74ewxv5rBORRIgglOlvEvEHoWF
Avwk4kMssC9uyZ0AhnBUuh5+mIPnLP0VN1hmRecOZpQ0YZrGKFLswhLuuVaY
OPfj4rg/9W9Mu3gFLDubh4c6gfEh+S0fqLOvX481/iINC6nrVoTAcf1z8Iuk
Hkg6OjjT04ugswRnZdsfZg3yiOqUR2RRBFTTExm7lnUqmrCnyNvXxRvwnZr2
VVq5KonE1m+a24iXXJGW5tyhJsa/Kc4X6DxXfrmWpi6gOOqbTqPeG25kirXD
pq8obO2bf7miClqk+rpthi33Sm26koIxK/BAMPtC36AOc75q1ljvDT7vLEgC
1EyUMIPfn8Lvh+2Sb26iwwezmc1mBY4z+X+Qwnd50aoAAA==
</rfc> </rfc>
 End of changes. 63 change blocks. 
1435 lines changed or deleted 885 lines changed or added

This html diff was produced by rfcdiff 1.48.