rfc9813v1.txt   rfc9813.txt 
Internet Engineering Task Force (IETF) A. DeKok Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 9813 InkBridge Networks Request for Comments: 9813 InkBridge Networks
BCP: 243 June 2025 BCP: 243 June 2025
Category: Best Current Practice Category: Best Current Practice
ISSN: 2070-1721 ISSN: 2070-1721
Operational Considerations for RADIUS and TLS Pre-Shared Key (TLS-PSK) Operational Considerations for Using TLS Pre-Shared Keys (TLS-PSKs) with
RADIUS
Abstract Abstract
This document provides implementation and operational considerations This document provides implementation and operational considerations
for using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS/TLS (RFC 6614) for using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS/TLS (RFC 6614)
and RADIUS/DTLS (RFC 7360). The purpose of the document is to help and RADIUS/DTLS (RFC 7360). The purpose of the document is to help
smooth the operational transition from the use of RADIUS/UDP to smooth the operational transition from the use of RADIUS/UDP to
RADIUS/TLS. RADIUS/TLS.
Status of This Memo Status of This Memo
skipping to change at line 241 skipping to change at line 242
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 that 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 that 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 seen in Section 4.1.2) in order to make it easier
people to interact with. Where 512 bits of entropy are input to an for people to interact with. Where 512 bits of entropy are input to
encoding construct, the output may be larger than 64 octets. an 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
that 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
skipping to change at line 428 skipping to change at line 429
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 server 3. When the server issues session tickets for resumption, the 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 forced 4. One way to do this is to use stateless resumption with a forced
non-UTF-8 key_name per [RFC5077], Section 4, such as by setting non-UTF-8 key_name per [RFC8446], Section 4.6.1, such as by
one octet to 0x00. setting one octet to 0x00.
5. When receiving TLS, the server receives a 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 preconfigured client that matches 5.1. If yes, it searches for a preconfigured client that matches
that identity. that identity.
5.1.1. If the identity is found, it authenticates the 5.1.1. If the identity is found, it authenticates the
client via PSK. client via PSK.
skipping to change at line 468 skipping to change at line 469
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:
incorrect UTF-8 format; or it may contain data that forms an
injection attack for SQL, Lightweight Directory Access Protocol * have an incorrect UTF-8 format,
(LDAP), Representational State Transfer (REST), or shell meta
characters; or it may contain embedded NUL octets that are * contain data that forms an injection attack for SQL, Lightweight
incompatible with APIs that expect NUL terminated strings. The Directory Access Protocol (LDAP), Representational State Transfer
identity may also be up to 65535 octets long. (REST), or shell meta characters, or
* contain embedded NUL octets that are 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 that 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 that 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.
skipping to change at line 573 skipping to change at line 579
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 that ask interface flag that is "TLS yes / no", and also provide fields that
for the PSK Identity and PSK itself. ask for the PSK Identity and PSK itself.
For TLS 1.3, implementations MUST support the "psk_dhe_ke" Pre-Shared For TLS 1.3, implementations MUST support the "psk_dhe_ke" PSK
Key Exchange Mode in TLS 1.3 as discussed in [RFC8446], Section 4.2.9 Exchange Mode as discussed in [RFC8446], Section 4.2.9 and in
and in [RFC9257], Section 6. Implementations MUST implement the [RFC9257], Section 6. Implementations MUST implement the recommended
recommended cipher suites in [RFC9325], Section 4.2 for TLS 1.2 and cipher suites in [RFC9325], Section 4.2 for TLS 1.2 and in [RFC8446],
in [RFC8446], Section 9.1 for TLS 1.3. In order to future-proof Section 9.1 for TLS 1.3. In order to future-proof these
these recommendations, we give the following recommendations. 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 the "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 that 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 PSK extension, it MUST close the connection if the
if the server did not also select the pre-shared key to continue the server did not also select the PSK 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
skipping to change at line 636 skipping to change at line 641
5.1.2. Usability Guidance 5.1.2. Usability Guidance
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 PSK (TLS-PSK) for RADIUS/TLS.
Systems that 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 the "psk_dhe_ke" Pre-Shared For TLS 1.3, implementations MUST support the "psk_dhe_ke" PSK
Key Exchange Mode in TLS 1.3 as discussed in [RFC8446], Section 4.2.9 Exchange Mode as discussed in [RFC8446], Section 4.2.9 and in
and in [RFC9257], Section 6. Implementations MUST implement the [RFC9257], Section 6. Implementations MUST implement the recommended
recommended cipher suites in [RFC9325], Section 4.2 for TLS 1.2 and cipher suites in [RFC9325], Section 4.2 for TLS 1.2 and in [RFC8446],
in [RFC8446], Section 9.1 for TLS 1.3. In order to future-proof Section 9.1 for TLS 1.3. In order to future-proof these
these recommendations, we give the following recommendations. 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 the "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 that 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
skipping to change at line 677 skipping to change at line 682
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 that use TLS-PSK. current practices and mandates behavior for servers that use TLS-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 client's identity, and the
shared secret is used to prove the clients authenticity and shared shared secret is used to prove the client's 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 Wi-Fi Access Point, 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.
skipping to change at line 871 skipping to change at line 876
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 that 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 what is recommended by be constructed via a fixed format, such as what is recommended by
[RFC5077], Section 4. A static pre-provisioned identity could be in [RFC8446], Section 4.6.1. A static pre-provisioned identity could be
the format of an NAI, as given in [RFC7542]. An implementation could in the format of an NAI, as given in [RFC7542]. An implementation
therefore examine the incoming identity and determine from the could therefore examine the incoming identity and determine from the
identity alone 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
it is not found, query the other one. Either an identity would be it is not found, query the other one. Either an identity would be
found in a table, in which case it can be authenticated, or the found in a table, in which case it can be authenticated, or the
identity would not be found in either table, in which case it is identity would not be found in either table, in which case it is
skipping to change at line 1020 skipping to change at line 1025
<https://www.rfc-editor.org/info/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/info/rfc9325>. 2022, <https://www.rfc-editor.org/info/rfc9325>.
10.2. Informative References 10.2. Informative References
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/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/info/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/info/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,
 End of changes. 13 change blocks. 
42 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.48.