rfc9813.original   rfc9813.txt 
RADEXT Working Group A. DeKok Internet Engineering Task Force (IETF) A. DeKok
Internet-Draft InkBridge Networks Request for Comments: 9813 InkBridge Networks
Intended status: Best Current Practice 21 January 2025 BCP: 243 June 2025
Expires: 25 July 2025 Category: Best Current Practice
ISSN: 2070-1721
Operational Considerations for RADIUS and TLS-PSK Operational Considerations for RADIUS and TLS Pre-Shared Key (TLS-PSK)
draft-ietf-radext-tls-psk-12
Abstract Abstract
This document provides implementation and operational considerations This document provides implementation and operational considerations
for using TLS-PSK with RADIUS/TLS (RFC6614) and RADIUS/DTLS for using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS/TLS (RFC 6614)
(RFC7360). The purpose of the document is to help smooth the and RADIUS/DTLS (RFC 7360). The purpose of the document is to help
operational transition from the use of the RADIUS/UDP to RADIUS/TLS. smooth the operational transition from the use of RADIUS/UDP to
RADIUS/TLS.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-radext-tls-psk/.
Discussion of this document takes place on the RADEXT Working Group
mailing list (mailto:radext@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/radext/. Subscribe at
https://www.ietf.org/mailman/listinfo/radext/.
Source for this draft and an issue tracker can be found at
https://github.com/radext-wg/radext-tls-psk.git.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This memo documents an Internet Best Current Practice.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 25 July 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9813.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
3. Justification of PSK. . . . . . . . . . . . . . . . . . . . . 4 3. Justification of PSK
4. General Discussion of PSKs and PSK Identities . . . . . . . . 5 4. General Discussion of PSKs and PSK Identities
4.1. Guidance for PSKs . . . . . . . . . . . . . . . . . . . . 5 4.1. Guidance for PSKs
4.1.1. PSK Requirements . . . . . . . . . . . . . . . . . . 5 4.1.1. PSK Requirements
4.1.2. Usability Guidance . . . . . . . . . . . . . . . . . 7 4.1.2. Usability Guidance
4.1.3. Interaction between PSKs and RADIUS Shared Secrets . 8 4.1.3. Interaction Between PSKs and RADIUS Shared Secrets
4.2. PSK Identities . . . . . . . . . . . . . . . . . . . . . 9 4.2. PSK Identities
4.2.1. Security of PSK Identities . . . . . . . . . . . . . 11 4.2.1. Security of PSK Identities
4.3. PSK and PSK Identity Sharing . . . . . . . . . . . . . . 13 4.3. PSK and PSK Identity Sharing
4.4. PSK Lifetimes . . . . . . . . . . . . . . . . . . . . . . 13 4.4. PSK Lifetimes
5. Guidance for RADIUS Clients . . . . . . . . . . . . . . . . . 14 5. Guidance for RADIUS Clients
5.1. PSK Identities . . . . . . . . . . . . . . . . . . . . . 14 5.1. PSK Identities
5.1.1. PSK Identity Requirements . . . . . . . . . . . . . . 14 5.1.1. PSK Identity Requirements
5.1.2. Usability Guidance . . . . . . . . . . . . . . . . . 15 5.1.2. Usability Guidance
6. Guidance for RADIUS Servers . . . . . . . . . . . . . . . . . 15 6. Guidance for RADIUS Servers
6.1. Current Practices . . . . . . . . . . . . . . . . . . . . 16 6.1. Current Practices
6.2. Practices for TLS-PSK . . . . . . . . . . . . . . . . . . 16 6.2. Practices for TLS-PSK
6.2.1. IP Filtering . . . . . . . . . . . . . . . . . . . . 17 6.2.1. IP Filtering
6.2.2. PSK Authentication . . . . . . . . . . . . . . . . . 19 6.2.2. PSK Authentication
6.2.3. Resumption . . . . . . . . . . . . . . . . . . . . . 20 6.2.3. Resumption
6.2.4. Interaction with other TLS authentication methods . . 21 6.2.4. Interaction with Other TLS Authentication Methods
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 7. Privacy Considerations
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 10. References
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.2. Informative References
12.1. Normative References . . . . . . . . . . . . . . . . . . 23 Acknowledgments
12.2. Informative References . . . . . . . . . . . . . . . . . 24 Author's Address
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The previous specifications "Transport Layer Security (TLS) The previous specifications "Transport Layer Security (TLS)
Encryption for RADIUS" [RFC6614] and "Datagram Transport Layer Encryption for RADIUS" [RFC6614] and "Datagram Transport Layer
Security (DTLS) as a Transport Layer for RADIUS" [RFC7360] defined Security (DTLS) as a Transport Layer for RADIUS" [RFC7360] defined
how (D)TLS can be used as a transport protocol for RADIUS. However, how (D)TLS can be used as a transport protocol for RADIUS. However,
those documents do not provide guidance for using TLS-PSK with those documents do not provide guidance for using TLS Pre-Shared Keys
RADIUS. This document provides that missing guidance, and gives (TLS-PSKs) with RADIUS. This document provides that missing
implementation and operational considerations. guidance, and gives implementation and operational considerations.
To clearly distinguish the various secrets and keys, this document To clearly distinguish the various secrets and keys, this document
uses "shared secret" to mean "RADIUS shared secret", and Pre-Shared uses "shared secret" to mean "RADIUS shared secret", and "Pre-Shared
Key (PSK) to mean secret keys which are used with TLS-PSK. Key (PSK)" to mean "secret keys that are used with TLS-PSK".
The purpose of the document is to help smooth the operational The purpose of the document is to help smooth the operational
transition from the use of the insecure RADIUS/UDP to the use of the transition from the use of the insecure RADIUS/UDP to the use of the
much more secure RADIUS/TLS. While using PSKs is often less much more secure RADIUS/TLS. While using PSKs is often less
preferable to using public / private keys, the operational model of preferable to using public or private keys, the operational model of
PSKs follows the legacy RADIUS "shared secret" model. As such, it PSKs follows the legacy RADIUS "shared secret" model. As such, it
can be easier for implementers and operators to transition to TLS can be easier for implementers and operators to transition to TLS
when that transition is offered as a series of small changes. when that transition is offered as a series of small changes.
The intent for TLS-PSK is to be used in networks where the addresses TLS-PSK is intended to be used in networks where the addresses of
of client and server are known, as with RADIUS/UDP. This situation clients and servers are known, as with RADIUS/UDP. This situation is
is similar to the use-case of RADIUS/UDP with shared secrets. TLS- similar to the use case of RADIUS/UDP with shared secrets. TLS-PSK
PSK is not suitable for situations where clients dynamically discover is not suitable for situations where clients dynamically discover
servers, as there is no way for the client to dynamically determine servers, as there is no way for the client to dynamically determine
which PSK should be used with a new server (or vice versa). In which PSK should be used with a new server (or vice versa). In
contrast, [RFC7585] dynamic discovery allows for a client or server contrast, dynamic discovery [RFC7585] allows for a client or server
to authenticate previously unknown server or client, as the parties to authenticate a previously unknown server or client, as the parties
can be issued a certificate by a known Certification Authority (CA). can be issued a certificate by a known Certification Authority (CA).
TLS-PSKs have the same issue of symmetric information between client TLS-PSKs have the same issue of symmetric information between client
and server: both parties know the secret key. A client could, in and server: both parties know the secret key. A client could, in
theory, pretend to be a server. In contrast, certificates are theory, pretend to be a server. In contrast, certificates are
asymmetric, where it is impossible for the parties to assume the asymmetric, where it is impossible for the parties to assume the
others identity. Further discussion of this topic is contained in other's identity. Further discussion of this topic is contained in
[]{#sharing}. Section 4.3.
Unless it is explicitly called out that a recommendation applies to 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 DTLS.
and DTLS.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
* External PSK External PSK
A PSK (along with a related PSK Identity) that is administratively
A PSK (along with a related PSK Identity) which is configured. That is, one that is external to TLS and is not
administratively configured. That is, one which is external to created by the TLS subsystem.
TLS, and is not created by the TLS subsystem.
* Resumption PSK
A PSK (along with a related PSK Identity) which is created by the Resumption PSK
A PSK (along with a related PSK Identity) that is created by the
TLS subsystem and/or application, for use with resumption. TLS subsystem and/or application, for use with resumption.
3. Justification of PSK. 3. Justification of PSK
TLS deployments usually rely on certificates in most common uses. TLS deployments usually rely on certificates in most common uses.
However, we recognize that it may be difficult to fully upgrade However, we recognize that it may be difficult to fully upgrade
client implementations to allow for certificates to be used with client implementations to allow for certificates to be used with
RADIUS/TLS and RADIUS/DTLS. These upgrades involve not only RADIUS/TLS and RADIUS/DTLS. These upgrades involve not only
implementing TLS, but can also require significant changes to implementing TLS, but can also require significant changes to
administration interfaces and application programming interfaces administration interfaces and application programming interfaces
(APIs) in order to fully support certificates. (APIs) in order to fully support certificates.
For example, unlike shared secrets, certificates expire. This For example, unlike shared secrets, certificates expire. This
expiration means that a working system using TLS can suddenly stop expiration means that a working system using TLS can suddenly stop
working. Managing this expiration can require additional working. Managing this expiration can require additional
notification APIs on RADIUS clients and servers which were previously notification APIs on RADIUS clients and servers that were previously
not required when shared secrets were used. not required when shared secrets were used.
Certificates also require the use of certification authorities (CAs), Certificates also require the use of certification authorities (CAs)
and chains of certificates. RADIUS implementations using TLS and chains of certificates. RADIUS implementations using TLS
therefore have to track not just a small shared secret, but also therefore have to track not just a small shared secret, but also
potentially many large certificates. The use of TLS-PSK can potentially many large certificates. The use of TLS-PSK can
therefore provide a simpler upgrade path for implementations to therefore provide a simpler upgrade path for implementations to
transition from RADIUS shared secrets to TLS. transition from RADIUS shared secrets to TLS.
In terms of ongoing maintenance, it is generally simpler to maintain In terms of ongoing maintenance, it is generally simpler to maintain
servers than clients. For one, there are many fewer servers than servers than clients. For one, there are many fewer servers than
clients. Servers are also typically less resource constrained, and clients. Servers are also typically less resource constrained, and
often run on general-purpose operating systems, where maintenance can often run on general-purpose operating systems, where maintenance can
be automated using widely-available tools. be automated using widely available tools.
In contrast, clients are often numerous, resource constrained, and In contrast, clients are often numerous, resource constrained, and
are more likely to be closed or proprietary systems with limited likely to be closed or proprietary systems with limited interfaces.
interfaces. As a result, it can be difficult to update these clients As a result, it can be difficult to update these clients when a root
when a root CA expires. The use of TLS-PSK in such an environment CA expires. The use of TLS-PSK in such an environment may therefore
may therefore offer management efficiencies. offer management efficiencies.
4. General Discussion of PSKs and PSK Identities 4. General Discussion of PSKs and PSK Identities
Before we define any RADIUS-specific use of PSKs, we must first Before we define any RADIUS-specific use of PSKs, we must first
review the current standards for PSKs, and give general advice on review the current standards for PSKs, and give general advice on
PSKs and PSK Identities. PSKs and PSK Identities.
The requirements in this section apply to both client and server The requirements in this section apply to both client and server
implementations which use TLS-PSK. Client-specific and server- implementations that use TLS-PSK. Client-specific and server-
specific issues are discussed in more detail later in this document. specific issues are discussed in more detail later in this document.
4.1. Guidance for PSKs 4.1. Guidance for PSKs
We first give requirements for creating and managing PSKs, followed We first give requirements for creating and managing PSKs, followed
by usability guidance, and then a discussion of RADIUS shared secrets by usability guidance, and then a discussion of RADIUS shared secrets
and their interaction with PSKs. and their interaction with PSKs.
4.1.1. PSK Requirements 4.1.1. PSK Requirements
Reuse of a PSK in multiple versions of TLS (e.g., TLS 1.2 and TLS Reuse of a PSK in multiple versions of TLS (e.g., TLS 1.2 and TLS
1.3) is considered unsafe ([RFC8446], Appendix E.7). Where TLS 1.3 1.3) is considered unsafe (see [RFC8446], Appendix E.7). Where TLS
binds the PSK to a particular key derivation function, TLS 1.2 does 1.3 binds the PSK to a particular key derivation function (KDF), TLS
not. This binding means that it is possible to use the same PSK in 1.2 does not. This binding means that it is possible to use the same
different hashes, leading to the potential for attacking the PSK by PSK in different hashes, leading to the potential for attacking the
comparing the hash outputs. While there are no known insecurities, PSK by comparing the hash outputs. While there are no known
these uses are not known to be secure, and should therefore be insecurities, these uses are not known to be secure, and should
avoided. For this reason, an implementation MUST NOT use the same therefore be avoided. For this reason, an implementation MUST NOT
PSK for TLS 1.3 and for earlier versions of TLS. The exact manner in use the same PSK for TLS 1.3 and for earlier versions of TLS. The
which this requirement is enforced is implementation-specific. One exact manner in which this requirement is enforced is implementation-
possibility is to have two different PSKs. Another possibility is to specific. One possibility is to have two different PSKs. Another
forbid the use of TLS versions less than TLS 1.3 possibility is to forbid the use of TLS versions less than TLS 1.3
[RFC9258] adds a key derivation function (KDF) to the import [RFC9258] adds a KDF to the import interface of (D)TLS 1.3, which
interface of (D)TLS 1.3, which binds the externally provided PSK to binds the externally provided PSK to the protocol version. That
the protocol version. That process is preferred to any TOFU process is preferred to any trust-on-first-use (TOFU) mechanism. In
mechanism. In particular, that document: particular, that document:
... describes a mechanism for importing PSKs derived from external | ... describes a mechanism for importing PSKs derived from external
PSKs by including the target KDF, (D)TLS protocol version, and an | PSKs by including the target KDF, (D)TLS protocol version, and an
optional context string to ensure uniqueness. This process yields | optional context string to ensure uniqueness. This process yields
a set of candidate PSKs, each of which are bound to a target KDF | a set of candidate PSKs, each of which are bound to a target KDF
and protocol, that are separate from those used in (D)TLS 1.2 and | and protocol, that are separate from those used in (D)TLS 1.2 and
prior versions. This expands what would normally have been a | prior versions. This expands what would normally have been a
single PSK and identity into a set of PSKs and identities. | single PSK and identity into a set of PSKs and identities.
An implementation MUST NOT use the same PSK for TLS 1.3 and for An implementation MUST NOT use the same PSK for TLS 1.3 and for
earlier versions of TLS. This requirement prevents reuse of a PSK earlier versions of TLS. This requirement prevents reuse of a PSK
with multiple TLS versions, which prevents the attacks discussed in with multiple TLS versions, which prevents the attacks discussed in
[RFC8446], Appendix E.7. The exact manner in which this requirement [RFC8446], Appendix E.7. The exact manner in which this requirement
is enforced is implementation-specific. One possibility is to have is enforced is implementation-specific. One possibility is to have
two different PSKs. Another possibility is to forbid the use of TLS two different PSKs. Another possibility is to forbid the use of TLS
versions less than TLS 1.3. versions less than TLS 1.3.
Implementations MUST follow the directions of [RFC9257], Section 6 Implementations MUST follow the directions of [RFC9257], Section 6
for the use of external PSKs in TLS. That document provides for the use of external PSKs in TLS. That document provides
extremely useful guidance on generating and using PSKs. extremely useful guidance on generating and using PSKs.
Implementations MUST support PSKs of at least 32 octets in length, Implementations MUST support PSKs of at least 32 octets in length,
and SHOULD support PSKs of 64 octets or more. As the PSKs are and SHOULD support PSKs of 64 octets or more. As the PSKs are
generally hashed before being used in TLS, the useful entropy of a generally hashed before being used in TLS, the useful entropy of a
PSK is limited by the size of the hash output. This output may be PSK is limited by the size of the hash output. This output may be
256, 384, or 512 bits in length. Nevertheless, it is good practice 256, 384, or 512 bits in length. Nevertheless, it is good practice
for implementations to allow entry of PSKs of more than 64 octets, as for implementations to allow entry of PSKs of more than 64 octets, as
the PSK may be in a form other than bare binary data. the PSK may be in a form other than bare binary data.
Implementations which limit the PSK to a maximum of 64 octets are Implementations that limit the PSK to a maximum of 64 octets are
likely to use PSKs which have much less than 512 bits of entropy. likely to use PSKs that have much less than 512 bits of entropy.
That is, a PSK with high entropy may be expanded via some construct That is, a PSK with high entropy may be expanded via some construct
(e.g., base32 as in the example below) in order to make it easier for (e.g., base32 as in the example below) in order to make it easier for
people to interact with. Where 512 bits of entropy are input to an people to interact with. Where 512 bits of entropy are input to an
encoding construct, the output may be larger than 64 octets. encoding construct, the output may be larger than 64 octets.
Implementations MUST require that PSKs be at least 16 octets in Implementations MUST require that PSKs be at least 16 octets in
length. That is, short PSKs MUST NOT be permitted to be used, and length. That is, short PSKs MUST NOT be permitted to be used, and
PSKs MUST be random. The strength of the PSK is not determined by PSKs MUST be random. The strength of the PSK is not determined by
the length of the PSK, but instead by the number of bits of entropy the length of the PSK, but instead by the number of bits of entropy
which it contains. People are not good at creating data with high that it contains. People are not good at creating data with high
entropy, so a source of cryptographically secure random numbers MUST entropy, so a source of cryptographically secure random numbers MUST
be used. be used.
Where user passwords are generally intended to be remembered and Where user passwords are generally intended to be remembered and
entered by people on a regular basis, PSKs are intended to be entered entered by people on a regular basis, PSKs are intended to be entered
once, and then automatically saved in a system configuration. As once, and then automatically saved in a system configuration. As
such, due to the limited entropy of passwords, they are not such, due to the limited entropy of passwords, they are not
acceptable for use with TLS-PSK, and would only be acceptable for use acceptable for use with TLS-PSK, and would only be acceptable for use
with a password-authenticated key exchange (PAKE) TLS method with a password-authenticated key exchange (PAKE) TLS method
[RFC8492]. Implementations MUST therefore support entry and storage [RFC8492]. Implementations MUST therefore support entry and storage
of PSKs as undistinguished octets. of PSKs as undistinguished octets.
We also incorporate by reference the requirements of [RFC7360], We also incorporate by reference the requirements of [RFC7360],
Section 10.2 when using PSKs. Section 10.2 when using PSKs.
It may be tempting for servers to implement a "trust on first use" It may be tempting for servers to implement a TOFU policy with
(TOFU) policy with respect to clients. Such behavior is NOT respect to clients. Such behavior is NOT RECOMMENDED. When servers
RECOMMENDED. When servers receive a connection from an unknown receive a connection from an unknown client, they SHOULD log the PSK
client, they SHOULD log the PSK Identity, source IP address, and any Identity, source IP address, and any other information that may be
other information which may be relevant. An administrator can then relevant. An administrator can then later look at the logs and
later look at the logs and determine the appropriate action to take. determine the appropriate action to take.
4.1.2. Usability Guidance 4.1.2. Usability Guidance
PSKs are in their purest form are opaque tokens, represented as an PSKs in their purest form are opaque tokens, represented as an
undistinguished series of octets. Where PSKs are expected to be undistinguished series of octets. Where PSKs are expected to be
managed automatically by scripted methods, this format is acceptable. managed automatically by scripted methods, this format is acceptable.
However, in some cases it is necessary for administrators to share However, in some cases it is necessary for administrators to share
PSKs, in which case humanly readable formats may be useful. PSKs, in which case human-readable formats may be useful.
Implementations SHOULD support entering PSKs as both binary data, and Implementations SHOULD support entering PSKs as both binary data and
via a humanly readable form such as hex encoding. via a human-readable form such as hex encoding.
Implementations SHOULD use a humanly readable form of PKSs for Implementations SHOULD use a human-readable form of PSKs for
interfaces which are intended to be used by people, and SHOULD allow interfaces that are intended to be used by people, and SHOULD allow
for binary data to be entered via an application programming for binary data to be entered via an application programming
interface (API). Implementations SHOULD also allow for PSKs to be interface (API). Implementations SHOULD also allow for PSKs to be
displayed in the above-mentioned hex encoding, so that administrators displayed in the hex encoding mentioned above, so that administrators
can manually verify that a particular PSK is being used. can manually verify that a particular PSK is being used.
When using PSKs, administrators SHOULD use PSKs of at least 24 When using PSKs, administrators SHOULD use PSKs of at least 24 octets
octets, generated using a source of cryptographically secure random that are generated using a source of cryptographically secure random
numbers. Implementers needing a secure random number generator numbers. Implementers needing a secure random number generator
should see [RFC8937] for for further guidance. PSKs are not should see [RFC8937] for further guidance. PSKs are not passwords,
passwords, and administrators should not try to manually create PSKs. and administrators should not try to manually create PSKs.
In order to guide implementers and administrators, we give example In order to guide implementers and administrators, we give example
commands below which generate random PSKs from a locally secure commands below that generate random PSKs from a locally secure
source. While some commands may not work on some systems one of the source. While some commands may not work on some systems, one of the
commands should succeed. The intent here is to document a concise commands should succeed. The intent here is to document a concise
and simple example of creating PSKs which are both secure, and and simple example of creating PSKs that are both secure and human-
humanly manageable. This document does not mandate that the PSKs manageable. This document does not mandate that the PSKs follow this
follow this format, or any other format. format or any other format.
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)
Only one of the above commands should be run, there is no need to run Only one of the above commands should be run; there is no need to run
all of them. Each command reads 128 bits (16 octets) of random data all of them. Each command reads 128 bits (16 octets) of random data
from a secure source, and encodes it as printable / readable ASCII. from a secure source, and encodes it as printable and readable ASCII.
This form of PSK will be accepted by any implementation which This form of PSK will be accepted by any implementation that supports
supports at least 32 octets for PSKs. Larger PSKs can be generated at least 32 octets for PSKs. Larger PSKs can be generated by
by changing the "16" number to a larger value. The above derivation changing the "16" number to a larger value. The above derivation
assumes that the random source returns one bit of entropy for every assumes that the random source returns one bit of entropy for every
bit of randomness which is returned. Sources failing that assumption bit of randomness that is returned. Sources failing that assumption
are NOT RECOMMENDED. are NOT RECOMMENDED.
4.1.3. Interaction between PSKs and RADIUS Shared Secrets 4.1.3. Interaction Between PSKs and RADIUS Shared Secrets
Any shared secret used for RADIUS/UDP or RADIUS/TLS MUST NOT be used Any shared secret used for RADIUS/UDP or RADIUS/TLS MUST NOT be used
for TLS-PSK. for TLS-PSK.
It is RECOMMENDED that RADIUS clients and servers track all used It is RECOMMENDED that RADIUS clients and servers track all used
shared secrets and PSKs, and then verify that the following shared secrets and PSKs, and then verify that the following
requirements all hold true: requirements all hold true:
* no shared secret is used for more than one RADIUS client * no shared secret is used for more than one RADIUS client
* no PSK is used for more than one RADIUS client * no PSK is used for more than one RADIUS client
* no shared secret is used as a PSK * no shared secret is used as a PSK
Note that the shared secret of "radsec" given in [RFC6614] can be Note that the shared secret of "radsec" given in [RFC6614] can be
used across multiple clients, as that value is mandated by the used across multiple clients, as that value is mandated by the
specification. The intention here is to recommend best practices for specification. The intention here is to recommend best practices for
administrators who enter site-local shared secrets. administrators who enter site-local shared secrets.
There may be use-cases for using one shared secret across multiple There may be use cases for using one shared secret across multiple
RADIUS clients. There may similarly be use-cases for sharing a PSK RADIUS clients. There may similarly be use cases for sharing a PSK
across multiple RADIUS clients. Details of the possible attacks on across multiple RADIUS clients. Details of the possible attacks on
reused PSKs are given in [RFC9257], Section 4.1. reused PSKs are given in [RFC9257], Section 4.1.
There are no known use-cases for using a PSK as a shared secret, or There are no known use cases for using a PSK as a shared secret, or
vice-versa. vice versa.
Implementations MUST reject configuration attempts that try to use Implementations MUST reject configuration attempts that try to use
the same value for PSK and shared secret. To prevent administrative the same value for the PSK and shared secret. To prevent
errors, implementations should not have interfaces which confuse PSKs administrative errors, implementations should not have interfaces
and shared secrets, or which allow both PSKs and shared secrets to be that confuse PSKs and shared secrets or that allow both PSKs and
entered at the same time. There is too much of a temptation for shared secrets to be entered at the same time. There is too much of
administrators to enter the same value in both fields, which would a temptation for administrators to enter the same value in both
violate the limitations given above. Similarly, using a "shared fields, which would violate the limitations given above. Similarly,
secret" field as a way for administrators to enter PSKs is bad using a "shared secret" field as a way for administrators to enter
practice. The PSK entry fields need to be labeled as being related PSKs is bad practice. The PSK entry fields need to be labeled as
to PSKs, and not to shared secrets. being related to PSKs, and not to shared secrets.
4.2. PSK Identities 4.2. PSK Identities
[RFC4279], Section 5.1 requires that PSK Identities be encoded in [RFC4279], Section 5.1 requires that PSK Identities be encoded in
UTF-8 format. However, [RFC8446], Section 4.2.11 describes the "Pre- UTF-8 format. However, [RFC8446], Section 4.2.11 describes the "Pre-
Shared Key Extension" and defines the ticket as an opaque string: Shared Key Extension" and defines the ticket as an opaque string:
"opaque identity<1..2^16-1>;". This PSK is then used in [RFC8446], "opaque identity<1..2^16-1>;". This PSK is then used in [RFC8446],
Section 4.6.1 for resumption. Section 4.6.1 for resumption.
These definitions appear to be in conflict. This conflict is These definitions appear to be in conflict. This conflict is
skipping to change at page 10, line 14 skipping to change at line 389
Note that the PSK Identity is sent in the clear, and is therefore Note that the PSK Identity is sent in the clear, and is therefore
visible to attackers. Where privacy is desired, the PSK Identity visible to attackers. Where privacy is desired, the PSK Identity
could be either an opaque token generated cryptographically, or could be either an opaque token generated cryptographically, or
perhaps in the form of a Network Access Identifier (NAI) [RFC7542], perhaps in the form of a Network Access Identifier (NAI) [RFC7542],
where the "user" portion is an opaque token. For example, an NAI where the "user" portion is an opaque token. For example, an NAI
could be "68092112@example.com". If the attacker already knows that could be "68092112@example.com". If the attacker already knows that
the client is associated with "example.com", then using that domain the client is associated with "example.com", then using that domain
name in the PSK Identity offers no additional information. In name in the PSK Identity offers no additional information. In
contrast, the "user" portion needs to be both unique to the client contrast, the "user" portion needs to be both unique to the client
and private, so using an opaque token there is a more secure and private, so using an opaque token is a more secure approach.
approach.
Implementations MUST support PSK Identities of 128 octets, and SHOULD Implementations MUST support PSK Identities of 128 octets, and SHOULD
support longer PSK Identities. We note that while TLS provides for support longer PSK Identities. We note that while TLS provides for
PSK Identities of up to 2^16-1 octets in length, there are few PSK Identities of up to 2^16-1 octets in length, there are few
practical uses for extremely long PSK Identities. practical uses for extremely long PSK Identities.
It is up to administrators and implementations as to how they It is up to administrators and implementations as to how they
differentiate external PSK Identities from session resumption PSK differentiate external PSK Identities from session resumption PSK
Identities used in TLS 1.3 session tickets. While [RFC9257], Identities used in TLS 1.3 session tickets. While [RFC9257],
Section 6.1.2 suggests the identities should be unique, it offers no Section 6.1.2 suggests the identities should be unique, it offers no
concrete steps for how this differentiation may be done. concrete steps for how this differentiation may be done.
One approach could be to have externally provisioned PSK Identities One approach could be to have externally provisioned PSK Identities
contain an NAI such as described above, while session resumption PSK contain an NAI such as what is described above, while session
Identities contain large blobs of opaque, encrypted, and resumption PSK Identities contain large blobs of opaque, encrypted,
authenticated text. It should then be relatively straightforward to and authenticated text. It should then be relatively straightforward
differentiate the two types of identities. One is UTF-8, the other to differentiate the two types of identities. One is UTF-8, the
is not. One is unauthenticated, the other is authenticated. other is not. One is unauthenticated, the other is authenticated.
Servers MUST assign and/or track session resumption PSK Identities in Servers MUST assign and/or track session resumption PSK Identities in
a way which facilities the ability to distinguish those identities a way that facilities the ability to distinguish those identities
from externally configured PSK Identities, and which enables them to from externally configured PSK Identities, and that enables them to
both find and validate the session resumption PSK. See both find and validate the session resumption PSK. See Section 6.2.3
{}(#resumption) below for more discussion of issues around below for more discussion of issues around resumption.
resumption.
A sample validation flow for TLS-PSK Identities could be performed A sample validation flow for TLS-PSK Identities could be performed
via the following steps: via the following steps:
1. PSK Identities provided via an administration interface are 1. PSK Identities provided via an administration interface are
enforced to be only UTF-8 on both client and server. enforced to be only UTF-8 on both client and server.
2. The client treats session tickets received from the server as 2. The client treats session tickets received from the server as
opaque blobs. opaque blobs.
3. When the server issues session tickets for resumption, the 3. When the server issues session tickets for resumption, the server
server ensures that they are not valid UTF-8. ensures that they are not valid UTF-8.
4. One way to do this is to use stateless resumption with a 4. One way to do this is to use stateless resumption with a forced
forced non-UTF-8 key_name per [RFC5077], Section 4, such as by non-UTF-8 key_name per [RFC5077], Section 4, such as by setting
setting one octet to 0x00. one octet to 0x00.
5 When receiving TLS, the server receives Client-Hello containing 5. When receiving TLS, the server receives a Client-Hello containing
a PSK, and checks if the identity is valid UTF-8. a PSK, and checks if the identity is valid UTF-8:
5.1. If yes, it searches for a pre-configured client which 5.1. If yes, it searches for a preconfigured client that matches
matches that identity. that identity.
5.1.1. If the identity is found, authenticates the client 5.1.1. If the identity is found, it authenticates the
via PSK. client via PSK.
5.1.2. else the identity is invalid, and the server closes 5.1.2. Else, the identity is invalid, and the server
the connection. closes the connection.
5.2 If the identity is not UTF-8, try resumption, which is 5.2. If not, try resumption, which is usually handled by a TLS
usually be handled by a TLS library. library.
5.2.1 If the TLS library verifies the session ticket, 5.2.1. If the TLS library verifies the session ticket,
resumption has happened, and the connection is established. then resumption has happened, and the connection is
established.
5.2.2. else the server ignores the session ticket, and 5.2.2. Else, the server ignores the session ticket, and
performs normal TLS handshake with a certificate. performs a normal TLS handshake with a certificate.
This validation flow is only suggested. Other validation methods are This validation flow is only suggested. Other validation methods are
possible. possible.
4.2.1. Security of PSK Identities 4.2.1. Security of PSK Identities
We note that the PSK Identity is a field created by the connecting We note that the PSK Identity is a field created by the connecting
client. Since the client is untrusted until both the identity and client. Since the client is untrusted until both the identity and
PSK have been verified, both of those fields MUST be treated as PSK have been verified, both of those fields MUST be treated as
untrusted. That is, a well-formed PSK Identity is likely to be in untrusted. That is, a well-formed PSK Identity is likely to be in
UTF-8 format, due to the requirements of [RFC4279], Section 5.1. UTF-8 format, due to the requirements of [RFC4279], Section 5.1.
However, implementations MUST support managing PSK Identities as a However, implementations MUST support managing PSK Identities as a
set of undistinguished octets. set of undistinguished octets.
It is not safe to use a raw PSK Identity to look up a corresponding It is not safe to use a raw PSK Identity to look up a corresponding
PSK. The PSK may come from an untrusted source, and may contain PSK. The PSK may come from an untrusted source and may contain
invalid or malicious data. For example, the identity may have invalid or malicious data. For example, the identity may have
incorrect UTF-8 format; or it may contain data which forms an incorrect UTF-8 format; or it may contain data that forms an
injection attack for SQL, LDAP, REST or shell meta characters; or it injection attack for SQL, Lightweight Directory Access Protocol
may contain embedded NUL octets which are incompatible with APIs (LDAP), Representational State Transfer (REST), or shell meta
which expect NUL terminated strings. The identity may also be up to characters; or it may contain embedded NUL octets that are
65535 octets long. incompatible with APIs that expect NUL terminated strings. The
identity may also be up to 65535 octets long.
As such, implementations MUST validate the identity prior to it being As such, implementations MUST validate the identity prior to it being
used as a lookup key. When the identity is passed to an external API used as a lookup key. When the identity is passed to an external API
(e.g., database lookup), implementations MUST either escape any (e.g., database lookup), implementations MUST either escape any
characters in the identity which are invalid for that API, or else characters in the identity that are invalid for that API, or else
reject the identity entirely. The exact form of any escaping depends reject the identity entirely. The exact form of any escaping depends
on the API, and we cannot document all possible methods here. on the API, and we cannot document all possible methods here.
However, a few basic validation rules are suggested, as outlined However, a few basic validation rules are suggested, as outlined
below. Any identity which is rejected by these validation rules MUST below. Any identity that is rejected by these validation rules MUST
cause the server to close the TLS connection. cause the server to close the TLS connection.
The suggested validation rules for identities used outside of The suggested validation rules for identities used outside of
resumption are as follows: resumption are as follows:
* Identities MUST be checked to see if they have been provisioned as * Identities MUST be checked to see if they have been provisioned as
a resumption PSK. If so, then the session can be resumed, subject a resumption PSK. If so, then the session can be resumed, subject
to any policies around resumption. to any policies around resumption.
* Identities longer than a fixed maximum SHOULD be rejected. The * Identities longer than a fixed maximum SHOULD be rejected. The
limit is implementation dependent, but SHOULD NOT be less than limit is implementation dependent, but SHOULD NOT be less than
128, and SHOULD NOT be more than 1024. There is no purpose to 128, and SHOULD NOT be more than 1024. There is no purpose to
allowing extremely long identities, and allowing them does little allowing extremely long identities, and allowing them does little
more than complicate implementations. more than complicate implementations.
* Identities configured by administrators SHOULD be in UTF-8 format, * Identities configured by administrators SHOULD be in UTF-8 format,
and SHOULD be in the [RFC7542] NAI format. While [RFC8446], and SHOULD be in the NAI format from [RFC7542]. While [RFC8446],
Section 4.2.11 defines the PSK Identity as "opaque Section 4.2.11 defines the PSK Identity as "opaque
identity<1..2^16-1>", it is useful for administrators to manage identity<1..2^16-1>", it is useful for administrators to manage
humanly-readable identities in a recognizable format. human-readable identities in a recognizable format.
This suggestion makes it easier to distinguish TLS-PSK Identities This suggestion makes it easier to distinguish TLS-PSK Identities
from TLS 1.3 resumption identities. It also allows from TLS 1.3 resumption identities. It also allows
implementations to more easily filter out unexpected or bad implementations to more easily filter out unexpected or bad
identities, and then to close inappropriate TLS connections. identities, and then to close inappropriate TLS connections.
It is RECOMMENDED that implementations extend these rules with any It is RECOMMENDED that implementations extend these rules with any
additional validation which are found to be useful. For example, additional validation that is found to be useful. For example,
implementations and/or deployments could both generate PSK Identities implementations and/or deployments could both generate PSK Identities
in a particular format for passing to client systems, and then also in a particular format for passing to client systems, and then also
verify that any received identity matches that format. For example, verify that any received identity matches that format. For example,
a site could generate PSK Identities which are composed of characters a site could generate PSK Identities that are composed of characters
in the local language. The site could then reject identities which in the local language. The site could then reject identities that
contain characters from other languages, even if those characters are contain characters from other languages, even if those characters are
valid UTF-8. valid UTF-8.
The purpose of these rules is to help administrators and implementers The purpose of these rules is to help administrators and implementers
more easily manage systems using TLS-PSK, while also minimizing more easily manage systems using TLS-PSK, while also minimizing
complexity and protecting from potential attackers traffic. The complexity and protecting from potential attackers' traffic. The
rules follow a principle of "discard bad traffic quickly", which rules follow a principle of "discard bad traffic quickly", which
helps to improve system stability and performance. helps to improve system stability and performance.
4.3. PSK and PSK Identity Sharing 4.3. PSK and PSK Identity Sharing
While administrators may desire to share PSKs and/or PSK Identities While administrators may desire to share PSKs and/or PSK Identities
across multiple systems, such usage is NOT RECOMMENDED. Details of across multiple systems, such usage is NOT RECOMMENDED. Details of
the possible attacks on reused PSKs are given in [RFC9257], the possible attacks on reused PSKs are given in [RFC9257],
Section 4.1. Section 4.1.
Implementations MUST support the ability to configure a unique PSK Implementations MUST support the ability to configure a unique PSK
and PSK Identity for each possible client-server relationship. This and PSK Identity for each possible client-server relationship. This
configuration allows administrators desiring security to use unique configuration allows administrators desiring security to use unique
PSKs for each such relationship. This configuration is also PSKs for each such relationship. This configuration is also
compatible with the practice of administrators who wish to re-use compatible with the practice of administrators who wish to reuse PSKs
PSKs and PSK Identities where local policies permit. and PSK Identities where local policies permit.
Implementations SHOULD warn administrators if the same PSK Identity Implementations SHOULD warn administrators if the same PSK Identity
and/or PSK is used for multiple client-server relationships. and/or PSK is used for multiple client-server relationships.
4.4. PSK Lifetimes 4.4. PSK Lifetimes
Unfortunately, [RFC9257] offers no guidance on PSK lifetimes other Unfortunately, [RFC9257] offers no guidance on PSK lifetimes other
than to note Section 4.2 that: than to note in Section 4.2 that:
Forward security may be achieved by using a PSK-DH mode or by | Forward security may be achieved by using a PSK-DH mode or by
using PSKs with short lifetimes. | using PSKs with short lifetimes.
It is RECOMMENDED that PSKs be rotated regularly. We offer no It is RECOMMENDED that PSKs be rotated regularly. We offer no
additional guidance on how often this process should occur. Changing additional guidance on how often this process should occur. Changing
PSKs has a non-zero cost. It is therefore up to administrators to PSKs has a non-zero cost. It is therefore up to administrators to
determine how best to balance the cost of changing the PSK against determine how best to balance the cost of changing the PSK against
the cost of a potential PSK compromise. the cost of a potential PSK compromise.
TLS-PSK MUST use modes such as PSK-DH or ECDHE_PSK [RFC5489] which TLS-PSK MUST use modes such as PSK-DH or ECDHE_PSK [RFC5489] that
provide forward secrecy. Failure to use such modes would mean that provide forward secrecy. Failure to use such modes would mean that
compromise of a PSK would allow an attacker to decrypt all sessions compromise of a PSK would allow an attacker to decrypt all sessions
which had used that PSK. that had used that PSK.
As the PSKs are looked up by identity, the PSK Identity MUST also be As the PSKs are looked up by identity, the PSK Identity MUST also be
changed when the PSK changes. changed when the PSK changes.
Servers SHOULD track when a connection was last received for a Servers SHOULD track when a connection was last received for a
particular PSK Identity, and SHOULD automatically invalidate particular PSK Identity, and SHOULD automatically invalidate
credentials when a client has not connected for an extended period of credentials when a client has not connected for an extended period of
time. This process helps to mitigate the issue of credentials being time. This process helps to mitigate the issue of credentials being
leaked when a device is stolen or discarded. leaked when a device is stolen or discarded.
5. Guidance for RADIUS Clients 5. Guidance for RADIUS Clients
Client implementations MUST allow the use of a pre-shared key (PSK) Client implementations MUST allow the use of a pre-shared key (PSK)
for RADIUS/TLS. The client implementation can then expose a user for RADIUS/TLS. The client implementation can then expose a user
interface flag which is "TLS yes / no", and then also fields which interface flag which is "TLS yes / no", and then also fields that ask
ask for the PSK Identity and PSK itself. for the PSK Identity and PSK itself.
For TLS 1.3, Implementations MUST support "psk_dhe_ke" Pre-Shared Key For TLS 1.3, implementations MUST support the "psk_dhe_ke" Pre-Shared
Exchange Mode in TLS 1.3 as discussed in [RFC8446], Section 4.2.9 and Key Exchange Mode in TLS 1.3 as discussed in [RFC8446], Section 4.2.9
in [RFC9257], Section 6. Implementations MUST implement the and in [RFC9257], Section 6. Implementations MUST implement the
recommended cipher suites in [RFC9325], Section 4.2 for TLS 1.2, and recommended cipher suites in [RFC9325], Section 4.2 for TLS 1.2 and
in [RFC8446], Section 9.1 for TLS 1.3. In order to future-proof in [RFC8446], Section 9.1 for TLS 1.3. In order to future-proof
these recommendations, we give the following recommendations: these recommendations, we give the following recommendations.
* Implementations SHOULD use the "Recommended" cipher suites listed * Implementations SHOULD use the "Recommended" cipher suites listed
in the IANA "TLS Cipher Suites" registry, in the IANA "TLS Cipher Suites" registry:
- for TLS 1.3, the use "psk_dhe_ke" PSK key exchange mode, - For TLS 1.3, use the "psk_dhe_ke" PSK key exchange mode.
- for TLS 1.2 and earlier, use cipher suites which require - For TLS 1.2 and earlier, use cipher suites that require
ephemeral keying. ephemeral keying.
If a client initiated a connection using a PSK with TLS 1.3 by If a client initiated a connection using a PSK with TLS 1.3 by
including the pre-shared key extension, it MUST close the connection including the pre-shared key extension, it MUST close the connection
if the server did not also select the pre-shared key to continue the if the server did not also select the pre-shared key to continue the
handshake. handshake.
5.1. PSK Identities 5.1. PSK Identities
This section offers advice on both requirements for PSK Identities, This section offers advice on both requirements for PSK Identities
and on usability. and on usability.
5.1.1. PSK Identity Requirements 5.1.1. PSK Identity Requirements
[RFC6614] is silent on the subject of PSK Identities, which is an [RFC6614] is silent on the subject of PSK Identities, which is an
issue that we correct here. Guidance is required on the use of PSK issue that we correct here. Guidance is required on the use of PSK
Identities, as the need to manage identities associated with PSK is a Identities, as the need to manage identities associated with PSKs is
new requirement for NAS management interfaces, and is a new a new requirement for both Network Access Server (NAS) management
requirement for RADIUS servers. interfaces and RADIUS servers.
RADIUS systems implementing TLS-PSK MUST support identities as per RADIUS systems implementing TLS-PSK MUST support identities as per
[RFC4279], Section 5.3, and MUST enable configuring TLS-PSK [RFC4279], Section 5.3 and MUST enable configuring TLS-PSK Identities
Identities in management interfaces as per [RFC4279], Section 5.4. in management interfaces as per [RFC4279], Section 5.4.
The historic methods of signing RADIUS packets have not yet been The historic methods of signing RADIUS packets have not yet been
broken, but they are believed to be much less secure than modern TLS. broken, but they are believed to be much less secure than modern TLS.
Therefore, when a RADIUS shared secret is used to sign RADIUS/UDP or Therefore, when a RADIUS shared secret is used to sign RADIUS/UDP or
RADIUS/TCP packets, that shared secret MUST NOT be used with TLS-PSK. RADIUS/TCP packets, that shared secret MUST NOT be used with TLS-PSK.
If the secrets were to be reused, then an attack on historic RADIUS If the secrets were to be reused, then an attack on historic RADIUS
cryptography could be trivially leveraged to decrypt TLS-PSK cryptography could be trivially leveraged to decrypt TLS-PSK
sessions. sessions.
With TLS-PSK, RADIUS/TLS clients MUST permit the configuration of a With TLS-PSK, RADIUS/TLS clients MUST permit the configuration of a
skipping to change at page 15, line 32 skipping to change at line 638
In order to prevent confusion between shared secrets and TLS-PSKs, In order to prevent confusion between shared secrets and TLS-PSKs,
management interfaces and APIs need to label PSK fields as "PSK" or management interfaces and APIs need to label PSK fields as "PSK" or
"TLS-PSK", rather than as "shared secret". "TLS-PSK", rather than as "shared secret".
6. Guidance for RADIUS Servers 6. Guidance for RADIUS Servers
In order to support clients with TLS-PSK, server implementations MUST In order to support clients with TLS-PSK, server implementations MUST
allow the use of a pre-shared key (TLS-PSK) for RADIUS/TLS. allow the use of a pre-shared key (TLS-PSK) for RADIUS/TLS.
Systems which act as both client and server at the same time MUST NOT Systems that act as both client and server at the same time MUST NOT
share or reuse PSK Identities between incoming and outgoing share or reuse PSK Identities between incoming and outgoing
connections. Doing so would open up the systems to attack, as connections. Doing so would open up the systems to attack, as
discussed in [RFC9257], Section 4.1. discussed in [RFC9257], Section 4.1.
For TLS 1.3, Implementations MUST support "psk_dhe_ke" Pre-Shared Key For TLS 1.3, implementations MUST support the "psk_dhe_ke" Pre-Shared
Exchange Mode in TLS 1.3 as discussed in [RFC8446], Section 4.2.9 and Key Exchange Mode in TLS 1.3 as discussed in [RFC8446], Section 4.2.9
in [RFC9257], Section 6. Implementations MUST implement the and in [RFC9257], Section 6. Implementations MUST implement the
recommended cipher suites in [RFC9325], Section 4.2 for TLS 1.2, and recommended cipher suites in [RFC9325], Section 4.2 for TLS 1.2 and
in [RFC8446], Section 9.1 for TLS 1.3. In order to future-proof in [RFC8446], Section 9.1 for TLS 1.3. In order to future-proof
these recommendations, we give the following recommendations: these recommendations, we give the following recommendations.
* Implementations SHOULD use the "Recommended" cipher suites listed * Implementations SHOULD use the "Recommended" cipher suites listed
in the IANA "TLS Cipher Suites" registry, in the IANA "TLS Cipher Suites" registry:
- for TLS 1.3, use "psk_dhe_ke" PSK key exchange mode, - For TLS 1.3, use the "psk_dhe_ke" PSK key exchange mode.
- for TLS 1.2 and earlier, use cipher suites which require - For TLS 1.2 and earlier, use cipher suites that require
ephemeral keying. ephemeral keying.
The following section(s) describe guidance for RADIUS server The following section(s) describe guidance for RADIUS server
implementations and deployments. We first give an overview of implementations and deployments. We first give an overview of
current practices, and then extend and/or replace those practices for current practices, and then extend and/or replace those practices for
TLS-PSK. TLS-PSK.
6.1. Current Practices 6.1. Current Practices
RADIUS identifies clients by source IP address ([RFC2865] and RADIUS identifies clients by source IP address (see [RFC2865] and
[RFC6613]) or by client certificate ([RFC6614] and [RFC7585]). [RFC6613]) or by client certificate (see [RFC6614] and [RFC7585]).
Neither of these approaches work for TLS-PSK. This section describes Neither of these approaches work for TLS-PSK. This section describes
current practices and mandates behavior for servers which use TLS- current practices and mandates behavior for servers that use TLS-PSK.
PSK.
A RADIUS/UDP server is typically configured with a set of information A RADIUS/UDP server is typically configured with a set of information
per client, which includes at least the source IP address and shared per client, which includes at least the source IP address and shared
secret. When the server receives a RADIUS/UDP packet, it looks up secret. When the server receives a RADIUS/UDP packet, it looks up
the source IP address, finds a client definition, and therefore the the source IP address, finds a client definition, and therefore the
shared secret. The packet is then authenticated (or not) using that shared secret. The packet is then authenticated (or not) using that
shared secret. shared secret.
That is, the IP address is treated as the clients identity, and the That is, the IP address is treated as the clients identity, and the
shared secret is used to prove the clients authenticity and shared shared secret is used to prove the clients authenticity and shared
trust. The set of clients forms a logical database "client table", trust. The set of clients forms a logical database "client table"
with the IP address as the key. with the IP address as the key.
A server may be configured with additional site-local policies A server may be configured with additional site-local policies
associated with that client. For example, a client may be marked up associated with that client. For example, a client may be marked up
as being a WiFi Access Point, or a VPN concentrator, etc. Different as being a Wi-Fi Access Point, a VPN concentrator, etc. Different
clients may be permitted to send different kinds of requests, where clients may be permitted to send different kinds of requests, where
some may send Accounting-Request packets, and other clients may not some may send Accounting-Request packets, and other clients may not
send accounting packets. send accounting packets.
6.2. Practices for TLS-PSK 6.2. Practices for TLS-PSK
We define practices for TLS-PSK by analogy with the RADIUS/UDP use- We define practices for TLS-PSK by analogy with the RADIUS/UDP use
case, and by extending the additional policies associated with the case and by extending the additional policies associated with the
client. The PSK Identity replaces the source IP address as the client. The PSK Identity replaces the source IP address as the
client identifier. The PSK replaces the shared secret as proof of client identifier. The PSK replaces the shared secret as proof of
client authenticity and shared trust. However, systems implementing client authenticity and shared trust. However, systems implementing
RADIUS/TLS [RFC6614] and RADIUS/DTLS [RFC7360] MUST still use the RADIUS/TLS [RFC6614] and RADIUS/DTLS [RFC7360] MUST still use the
shared secret as discussed in those specifications. Any PSK is only shared secret as discussed in those specifications. Any PSK is only
used by the TLS layer, and has no effect on the RADIUS data which is used by the TLS layer and has no effect on the RADIUS data that is
being transported. That is, the RADIUS data transported in a TLS being transported. That is, the RADIUS data transported in a TLS
tunnel is the same no matter if client authentication is done via PSK tunnel is the same no matter if client authentication is done via PSK
or by client certificates. The encoding of the RADIUS data is or by client certificates. The encoding of the RADIUS data is
entirely unaffected by the use (or not) of PSKs and client entirely unaffected by the use (or not) of PSKs and client
certificates. certificates.
In order to securely support dynamic source IP addresses for clients, In order to securely support dynamic source IP addresses for clients,
we also require that servers limit clients based on a network range. we also require that servers limit clients based on a network range.
The alternative would be to suggest that RADIUS servers allow any The alternative would be to suggest that RADIUS servers allow any
source IP address to connect and try TLS-PSK, which could be a source IP address to connect and try TLS-PSK, which could be a
security risk. When RADIUS servers do no source IP address security risk. When RADIUS servers do no source IP address
filtering, it is easier for attackers to send malicious traffic to filtering, it is easier for attackers to send malicious traffic to
the server. An issue with a TLS library or even a TCP/IP stack could the server. An issue with a TLS library or even a TCP/IP stack could
permit the attacker to gain unwarranted access. In contrast, when IP permit the attacker to gain unwarranted access. In contrast, when IP
address filtering is done, attackers generally must first gain access address filtering is done, attackers generally must first gain access
to a secure network before attacking the RADIUS server. to a secure network before attacking the RADIUS server.
Even where [RFC7585] dynamic discovery is not used, the use of TLS- Even where dynamic discovery [RFC7585] is not used, the use of TLS-
PSK across unrelated organizations requires that those organizations PSK across unrelated organizations requires that those organizations
share PSKs. Such sharing makes it easier for a client to impersonate share PSKs. Such sharing makes it easier for a client to impersonate
a server, and vice versa. In contrast, when certificates are used, a server, and vice versa. In contrast, when certificates are used,
such impersonations are impossible. It is therefore NOT RECOMMENDED such impersonations are impossible. It is therefore NOT RECOMMENDED
to use TLS-PSK across organizational boundaries. to use TLS-PSK across organizational boundaries.
When TLS-PSK is used in an environment where both client and server When TLS-PSK is used in an environment where both client and server
are part of the same organization, then impersonations only affect are part of the same organization, then impersonations only affect
that organization. As TLS offers significant advantages over RADIUS/ that organization. As TLS offers significant advantages over RADIUS/
UDP, it is RECOMMENDED that organizations use RADIUS/TLS with TLS-PSK UDP, it is RECOMMENDED that organizations use RADIUS/TLS with TLS-PSK
to replace RADIUS/UDP for all systems managed within the same to replace RADIUS/UDP for all systems managed within the same
organization. While such systems are generally located inside of organization. While such systems are generally located inside of
private networks, there are no known security issues with using TLS- private networks, there are no known security issues with using TLS-
PSK for RADIUS/TLS connections across the public Internet. PSK for RADIUS/TLS connections across the public Internet.
If a client system is compromised, its complete configuration is If a client system is compromised, its complete configuration is
exposed to the attacker. Exposing a client certificate means that exposed to the attacker. Exposing a client certificate means that
the attacker can pretend to be the client. In contrast, exposing a the attacker can pretend to be the client. In contrast, exposing a
PSK means that the attacker can not only pretend to be the client, PSK means that the attacker cannot only pretend to be the client, but
but can also pretend to be the server. can also pretend to be the server.
The main benefit of TLS-PSK, therefore, is that its operational The main benefit of TLS-PSK, therefore, is that its operational
processes are similar to that used for managing RADIUS/UDP, while processes are similar to that used for managing RADIUS/UDP, while
gaining the increased security of TLS. However, it is still gaining the increased security of TLS. However, it is still
beneficial for servers to perform IP address filtering, in order to beneficial for servers to perform IP address filtering, in order to
further limit their exposure to attacks. further limit their exposure to attacks.
6.2.1. IP Filtering 6.2.1. IP Filtering
A server supporting this specification MUST perform IP address A server supporting this specification MUST perform IP address
filtering on incoming connections. There are few reasons for a filtering on incoming connections. There are few reasons for a
server to have a default configuration which allows connections from server to have a default configuration that allows connections from
any source IP address. any source IP address.
A TLS-PSK server MUST be configurable with a set of "allowed" network A TLS-PSK server MUST be configurable with a set of "allowed" network
ranges from which clients are permitted to connect. Any connection ranges from which clients are permitted to connect. Any connection
from outside of the allowed range(s) MUST be rejected before any PSK from outside of the allowed range(s) MUST be rejected before any PSK
Identity is checked. It is RECOMMENDED that servers support IP Identity is checked. It is RECOMMENDED that servers support IP
address filtering even when TLS-PSK is not used. address filtering even when TLS-PSK is not used.
The "allowed" network ranges could be implemented as a global list, The "allowed" network ranges could be implemented as a global list,
or one or more network ranges could be tied to a client or clients. or one or more network ranges could be tied to a client or clients.
The intent here is to allow connections to be filtered by source IP The intent here is to allow connections to be filtered by source IP
address, and to allow clients to be limited to a subset of network address and to allow clients to be limited to a subset of network
addresses. The exact method and representation of that filtering is addresses. The exact method and representation of that filtering is
up to an implementation. up to an implementation.
Conceptually, the set of IP addresses and ranges, along with Conceptually, the set of IP addresses and ranges, along with
permitted clients and their credentials forms a logical "client permitted clients and their credentials, form a logical "client
table" which the server uses to both filter and authenticate clients. table" that the server uses to both filter and authenticate clients.
The client table should contain information such as allowed network The client table should contain information such as allowed network
ranges, PSK Identity and associated PSK, credentials for another TLS ranges, PSK Identity and associated PSK, credentials for another TLS
authentication method, or flags which indicate that the server should authentication method, or flags that indicate that the server should
require a client certificate. require a client certificate.
Once a server receives a connection, it checks the source IP address Once a server receives a connection, it checks the source IP address
against the list of all allowed IP addresses or ranges in the client against the list of all allowed IP addresses or ranges in the client
table. If none match, the connection MUST be rejected. That is, the table. If none match, the connection MUST be rejected. That is, the
connection MUST be from an authorized source IP address. connection MUST be from an authorized source IP address.
Once a connection has been established, the server MUST NOT process Once a connection has been established, the server MUST NOT process
any application data inside of the TLS tunnel until the client has any application data inside of the TLS tunnel until the client has
been authenticated. Instead, the server normally receives a TLS-PSK been authenticated. Instead, the server normally receives a TLS-PSK
skipping to change at page 18, line 46 skipping to change at line 792
the server MUST close the connection. The server then also checks if the server MUST close the connection. The server then also checks if
this client definition allows this particular source IP address. If this client definition allows this particular source IP address. If
the source IP address is not allowed, the server MUST close the the source IP address is not allowed, the server MUST close the
connection. connection.
Where the server does not receive TLS-PSK from the client, it Where the server does not receive TLS-PSK from the client, it
proceeds with another authentication method such as client proceeds with another authentication method such as client
certificates. Such requirements are discussed elsewhere, most certificates. Such requirements are discussed elsewhere, most
notably in [RFC6614] and [RFC7360]. notably in [RFC6614] and [RFC7360].
An implementation may perform two independent IP address lookups. An implementation may perform two independent IP address lookups:
First, to check if the connection allowed at all, and second to check first to check if the connection is allowed at all, and second to
if the connection is authorized for this particular client. One or check if the connection is authorized for this particular client.
both checks may be used by a particular implementation. The two sets One or both checks may be used by a particular implementation. The
of IP addresses can overlap, and implementations SHOULD support that two sets of IP addresses can overlap, and implementations SHOULD
capability. support that capability.
Depending on the implementation, one or more clients may share a list Depending on the implementation, one or more clients may share a list
of allowed network ranges. Alternately, the allowed network ranges of allowed network ranges. Alternately, the allowed network ranges
for two clients can overlap only partially, or not at all. All of for two clients can overlap only partially, or not at all. All of
these possibilities MUST be supported by the server implementation. these possibilities MUST be supported by the server implementation.
For example, a RADIUS server could be configured to be accept For example, a RADIUS server could be configured to accept
connections from a source network of 192.0.2.0/24 or 2001:DB8::/32. connections from a source network of 192.0.2.0/24 or 2001:DB8::/32.
The server could therefore discard any TLS connection request which The server could therefore discard any TLS connection request that
comes from a source IP address outside of that network. In that comes from a source IP address outside of that network. In that
case, there is no need to examine the PSK Identity or to find the case, there is no need to examine the PSK Identity or to find the
client definition. Instead, the IP source filtering policy would client definition. Instead, the IP source filtering policy would
deny the connection before any TLS communication had been performed. deny the connection before any TLS communication had been performed.
As some clients may have dynamic IP addresses, it is possible for a As some clients may have dynamic IP addresses, it is possible for one
one PSK Identity to appear at different source IP addresses over PSK Identity to appear at different source IP addresses over time.
time. In addition, as there may be many clients behind one NAT In addition, as there may be many clients behind one NAT gateway,
gateway, there may be multiple RADIUS clients using one public IP there may be multiple RADIUS clients using one public IP address.
address. RADIUS servers MUST support multiple PSK Identifiers at one RADIUS servers MUST support multiple PSK Identifiers at one source IP
source IP address. address.
That is, a server needs to support multiple different clients within That is, a server needs to support multiple different clients within
one network range, multiple clients behind a NAT, and one client one network range, multiple clients behind a NAT, and one client
having different IP addresses over time. All of those use-cases are having different IP addresses over time. All of those use cases are
common and necessary. common and necessary.
The following section describes these requirements in more detail. The following section describes these requirements in more detail.
6.2.2. PSK Authentication 6.2.2. PSK Authentication
Once the source IP address has been verified to be allowed for this Once the source IP address has been verified to be allowed for this
particular client, the server authenticates the TLS connection via particular client, the server authenticates the TLS connection via
the PSK taken from the client definition. If the PSK is verified, the PSK taken from the client definition. If the PSK is verified,
the server then accepts the connection, and proceeds with RADIUS/TLS the server then accepts the connection and proceeds with RADIUS/TLS
as per [RFC6614]. as per [RFC6614].
If the PSK is not verified, then the server MUST close the If the PSK is not verified, then the server MUST close the
connection. While TLS provides for fallback to other authentication connection. While TLS provides for fallback to other authentication
methods such as client certificates, there is no reason for a client methods such as client certificates, there is no reason for a client
to be configured simultaneously with multiple authentication methods. to be configured simultaneously with multiple authentication methods.
A client MUST use only one authentication method for TLS. An A client MUST use only one authentication method for TLS. An
authentication method is either TLS-PSK, client certificates, or some authentication method is either TLS-PSK, client certificates, or some
other method supported by TLS. other method supported by TLS.
That is, client configuration is relatively simple: use a particular That is, client configuration is relatively simple: use a particular
set of credentials to authenticate to a particular server. While set of credentials to authenticate to a particular server. While
clients may support multiple servers and fail-over or load-balancing, clients may support multiple servers and fail-over or load-balancing,
that configuration is generally orthogonal to the choice of which that configuration is generally orthogonal to the choice of which
credentials to use. credentials to use.
6.2.3. Resumption 6.2.3. Resumption
It is NOT RECOMMENDED that servers enable resumption for sessions It is NOT RECOMMENDED that servers enable resumption for sessions
which use TLS-PSK. There are few practical benefits to supporting that use TLS-PSK. There are few practical benefits to supporting
resumption, and many complexities. resumption and many complexities.
However, some systems will need to support both TLS-PSK, and other However, some systems will need to support both TLS-PSK and other
TLS-based authentication methods such as certificates, while also TLS-based authentication methods such as certificates, while also
supporting session resumption. It is therefore vital for servers to supporting session resumption. It is therefore vital for servers to
be able to distinguish the use-case of TLS-PSK with pre-configured be able to distinguish the use case of TLS-PSK with preconfigured
identities from TLS-PSK which is being used for resumptions. identities from TLS-PSK that is being used for resumptions.
The above discussion of PSK Identities is complicated by the use of The above discussion of PSK Identities is complicated by the use of
PSKs for resumption in TLS 1.3. A server which receives a PSK PSKs for resumption in TLS 1.3. A server that receives a PSK
Identity via TLS typically cannot query the TLS layer to see if this Identity via TLS typically cannot query the TLS layer to see if this
identity is for a resumed session (which is possibly for another TLS identity is for a resumed session (which is possibly for another TLS
authentication method), or is instead a static pre-provisioned authentication method), or is instead a static pre-provisioned
identity. This confusion complicates server implementations. identity. This confusion complicates server implementations.
One way for a server to tell the difference between the two kinds of One way for a server to tell the difference between the two kinds of
identities is via construction. Identities used for resumption can identities is via construction. Identities used for resumption can
be constructed via a fixed format, such as recommended by [RFC5077], be constructed via a fixed format, such as what is recommended by
Section 4. A static pre-provisioned identity could be in format of [RFC5077], Section 4. A static pre-provisioned identity could be in
an NAI, as given in [RFC7542]. An implementation could therefore the format of an NAI, as given in [RFC7542]. An implementation could
examine the incoming identity, and determine from the identity alone therefore examine the incoming identity and determine from the
what kind of authentication was being performed. identity alone what kind of authentication was being performed.
An alternative way for a server to distinguish the two kinds of An alternative way for a server to distinguish the two kinds of
identities is to maintain two tables. One table would contain static identities is to maintain two tables. One table would contain static
identities, as the logical client table described above. Another identities, as the logical client table described above. Another
table could be the table of identities handed out for resumption. table could be the table of identities handed out for resumption.
The server would then look up any PSK Identity in one table, and if The server would then look up any PSK Identity in one table, and if
not found, query the other one. An identity would be found in a it is not found, query the other one. Either an identity would be
table, in which case it can be authenticated. Or, the identity would found in a table, in which case it can be authenticated, or the
not be found in either table, in which case it is unknown, and the identity would not be found in either table, in which case it is
server MUST close the connection. unknown, and the server MUST close the connection.
As suggested in [RFC8446], TLS-PSK peers MUST NOT store resumption As suggested in [RFC8446], TLS-PSK peers MUST NOT store resumption
PSKs or tickets (and associated cached data) for longer than 604800 PSKs or tickets (and associated cached data) for longer than 604800
seconds (7 days) regardless of the PSK or ticket lifetime. seconds (7 days), regardless of the PSK or ticket lifetime.
Since resumption in TLS 1.3 uses PSK Identies and keys, it is NOT Since resumption in TLS 1.3 uses PSK Identities and keys, it is NOT
RECOMMENDED to permit resumption of sessions when TLS-PSK is used. RECOMMENDED to permit resumption of sessions when TLS-PSK is used.
The use of resumption offers additional complexity with minimal The use of resumption offers additional complexity with minimal
addition benefit. additional benefits.
Where resumption is allowed with TLS-PSK, systems MUST cache data Where resumption is allowed with TLS-PSK, systems MUST cache data
during the initial full handshake sufficient to allow authorization during the initial full handshake sufficiently enough to allow
decisions to be made during resumption. If the cached data cannot be authorization decisions to be made during resumption. If the cached
retrieved securely, resumption MUST NOT be done. Instead, the system data cannot be retrieved securely, resumption MUST NOT be done.
MUST perform a full handshake. Instead, the system MUST perform a full handshake.
The data which needs to be cached is typically information such as The data that needs to be cached is typically information such as the
the original PSK Identity, along with any policies associated with original PSK Identity, along with any policies associated with that
that identity. identity.
Information from the original TLS exchange (e.g., the original PSK Information from the original TLS exchange (e.g., the original PSK
Identity) as well as related information (e.g., source IP addresses) Identity) as well as related information (e.g., source IP addresses)
may change between the initial full handshake and resumption. This may change between the initial full handshake and resumption. This
change creates a "time-of-check time-of-use" (TOCTOU) security change creates a "time-of-check time-of-use" (TOCTOU) security
vulnerability. A malicious or compromised client could supply one vulnerability. A malicious or compromised client could supply one
set of data during the initial authentication, and a different set of set of data during the initial authentication and a different set of
data during resumption, potentially allowing them to obtain access data during resumption, potentially allowing them to obtain access
that they should not have. that they should not have.
If any authorization or policy decisions were made with information If any authorization or policy decisions were made with information
that has changed between the initial full handshake and resumption, that has changed between the initial full handshake and resumption,
and if change may lead to a different decision, such decisions MUST and if changes may lead to a different decision, such decisions MUST
be reevaluated. Systems MUST also reevaluate authorization and be reevaluated. Systems MUST also reevaluate authorization and
policy decisions during resumption, based on the information given in policy decisions during resumption, based on the information given in
the new connection. Servers MAY refuse to perform resumption where the new connection. Servers MAY refuse to perform resumption where
the information supplied during resumption does not match the the information supplied during resumption does not match the
information supplied during the original authentication. If a safe information supplied during the original authentication. If a safe
decision is not possible, servers MUST instead continue with a full decision is not possible, servers MUST instead continue with a full
handshake. handshake.
6.2.4. Interaction with other TLS authentication methods 6.2.4. Interaction with Other TLS Authentication Methods
When a server supports both TLS-PSK and client certificates, it MUST When a server supports both TLS-PSK and client certificates, it MUST
be able to accept authenticated connections from clients which may be able to accept authenticated connections from clients that may use
use either type of credentials, perhaps even from the same source IP either type of credentials, perhaps even from the same source IP
address and at the same time. That is, servers are required to both address and at the same time. That is, servers are required to both
authenticate the client, and also to filter clients by source IP authenticate the client and also to filter clients by source IP
address. These checks both have to match in order for a client to be address. These checks both have to match in order for a client to be
accepted. accepted.
7. Privacy Considerations 7. Privacy Considerations
We make no changes over [RFC6614] and [RFC7360]. We make no changes to [RFC6614] and [RFC7360].
8. Security Considerations 8. Security Considerations
The primary focus of this document is addressing security The primary focus of this document is addressing security
considerations for RADIUS. considerations for RADIUS.
Previous specifications discuss security considerations for TLS-PSK Previous specifications discuss security considerations for TLS-PSK
in detail. We refer the reader to [RFC8446], Appendix E.7, in detail. We refer the reader to Appendix E.7 of [RFC8446],
[RFC9257], and [RFC9258]. Those documents are newer than [RFC6614] [RFC9257], and [RFC9258]. Those documents are newer than [RFC6614]
and [RFC7360], andtherefore raise issues which were not considered and [RFC7360], and therefore raise issues that were not considered
during the initial design of RADIUS/TLS and RADIUS/DTLS. during the initial design of RADIUS/TLS and RADIUS/DTLS.
Using TLS-PSK across the wider Internet for RADIUS can have different Using TLS-PSK across the wider Internet for RADIUS can have different
security considerations than for other protocols. For example, if security considerations than for other protocols. For example, if
TLS-PSK was for client/server communication with HTTPS, then having a TLS-PSK was for client/server communication with HTTPS, then having a
PSK be exposed or broken could affect one users traffic. In PSK be exposed or broken could affect one user's traffic. In
contrast, RADIUS contains credentials and personally identifiable contrast, RADIUS contains credentials and personally identifiable
information (PII) for many users. As a result, an attacker being information (PII) for many users. As a result, an attacker being
able to see inside of a TLS-PSK connection for RADIUS would result in able to see inside of a TLS-PSK connection for RADIUS would result in
substantial amounts of PII being leaked, possibly including substantial amounts of PII being leaked, possibly including
passwords. passwords.
When modes providing forward secrecy are used (e.g. ECDHE_PSK When modes providing forward secrecy are used (e.g., ECDHE_PSK as
[RFC5489] and [RFC8442]), such attacks are limited to future seen in [RFC5489] and [RFC8442]), such attacks are limited to future
sessions, and historical sessions are still secure. sessions, and historical sessions are still secure.
9. IANA Considerations 9. IANA Considerations
There are no IANA considerations in this document. This document has no IANA actions.
RFC Editor: This section may be removed before final publication.
10. Acknowledgments
Thanks to the many reviewers in the RADEXT working group for positive
feedback.
11. Changelog
* 00 - initial version
* 01 - update examples 10. References
12. References 10.1. Normative References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000, RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/rfc/rfc2865>. <https://www.rfc-editor.org/info/rfc2865>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)", Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, DOI 10.17487/RFC4279, December 2005, RFC 4279, DOI 10.17487/RFC4279, December 2005,
<https://www.rfc-editor.org/rfc/rfc4279>. <https://www.rfc-editor.org/info/rfc4279>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS", "Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, DOI 10.17487/RFC6614, May 2012, RFC 6614, DOI 10.17487/RFC6614, May 2012,
<https://www.rfc-editor.org/rfc/rfc6614>. <https://www.rfc-editor.org/info/rfc6614>.
[RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a [RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a
Transport Layer for RADIUS", RFC 7360, Transport Layer for RADIUS", RFC 7360,
DOI 10.17487/RFC7360, September 2014, DOI 10.17487/RFC7360, September 2014,
<https://www.rfc-editor.org/rfc/rfc7360>. <https://www.rfc-editor.org/info/rfc7360>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", RFC 8265, Representing Usernames and Passwords", RFC 8265,
DOI 10.17487/RFC8265, October 2017, DOI 10.17487/RFC8265, October 2017,
<https://www.rfc-editor.org/rfc/rfc8265>. <https://www.rfc-editor.org/info/rfc8265>.
[RFC9257] Housley, R., Hoyland, J., Sethi, M., and C. A. Wood, [RFC9257] Housley, R., Hoyland, J., Sethi, M., and C. A. Wood,
"Guidance for External Pre-Shared Key (PSK) Usage in TLS", "Guidance for External Pre-Shared Key (PSK) Usage in TLS",
RFC 9257, DOI 10.17487/RFC9257, July 2022, RFC 9257, DOI 10.17487/RFC9257, July 2022,
<https://www.rfc-editor.org/rfc/rfc9257>. <https://www.rfc-editor.org/info/rfc9257>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/rfc/rfc9325>. 2022, <https://www.rfc-editor.org/info/rfc9325>.
12.2. Informative References 10.2. Informative References
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/rfc/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for [RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for
Transport Layer Security (TLS)", RFC 5489, Transport Layer Security (TLS)", RFC 5489,
DOI 10.17487/RFC5489, March 2009, DOI 10.17487/RFC5489, March 2009,
<https://www.rfc-editor.org/rfc/rfc5489>. <https://www.rfc-editor.org/info/rfc5489>.
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613,
DOI 10.17487/RFC6613, May 2012, DOI 10.17487/RFC6613, May 2012,
<https://www.rfc-editor.org/rfc/rfc6613>. <https://www.rfc-editor.org/info/rfc6613>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015, DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/rfc/rfc7542>. <https://www.rfc-editor.org/info/rfc7542>.
[RFC7585] Winter, S. and M. McCauley, "Dynamic Peer Discovery for [RFC7585] Winter, S. and M. McCauley, "Dynamic Peer Discovery for
RADIUS/TLS and RADIUS/DTLS Based on the Network Access RADIUS/TLS and RADIUS/DTLS Based on the Network Access
Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October
2015, <https://www.rfc-editor.org/rfc/rfc7585>. 2015, <https://www.rfc-editor.org/info/rfc7585>.
[RFC8442] Mattsson, J. and D. Migault, "ECDHE_PSK with AES-GCM and [RFC8442] Mattsson, J. and D. Migault, "ECDHE_PSK with AES-GCM and
AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2", RFC 8442, AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2", RFC 8442,
DOI 10.17487/RFC8442, September 2018, DOI 10.17487/RFC8442, September 2018,
<https://www.rfc-editor.org/rfc/rfc8442>. <https://www.rfc-editor.org/info/rfc8442>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8492] Harkins, D., Ed., "Secure Password Ciphersuites for [RFC8492] Harkins, D., Ed., "Secure Password Ciphersuites for
Transport Layer Security (TLS)", RFC 8492, Transport Layer Security (TLS)", RFC 8492,
DOI 10.17487/RFC8492, February 2019, DOI 10.17487/RFC8492, February 2019,
<https://www.rfc-editor.org/rfc/rfc8492>. <https://www.rfc-editor.org/info/rfc8492>.
[RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
and C. Wood, "Randomness Improvements for Security and C. Wood, "Randomness Improvements for Security
Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020, Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,
<https://www.rfc-editor.org/rfc/rfc8937>. <https://www.rfc-editor.org/info/rfc8937>.
[RFC9258] Benjamin, D. and C. A. Wood, "Importing External Pre- [RFC9258] Benjamin, D. and C. A. Wood, "Importing External Pre-
Shared Keys (PSKs) for TLS 1.3", RFC 9258, Shared Keys (PSKs) for TLS 1.3", RFC 9258,
DOI 10.17487/RFC9258, July 2022, DOI 10.17487/RFC9258, July 2022,
<https://www.rfc-editor.org/rfc/rfc9258>. <https://www.rfc-editor.org/info/rfc9258>.
Acknowledgments
Thanks to the many reviewers in the RADEXT Working Group for positive
feedback.
Author's Address Author's Address
Alan DeKok Alan DeKok
InkBridge Networks InkBridge Networks
Email: alan.dekok@inkbridge.io Email: alan.dekok@inkbridge.io
 End of changes. 149 change blocks. 
361 lines changed or deleted 333 lines changed or added

This html diff was produced by rfcdiff 1.48.