RADIUS and TLS-PSK

4.1. Requirements on PSKs

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 binds the PSK to a particular key derivation function, TLS 1.2 does not. This binding means that it is possible to use the same PSK in different hashes, leading to the potential for attacking the PSK by comparing the hash outputs. While there are no known insecurities, these uses are not known to be secure, and should therefore be avoided.¶

[RFC9258] adds a key derivation function to the import interface of (D)TLS 1.3, which binds the externally provided PSK to the protocol version. In particular, that document:¶

• ... describes a mechanism for importing PSKs derived from external PSKs by including the target KDF, (D)TLS protocol version, and an optional context string to ensure uniqueness. This process yields 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 prior versions. This expands what would normally have been a 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 earlier versions of TLS. This requirement prevents reuse of a PSK with multiple TLS versions, which prevents the attacks discussed in [RFC8446], Appendix E.7. The exact manner in which this requirement is enforced is implementation-specific. One possibility is to have two different PSKs. Another possibility is to forbid the use of TLS 1.3, or to forbid the use of TLS versions less than TLS 1.3.¶

It is RECOMMENDED that systems follow the directions of [RFC9257], Section 6 for the use of external PSKs in TLS. That document provides extremely useful guidance on generating and using PSKs.¶

Implementations MUST support PSKs of at least 32 octets in length, 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 PSK is limited by the size of the hash output. This output may be 256, 384, or 512 bits in length. Never the less, it is good practice 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. Implementations which limit the PSK to a maximum of 64 octets are likely to use PSKs which have much less than 512 bits of entropy. 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 people to interact with. Where 512 bits of entropy are input to an encoding construct, the output may be larger than 64 octets.¶

Implementations MUST require that PSKs be at least 16 octets in length, which SHOULD be derived from a source with at least 128 bits of entropy. That is, short PSKs MUST NOT be permitted to be used, and PSKs MUST be uniformly random. The strength of the PSK is not determined by 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 entropy, so a source of cryptographically secure random numbers MUST be used.¶

Administrators SHOULD use PSKs of at least 24 octets, generated using a source of cryptographically secure random numbers. Implementers needing a secure random number generator should see [RFC8937] for for further guidance. PSKs are not passwords, and administrators should not try to manually create PSKs.¶

Passwords are generally intended to be remembered and entered by people on a regular basis. In contrast, PSKs are intended to be entered once, and then automatically saved in a system configuration. As such, due to the limited entropy of passwords, they are not acceptable for use with TLS-PSK, and would only be acceptable for use with a password-authenticated key exchange (PAKE) TLS method [RFC8492].¶

We also incorporate by reference the requirements of [RFC7360], Section 10.2 when using PSKs.¶

In order to guide Implementers, we give an example script below which generates random PSKs. While the script is not portable to all possible systems, the intent here is to document a concise and simple method for creating PSKs which are both secure, and humanly manageable.¶

#!/usr/bin/env perl
use MIME::Base32;
use Crypt::URandom();
print join('-', unpack("(A4)*",
   lc encode_base32(Crypt::URandom::urandom(16)))), "\n";

This script reads 128 bits (16 octets) of random data from a secure source, encodes it in Base32, and then formats it to be more humanly manageable. The generated keys are of the form "yttb-4gv2-ynfk-jbjh-2dja-cj7e-am". This form of PSK will be accepted by any implementation which supports at least 32 octets for PSKs. Larger PSKs can be generated by passing larger values to the "urandom()" function. The above derivation assumes that the random source returns one bit of entropy for every bit of randomness which is returned. Sources failing that assumption are NOT RECOMMENDED.¶

4.2. PSK Identities

[RFC4279], Section 5.1 requires that PSK identities be encoded in UTF-8 format. However, [RFC8446], Section 4.6.1 reuses PSKs and the PSK identity for resumption, and defines the ticket as:¶

• the value of the ticket to be used as the PSK identity. The ticket itself is an opaque label. It MAY be either a database lookup key or a self-encrypted and self-authenticated value.¶

These definitions appear to be in conflict. This conflict is addressed in [RFC9257], Section 6.1.1, which discusses requirements for encoding and comparison of PSK identities. It is RECOMMENDED that systems follow the directions of [RFC9257], Section 6.1.1 when using PSK Identities for RADIUS/TLS.¶

In general, implements should allow for administratively provisioned PSK identities to follow [RFC4279] and be UTF-8, while PSK identities provisioned as part of resumption are automatically provisioned, and therefore follow [RFC8446].¶

Note that the PSK identity is sent in the clear, and is therefore visible to attackers. Where privacy is desired, the PSK identity could be either an opaque token generated cryptographically, or perhaps in the form of a Network Access Identifier (NAI) [RFC7542], where the "user" portion is an opaque token. For example, an NAI could be "68092112@example.com". If the attacker already knows that the client is associated with "example.com", then using that domain name in the PSK identity offers no additional information. In contrast, the "user" portion needs to be both unique to the client and private, so using an opaque token there is a more secure approach.¶

Implementations MUST support PSK Identities of 128 octets, and SHOULD 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 practical uses for extremely long PSK identities.¶

It is up to administrators and implementations as to how they differentiate administratively provisioned PSK identities from automatically provisioned identities used in TLS 1.3 session tickets. One approach could be to have administratively provisioned identities contain an NAI such as described above, while session tickets contain large blobs of opaque, encrypted, and authenticated text. It should then be relatively straightforward to differentiate the two types of identities. One is UTF-8, the other is not. One is not authenticated, the other is authenticated.¶

Servers MUST assign and/or track session resumption identities in a way which facilities the ability to distinguish those identities from pre-configured ones ,and which enables them to both find and validate the session resumption ticket.¶

A sample validation flow for TLS-PSK identities could be performed via the following steps:¶

• 1. PSK identities provided via an administration interface are enforced to be only UTF-8 on both client and server.¶
  2. The client treats session tickets received from the server as opaque blobs.¶
  3. When the server issues session tickets for resumption, the server ensures that they are not valid UTF-8.¶
  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 one octet to 0x00.¶

  5 When receiving TLS, the server receives Client-Hello containing a PSK, and checks if the identity is valid UTF-8.¶

  • 5.1. If yes, it searches for a pre-configured client which matches that identity.¶

    • 5.1.1. If the identity is found, authenticates the client via PSK.¶

      5.1.2. else the identity is invalid, and the server closes the connection.¶

    5.2 If the identity is not UTF-8, try resumption, which is usually be handled by a TLS library.¶

    • 5.2.1 If the TLS library verifies the session ticket, resumption has happened, and the connection is established.¶

      5.2.2. else the server ignores the session ticker, and performs normal TLS handshake with a certificate.¶

This validation flow is only suggested. Other validation methods are possible.¶

4.3. PSK and PSK Identity Sharing

While administrators may desire to share PSKs and/or PSK identities across multiple systems, such usage is NOT RECOMMENDED. Details of the possible attacks on reused PSKs are given in [RFC9257], Section 4.1.¶

Implementations MUST be able to configure a unique PSK and PSK identity for each possible client-server relationship. This configuration allows administrators desiring security to use unique PSKs for each such relationship. This configuration also allows administrators to re-use PSKs and PSK Identities where local policies permit.¶

Implementations SHOULD warn administrators if the same PSK identity and/or PSK is used for multiple client-server relationships.¶

5.1. PSK Identities

[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 identities, as the need to manage identities associated with PSK is a new requirement for NAS management interfaces, and is a new requirement for RADIUS servers.¶

RADIUS systems implementing TLS-PSK MUST support identities as per [RFC4279], Section 5.3, and MUST enable configuring TLS-PSK identities in management interfaces as per [RFC4279], Section 5.4.¶

The historic methods of signing RADIUS packets have not yet been cracked, 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 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 cryptography could be trivially leveraged to decrypt TLS-PSK sessions. Therefore in order to prevent confusion between shared secrets and TLS-PSKs, management interfaces and APIs need to label PSK fields as "PSK" or "TLS-PSK", rather than as "shared secret".¶

With TLS-PSK, RADIUS/TLS clients MUST permit the configuration of a RADIUS server IP address or host name, because dynamic server lookups [RFC7585] can only be used if servers use certificates.¶

6.1. Current Practices

RADIUS identifies clients by source IP address ([RFC2865] and [RFC6613]) or by client certificate ([RFC6614] and [RFC7585]). Neither of these approaches work for TLS-PSK. This section describes current practices and mandates behavior for servers which use TLS-PSK.¶

A RADIUS/UDP server is typically configured with a set of information per client, which includes at least the source IP address and shared secret. When the server receives a RADIUS/UDP packet, it looks up the source IP address, finds a client definition, and therefore the shared secret. The packet is then authenticated (or not) using that shared secret.¶

That is, the IP address is treated as the clients identity, and the shared secret is used to prove the clients authenticity and shared trust. The set of clients forms a logical database "client table", with the IP address as the key.¶

A server may be configured with additional site-local policies associated with that client. For example, a client may be marked up as being a WiFi Access Point, or a VPN concentrator, etc. Different clients may be permitted to send different kinds of requests, where some may send Accounting-Request packets, and other clients may not send accounting packets.¶

6.2. Practices for TLS-PSK

We define practices for TLS-PSK by analogy with the RADIUS/UDP use-case, and by extending the additional policies associated with the client. The PSK identity replaces the source IP address as the client identifier. The PSK replaces the shared secret as proof of client authenticity and shared trust. However, systems implementing RADIUS/TLS [RFC6614] and RADIUS/DTLS [RFC7360] MUST still use the 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 being transported. That is, the RADIUS data transported in a TLS tunnel is the same no matter if client authentication is done via PSK or by client certificates. The encoding of the RADIUS data is entirely unaffected by the use (or not) of PSKs and client certificates.¶

In order to securely support dynamic source IP addresses for clients, we also require that servers limit clients based on a network range. The alternative would be to suggest that RADIUS servers allow any source IP address to connect and try TLS-PSK, which could be a security risk. When RADIUS servers do no source IP address 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 permit the attacker to gain unwarranted access. In contrast, when IP address filtering is done, attackers generally must first gain access to a secure network before attacking the RADIUS server.¶

Even where [RFC7585] dynamic discovery is not used, servers SHOULD NOT permit TLS-PSK to be used across the wider Internet. The intent for TLS-PSK is for it to be used in internal / secured networks, where clients come from a small number of known locations. In contrast, certificates can be generated and assigned to clients without any interaction with the RADIUS server. Therefore if the RADIUS server needs to accept connections from clients at unknown locations, a more secure method is to use client certificates.¶

If a client system is compromised, its complete configuration is exposed to the attacker. Exposing a client certificate means that the attacker can pretend to be the client. In contrast, exposing a PSK means that the attacker can not only pretend to be the client, but can also pretend to be the server.¶

The benefits of TLS-PSK are in easing management and in administrative overhead, not in securing traffic from resourceful attackers. Where TLS-PSK is used across the Internet, PSKs MUST contain at least 256 bits of entropy.¶

For example, a RADIUS server could be configured to be accept connections from a source network of 192.0.2.0/24. The server could therefore discard any TLS connection request which 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 client definition. Instead, the IP source filtering policy would deny the connection before any TLS communication had been performed.¶

RADIUS servers need to be able to limit certain PSK identifiers to certain network ranges or IP addresses. That is, if a NAS is known to have a dynamic IP address within a particular subnet, the server should limit use of the NASes PSK to that subnet. This filtering can therefore help to catch configuration errors.¶

As some clients may have dynamic IP addresses, it is possible for a one PSK identity to appear at different source IP addresses over time. In addition, as there may be many clients behind one NAT gateway, there may be multiple RADIUS clients using one public IP address. RADIUS servers need to support multiple PSK identifiers at one source IP address.¶

That is, a server needs to support multiple different clients within one network range, multiple clients behind a NAT, and one client having different IP addresses over time. All of those use-cases are common and necessary.¶

The following section describes these requirements in more detail.¶