RFC 9813

Operational Considerations for Using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS

📅 published July 2025, from ietf

RFC 9813 🦋 Operational Considerations for Using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS

Okay bestie, here are the vitals 💅 This one is a Best Current Practice (BCP 243) from the Internet Engineering Task Force (IETF), written by A. DeKok at InkBridge Networks. It came out in July 2025 and has ISSN 2070-1721. Its header doesn't say it obsoletes or updates anything, so it's standing on its own 🌸

Abstract ✨

Okay so this doc gives implementation and operational tips for using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS/TLS (RFC 6614) and RADIUS/DTLS (RFC 7360) 🎀 The whole point is to make the move from RADIUS/UDP to RADIUS/TLS feel smooth and not like a big scary migration 🥺

Status of This Memo 📝

This memo documents an Internet Best Current Practice 💜

This doc is a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on BCPs, check out Section 2 of RFC 7841 🧚

For the current status of this doc, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9813 🔗

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved ©️

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, bestie, because they explain your rights and restrictions for this doc. Code Components pulled out of this doc have to include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Revised BSD License says 📜

Table of Contents 🗂️

   1.  Introduction
   2.  Terminology
   3.  Justification of PSK
   4.  General Discussion of PSKs and PSK Identities
     4.1.  Guidance for PSKs
       4.1.1.  PSK Requirements
       4.1.2.  Usability Guidance
       4.1.3.  Interaction Between PSKs and RADIUS Shared Secrets
     4.2.  PSK Identities
       4.2.1.  Security of PSK Identities
     4.3.  PSK and PSK Identity Sharing
     4.4.  PSK Lifetimes
   5.  Guidance for RADIUS Clients
     5.1.  PSK Identities
       5.1.1.  PSK Identity Requirements
       5.1.2.  Usability Guidance
   6.  Guidance for RADIUS Servers
     6.1.  Current Practices
     6.2.  Practices for TLS-PSK
       6.2.1.  IP Filtering
       6.2.2.  PSK Authentication
       6.2.3.  Resumption
       6.2.4.  Interaction with Other TLS Authentication Methods
   7.  Privacy Considerations
   8.  Security Considerations
   9.  IANA Considerations
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Acknowledgments
   Author's Address

1. Introduction ✨

So the earlier specs, "Transport Layer Security (TLS) Encryption for RADIUS" [RFC6614] and "Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS" [RFC7360], explained how (D)TLS can be used as a transport for RADIUS 🚀 But they don't give any guidance on using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS. This doc fills that gap, and it also covers implementation and operational considerations 💖

To keep the secrets and keys straight, this doc uses "shared secret" to mean "RADIUS shared secret", and "Pre-Shared Key (PSK)" to mean "secret keys that are used with TLS-PSK" 🔑

The whole purpose here is to help people move off the insecure RADIUS/UDP and onto the way more secure RADIUS/TLS 🛡️ PSKs are often less preferred than public or private keys, but the way they work follows the old-school RADIUS "shared secret" model. So it's easier for implementers and operators to switch to TLS when the switch comes as a series of small changes 🍓

TLS-PSK is meant for networks where the addresses of clients and servers are already known, the same way RADIUS/UDP works. That's similar to RADIUS/UDP with shared secrets 🧚 TLS-PSK is not suitable when clients dynamically discover servers, because the client has no way to work out which PSK goes with a new server (or the other way around) 😭 Dynamic discovery [RFC7585] is different: it lets a client or server authenticate a server or client it's never met before, because the parties can be issued a certificate by a known Certification Authority (CA) 🌸

Here's the catch: TLS-PSKs have symmetric information, meaning both parties know the same secret key. A client could, in theory, pretend to be a server 🙈 Certificates are asymmetric, so the parties can't just assume each other's identity. There's more on this in Section 4.3 💅

Unless a recommendation is explicitly called out as applying to TLS or DTLS alone, each recommendation applies to both TLS and DTLS 🫶

2. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like that 💜 Lowercase versions don't count as keywords, so don't panic 🙈

External PSK A PSK (along with a related PSK Identity) that is administratively configured. In other words, it's external to TLS and wasn't created by the TLS subsystem 🌷

Resumption PSK A PSK (along with a related PSK Identity) that is created by the TLS subsystem and/or application, for use with resumption 🔁

3. Justification of PSK 💭

TLS deployments mostly rely on certificates for most common uses. But we get that it can be hard to fully upgrade client implementations so they can use certificates with RADIUS/TLS and RADIUS/DTLS 😩 That upgrade doesn't just mean implementing TLS. It can also mean big changes to administration interfaces and application programming interfaces (APIs) so certificates are properly supported 🛠️

Certificates also have a sneaky problem: unlike shared secrets, they expire. That means a working TLS system can suddenly stop working 💀 Managing that expiration can require extra notification APIs on RADIUS clients and servers, which weren't needed when shared secrets were the only option 🔔

Certificates also need certification authorities (CAs) and chains of certificates. So RADIUS implementations using TLS have to track not just one small shared secret, but potentially lots of big certificates 📚 That's why TLS-PSK can offer a simpler upgrade path for implementations moving from RADIUS shared secrets to TLS 🦋

When it comes to ongoing maintenance, servers are generally simpler to look after than clients. For one thing, there are way fewer servers than clients. Servers also tend to have more resources, often run on general-purpose operating systems, and can have their maintenance automated with widely available tools 🖥️✨

Clients are the opposite: they're often numerous, resource constrained, and likely to be closed or proprietary systems with limited interfaces 🥲 Because of that, it can be really hard to update these clients when a root CA expires. So TLS-PSK in an environment like that may offer real management efficiencies 🌈

4. General Discussion of PSKs and PSK Identities 🎀

Before we define any RADIUS-specific use of PSKs, we have to look at the current standards for PSKs and give some general advice on PSKs and PSK Identities 🧐

The requirements in this section apply to both client and server implementations that use TLS-PSK. Client-specific and server-specific issues get covered in more detail later in the doc 👑

4.1. Guidance for PSKs 🔐

We'll start with requirements for creating and managing PSKs, then move on to usability guidance, and finish with a discussion of RADIUS shared secrets and how they interact with PSKs 💖

4.1.1. PSK Requirements ✨

Okay so bestie, reusing one PSK across multiple TLS versions (like TLS 1.2 and TLS 1.3) is considered unsafe 💀 (see [RFC8446], Appendix E.7). The reason is that TLS 1.3 ties the PSK to a particular key derivation function (KDF), but TLS 1.2 doesn't. So you could use the same PSK with different hashes and end up attacking it by comparing the hash outputs 🙈. Are there known insecurities? Nope! But these uses aren't known to be secure either, so they should be avoided, periodt 💅.

So an implementation MUST NOT use the same PSK for TLS 1.3 and for earlier versions of TLS 🚫. How you enforce that is up to the implementation 🎀. One option is to have two different PSKs. Another is to forbid TLS versions less than TLS 1.3.

[RFC9258] adds a KDF to the import interface of (D)TLS 1.3, which binds the externally provided PSK to the protocol version 🦋. That's preferred over any trust-on-first-use (TOFU) mechanism, no cap. Here's how that document puts it:

... 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.

Going over it once more because it's important 🔥: an implementation MUST NOT use the same PSK for TLS 1.3 and for earlier versions of TLS. This stops a PSK from being reused across multiple TLS versions, which blocks the attacks covered in [RFC8446], Appendix E.7 🛡️. Again, the enforcement is implementation-specific, with the same two options: two different PSKs, or forbidding TLS versions below TLS 1.3.

Implementations MUST follow the directions of [RFC9257], Section 6 for using external PSKs in TLS 📖. That document is seriously useful for generating and using PSKs, so go read it 🌸.

Implementations MUST support PSKs of at least 32 octets in length, and SHOULD support PSKs of 64 octets or more ✨. Here's the thing: PSKs get hashed before they're used in TLS, so the useful entropy is capped by the hash output size, which can be 256, 384, or 512 bits 🧚. Still, it's good practice to let people enter PSKs longer than 64 octets, since a PSK might not be bare binary data 💖. Implementations that cap PSKs at 64 octets will probably end up with PSKs that have way less than 512 bits of entropy 😭. So a high-entropy PSK might get expanded with some construct (like base32, see Section 4.1.2) to make it easier for humans to handle 🍓. If 512 bits of entropy go into an encoding construct, the output can be bigger than 64 octets 🌈.

Implementations MUST require that PSKs be at least 16 octets in length 🙅. Short PSKs MUST NOT be permitted, and PSKs MUST be random 🎲. Length isn't what makes a PSK strong, though. Strength comes from how many bits of entropy it actually has 💪. People are bad at making high-entropy data by hand, so a source of cryptographically secure random numbers MUST be used 🔐.

Passwords are meant to be remembered and typed in over and over, but PSKs are entered once and then saved in a system configuration automatically 🧠. Passwords have limited entropy, so they aren't acceptable for TLS-PSK. They'd only work with a password-authenticated key exchange (PAKE) TLS method [RFC8492] 🤝. So implementations MUST support entry and storage of PSKs as undistinguished octets 🫶.

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

Servers might be tempted to run a TOFU policy with clients 🙈. That behavior is NOT RECOMMENDED ❌. When a server gets a connection from an unknown client, it SHOULD log the PSK Identity, the source IP address, and any other relevant info 📝. That way an administrator can check the logs later and decide what to do 👑.

4.1.2. Usability Guidance 🎀

PSKs in their purest form are opaque tokens, just an undistinguished series of octets 🔢. If scripts are managing PSKs automatically, that format is totally fine 🤖. But sometimes administrators have to share PSKs by hand, and then human-readable formats help a lot 🌸. Implementations SHOULD support entering PSKs as both binary data and in a human-readable form like hex encoding 💅.

Implementations SHOULD use a human-readable form of PSKs for interfaces people use directly, and SHOULD allow binary data to be entered through an application programming interface (API) 🧚. Implementations SHOULD also let PSKs be displayed in the hex encoding above, so admins can manually verify which PSK is actually being used 🔍.

When using PSKs, administrators SHOULD use PSKs of at least 24 octets that are generated with a source of cryptographically secure random numbers ✨. Implementers who need a secure random number generator should check [RFC8937] for more guidance 📖. PSKs aren't passwords, so administrators should not try to make them up manually 🙅‍♀️.

To guide implementers and administrators, here are example commands that generate random PSKs from a locally secure source 🦋. Some commands might not work on every system, but one of them should 💖. The goal is a concise, simple example of making PSKs that are both secure and human-manageable 🌈. This document does not mandate that PSKs follow this format or any other format 🫶.

openssl rand -base64 16

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 | (hexdump -ve '/1 "%02x"' && echo)

Only run one of the above commands, no need to run them all 🙃. Each command reads 128 bits (16 octets) of random data from a secure source and encodes it as printable, readable ASCII 🍓. This form of PSK will be accepted by any implementation that supports at least 32 octets for PSKs ✨. Want a bigger PSK? Just change the "16" to a larger value 💪. The derivation above assumes the random source returns one bit of entropy for every bit of randomness it returns 🧠. Sources that don't meet that assumption are NOT RECOMMENDED ⚠️.

4.1.3. Interaction Between PSKs and RADIUS Shared Secrets 🔐

Any shared secret used for RADIUS/UDP or RADIUS/TLS MUST NOT be used for TLS-PSK 🚫. Like, never ever 💀.

It is RECOMMENDED that RADIUS clients and servers track all shared secrets and PSKs they use, and then verify that the following requirements all hold true 📋:

  • no shared secret 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

Note that the shared secret of "radsec" given in [RFC6614] can be used across multiple clients, because that value is mandated by the specification 🙌. The point here is to recommend best practices for admins who enter site-local shared secrets 🏠.

There may be use cases for using one shared secret across multiple RADIUS clients 🤷‍♀️. There may similarly be use cases for sharing a PSK across multiple RADIUS clients 🫂. Details of the possible attacks on reused PSKs are in [RFC9257], Section 4.1 📖.

There are no known use cases for using a PSK as a shared secret, or vice versa 🙅.

Implementations MUST reject configuration attempts that try to use the same value for the PSK and the shared secret 🛑. To prevent admin mistakes, implementations should not have interfaces that mix up PSKs and shared secrets, or that let both be entered at the same time 🫣. There's way too much temptation for admins to type the same value into both fields, which would break the limits above 😭. Similarly, using a "shared secret" field to enter PSKs is bad practice 🙈. PSK entry fields need to be labeled as PSK fields, not shared secret fields 🏷️✨.

4.2. PSK Identities 🎀

okay so bestie, [RFC4279], Section 5.1 says PSK Identities have to be encoded in UTF-8 format. 😭 But then [RFC8446], Section 4.2.11 describes the "Pre-Shared Key Extension" and defines the ticket as an opaque string: "opaque identity<1..2^16-1>;". That PSK then gets used in [RFC8446], Section 4.6.1 for resumption. Two specs, two different vibes, and that's a whole mess 💀

These definitions appear to be in conflict. The conflict gets handled in [RFC9257], Section 6.1.1, which talks about the rules for encoding and comparing PSK Identities. Systems MUST follow the directions of [RFC9257], Section 6.1.1 when using or comparing PSK Identities for RADIUS/TLS. Implementations MUST follow the recommendations of [RFC8265] for handling PSK Identity strings. No skipping this part 🙅‍♀️

In general, implementers should allow external PSK Identities to follow [RFC4279] and be UTF-8, while PSK Identities that get provisioned as part of resumption are automatically provisioned, so they follow [RFC8446]. Two lanes, both valid 🦋

Note that the PSK Identity is sent in the clear, which means attackers can see it 👀 Where privacy matters, the PSK Identity could be either an opaque token generated cryptographically, or maybe 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 the client is associated with example.com, then using that domain name in the PSK Identity gives them zero new info. The "user" portion, though, needs to be both unique to the client and private, so an opaque token is the more secure move 🔐

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. Length goals, but make it make sense 💅

It is up to administrators and implementations to decide how they tell external PSK Identities apart from session resumption PSK Identities used in TLS 1.3 session tickets. While [RFC9257], Section 6.1.2 suggests the identities should be unique, it offers no concrete steps for how that differentiation may be done. Not gonna lie, that's a bit of a cliffhanger 🙈

One approach could be to have externally provisioned PSK Identities contain an NAI like the one described above, while session resumption PSK Identities contain large blobs of opaque, encrypted, and authenticated text. It should then be relatively straightforward to tell the two types apart. One is UTF-8, the other is not. One is unauthenticated, the other is authenticated. Iconic contrast, honestly ✨

Servers MUST assign and/or track session resumption PSK Identities in a way that facilitates the ability to distinguish those identities from externally configured PSK Identities, and that enables them to both find and validate the session resumption PSK. See Section 6.2.3 below for more discussion of issues around resumption. Main character energy for the resumption stuff 🎬

A sample validation flow for TLS-PSK Identities could be performed with 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 [RFC8446], Section 4.6.1, such as by
    setting one octet to 0x00.

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

    5.1.  If yes, it searches for a preconfigured client that matches
          that identity.

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

          5.1.2.  Else, the identity is invalid, and the server
                  closes the connection.

    5.2.  If not, try resumption, which is usually handled by a TLS
          library.

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

          5.2.2.  Else, the server ignores the session ticket, and
                  performs a normal TLS handshake with a certificate.

This validation flow is only suggested. Other validation methods are possible. Choose your own adventure 🧚

4.2.1. Security of PSK Identities 🔒

We note that the PSK Identity is a field created by the connecting client. Since the client is untrusted until both the identity and 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 UTF-8 format, due to the requirements of [RFC4279], Section 5.1. However, implementations MUST support managing PSK Identities as a set of undistinguished octets. Trust nobody, not even the identity 🫶

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 invalid or malicious data. For example, the identity may:

  • have an incorrect UTF-8 format,
  • contain data that forms an injection attack for SQL, the Lightweight Directory Access Protocol (LDAP), Representational State Transfer (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. Yikes, that's a lot of octets 😭

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 (e.g., database lookup), implementations MUST either escape any characters in the identity that are invalid for that API, or else reject the identity entirely. The exact form of any escaping depends on the API, and we cannot document all possible methods here. However, a few basic validation rules are suggested, as outlined below. Any identity that is rejected by these validation rules MUST cause the server to close the TLS connection. Bye bye, bad vibes 👋

The suggested validation rules for identities used outside of resumption are as follows:

  • Identities MUST be checked to see if they have been provisioned as a resumption PSK. If so, then the session can be resumed, subject to any policies around resumption.
  • Identities longer than a fixed maximum SHOULD be rejected. The limit is implementation dependent, but SHOULD NOT be less than 128, and SHOULD NOT be more than 1024. There is no purpose to allowing extremely long identities, and allowing them does little more than complicate implementations. Why would you even 🙄
  • Identities configured by administrators SHOULD be in UTF-8 format, and SHOULD be in the NAI format from [RFC7542]. While [RFC8446], Section 4.2.11 defines the PSK Identity as "opaque identity<1..2^16-1>", it is useful for administrators to manage human-readable identities in a recognizable format.

This suggestion makes it easier to tell TLS-PSK Identities apart from TLS 1.3 resumption identities. It also helps implementations filter out unexpected or bad identities, and then close inappropriate TLS connections. Filtering arc unlocked 🧹

It is RECOMMENDED that implementations extend these rules with any additional validation that is found to be useful. For example, implementations and/or deployments could both generate PSK Identities in a particular format for passing to client systems, and then also verify that any received identity matches that format. For example, a site could generate PSK Identities that are composed of characters in the local language. The site could then reject identities that contain characters from other languages, even if those characters are valid UTF-8. Custom bouncer energy 💅

The purpose of these rules is to help administrators and implementers more easily manage systems using TLS-PSK, while also minimizing complexity and protecting against potential attackers' traffic. The rules follow a principle of "discard bad traffic quickly," which helps improve system stability and performance. Honestly iconic, discard the trash fast 🗑️✨

4.3. PSK and PSK Identity Sharing 🍓

While administrators may want 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. Sharing is caring, except when it's not 🙃

Implementations MUST support the ability to configure a unique PSK and PSK Identity for each possible client-server relationship. This configuration allows administrators who want security to use unique PSKs for each such relationship. It is also compatible with administrators who wish to reuse PSKs and PSK Identities where local policies permit. Flexible, unbothered, lowkey perfect 🌈

Implementations SHOULD warn administrators if the same PSK Identity and/or PSK is used for multiple client-server relationships. Warning bell, ding ding 🔔

4.4. PSK Lifetimes ⏳

Unfortunately, [RFC9257] offers no guidance on PSK lifetimes other than to note in Section 4.2 that:

Forward security may be achieved by using a PSK-DH mode or by using PSKs with short lifetimes.

It is RECOMMENDED that PSKs be rotated regularly. We offer no additional guidance on how often this process should occur. Changing 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 the cost of a potential PSK compromise. It's a balancing act, bestie ⚖️

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 compromise of a PSK would allow an attacker to decrypt all sessions that had used that PSK. Forward secrecy is non-negotiable, no cap 🚫

As the PSKs are looked up by identity, the PSK Identity MUST also be changed when the PSK changes. Rotate both or nothing 🔄

Servers SHOULD track when a connection was last received for a particular PSK Identity, and SHOULD automatically invalidate credentials when a client has not connected for an extended period of time. This process helps mitigate the issue of credentials being leaked when a device is stolen or discarded. Ghost accounts get cleaned up, periodt 🧹💜

5. Guidance for RADIUS Clients 📡

Client implementations MUST allow the use of a Pre-Shared Key (PSK) for RADIUS/TLS. The client implementation can then provide a user interface flag that is "TLS yes / no", and also provide fields that ask for the PSK Identity and PSK itself. Give the people a toggle 🎛️

For TLS 1.3, implementations MUST support the "psk_dhe_ke" PSK Exchange Mode as discussed in [RFC8446], Section 4.2.9 and in [RFC9257], Section 6. Implementations MUST implement the 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 these recommendations, we give the following recommendations:

  • Implementations SHOULD use the "Recommended" cipher suites listed in the IANA "TLS Cipher Suites" registry:
    • For TLS 1.3, use the "psk_dhe_ke" PSK key exchange mode.
    • For TLS 1.2 and earlier, use cipher suites that require ephemeral keying.

If a client initiated a connection using a PSK with TLS 1.3 by including the PSK extension, it MUST close the connection if the server did not also select the PSK to continue the handshake. No half-finished handshakes allowed 🙅‍♀️💖

5.1. PSK Identities 🌸

This section offers advice on both requirements for PSK Identities and on usability. Let's get into it ✨

5.1.1. PSK Identity Requirements 🎀

okay so [RFC6614] is totally silent on PSK Identities 😭 which is lowkey a whole problem, and this doc is here to fix it bestie 💅 we need guidance on them because managing the identities tied to PSKs is a brand new job for both Network Access Server (NAS) management interfaces AND 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. no cap, that's the baseline ✨

now the historic ways of signing RADIUS packets haven't been broken yet 👀 but they're believed to be way less secure than modern TLS, so it's giving "do not mix these" energy 🙈 so 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. like, if you reused the secrets, an attack on the old RADIUS crypto could be trivially leveraged to decrypt TLS-PSK sessions 💀 not me reusing secrets lol

also, 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 🌸

5.1.2. Usability Guidance 💖

okay so to stop people mixing up shared secrets and TLS-PSKs 😭, management interfaces and APIs need to label PSK fields as "PSK" or "TLS-PSK", rather than as "shared secret". clear labels = happy admins 🫶

6. Guidance for RADIUS Servers 👑

okay main character moment: in order to support clients with TLS-PSK, server implementations MUST 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 share or reuse PSK Identities between incoming and outgoing connections 🙅‍♀️ doing that would open them up to attack, as discussed in [RFC9257], Section 4.1. not the vibe 💀

for TLS 1.3, implementations MUST support the "psk_dhe_ke" PSK Exchange Mode as discussed in [RFC8446], Section 4.2.9 and in [RFC9257], Section 6. implementations MUST also implement the recommended cipher suites in [RFC9325], Section 4.2 for TLS 1.2 and in [RFC8446], Section 9.1 for TLS 1.3. to future-proof all this, we give the following recommendations ✨

  • Implementations SHOULD use the "Recommended" cipher suites listed in the IANA "TLS Cipher Suites" registry:
    • For TLS 1.3, use the psk_dhe_ke PSK key exchange mode.
    • For TLS 1.2 and earlier, use cipher suites that require ephemeral keying.

the next sections are about guidance for RADIUS server implementations and deployments 🧚 first we'll go over current practices, and then we'll extend and/or replace those for TLS-PSK 💅

6.1. Current Practices 🍓

okay so RADIUS identifies clients by source IP address (see [RFC2865] and [RFC6613]) or by client certificate (see [RFC6614] and [RFC7585]). neither of those works for TLS-PSK 😭 this section describes current practices and mandates behavior for servers that use TLS-PSK.

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

so basically the IP address is treated as the client's identity, and the shared secret proves the client's authenticity and shared trust 🦋 the set of clients forms a logical database "client table" with the IP address as the key. iconic table energy 💜

a server may also have extra site-local policies tied to that client. for example, a client might be marked as a Wi-Fi Access Point, a VPN concentrator, etc. 📡 different clients can be allowed to send different kinds of requests: some may send Accounting-Request packets, and others may not send accounting packets at all 🌈

6.2. Practices for TLS-PSK 🌸

we define practices for TLS-PSK by analogy with the RADIUS/UDP use case, and by extending the extra policies tied to 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 being transported. so the RADIUS data inside a TLS tunnel is the same whether client authentication is done via PSK or by client certificates 💖 the encoding of the RADIUS data is totally unaffected by whether PSKs or client certificates are used (or not) 🫶

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 suggesting that RADIUS servers let ANY source IP address connect and try TLS-PSK, which could be a real security risk 😬 when RADIUS servers don't do any source IP address filtering, it's way easier for attackers to send malicious traffic to the server. a bug in a TLS library or even a TCP/IP stack could let an attacker gain unwarranted access 💀 but when IP address filtering is done, attackers generally have to first get into a secure network before they can even attack the RADIUS server 🔥

even where dynamic discovery [RFC7585] isn't used, using TLS-PSK across unrelated organizations means those organizations have to share PSKs. that sharing makes it easier for a client to impersonate a server, and vice versa 😭 with certificates, those impersonations are impossible. so it is NOT RECOMMENDED to use TLS-PSK across organizational boundaries 🚫

when TLS-PSK is used in an environment where both client and server are part of the same organization, then impersonations only affect that organization 🏠 and since TLS has big advantages over RADIUS/UDP, it is RECOMMENDED that organizations use RADIUS/TLS with TLS-PSK to replace RADIUS/UDP for all systems managed within the same organization ✨ those systems are generally inside private networks, but there are no known security issues with using TLS-PSK for RADIUS/TLS connections across the public Internet 🌍

⚠️ if a client system gets compromised, its complete configuration is exposed to the attacker. exposing a client certificate means the attacker can pretend to be the client. but exposing a PSK means the attacker can NOT ONLY pretend to be the client, but ALSO pretend to be the server 😱😱 this is the scary part bestie, so handle PSKs with care 🔐

so the main benefit of TLS-PSK is that its operational processes are similar to what's used for managing RADIUS/UDP, while gaining the extra security of TLS 🎀 however, it's still beneficial for servers to do IP address filtering, to further limit their exposure to attacks 🛡️

6.2.1. IP Filtering 🦋

okay this is the bit where servers get strict 😤 a server supporting this specification MUST perform IP address filtering on incoming connections. there are very few good reasons for a server to have a default configuration that allows connections from any source IP address 🙅‍♀️

a TLS-PSK server MUST be configurable with a set of "allowed" network ranges that clients are permitted to connect from. any connection from outside the allowed range(s) MUST be rejected before any PSK Identity is checked 🚪 it is RECOMMENDED that servers support IP address filtering even when TLS-PSK is NOT used too 💜

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. the goal is to let connections be filtered by source IP address, and to let clients be limited to a subset of network addresses ✨ exactly how that filtering is done and represented is up to each implementation 🧚

conceptually, the set of IP addresses and ranges, along with permitted clients and their credentials, form a logical "client table" that the server uses to both filter AND authenticate clients 🗂️ the client table should contain info such as allowed network ranges, PSK Identity and associated PSK, credentials for another TLS authentication method, or flags that tell the server it should require a client certificate 🔑

once a server gets a connection, it checks the source IP address against the list of all allowed IP addresses or ranges in the client table. if none match, the connection MUST be rejected. in other words, the connection MUST come from an authorized source IP address 🚫

once a connection has been established, the server MUST NOT process any application data inside the TLS tunnel until the client has been authenticated 🙅‍♀️ instead, the server normally receives a TLS-PSK Identity from the client, and then uses that identity to look up the client in the client table. if there's no matching client, the server MUST close the connection. then the server also checks whether this client definition allows this particular source IP address. if the source IP address isn't allowed, the server MUST close the connection 💅

where the server doesn't receive TLS-PSK from the client, it moves on to another authentication method, like client certificates 🔐 those requirements are discussed elsewhere, most notably in [RFC6614] and [RFC7360] 📚

an implementation may do two independent IP address lookups: first to check whether the connection is allowed at all, and second to check whether the connection is authorized for this particular client 🔍 one or both checks may be used by a particular implementation. the two sets of IP addresses can overlap, and implementations SHOULD support that capability 🫶

depending on the implementation, one or more clients may share a list of allowed network ranges 🌈 alternatively, the allowed network ranges for two clients can overlap only partially, or not at all. ALL of these possibilities MUST be supported by the server implementation 👑

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. the server could then discard any TLS connection request coming from a source IP address outside that network 🗑️ in that case, there's no need to examine the PSK Identity or find the client definition. the IP source filtering policy just denies the connection before any TLS communication has happened 🙅‍♀️

some clients may have dynamic IP addresses, so it's possible for one PSK Identity to show up from different source IP addresses over time 🔄 also, since there may be lots of clients behind one NAT gateway, there may be multiple RADIUS clients sharing one public IP address 🏠 so RADIUS servers MUST support multiple PSK Identifiers at one source IP address 💖

basically 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, no debate 💅

the following section describes these requirements in more detail 📖

6.2.2. PSK Authentication ✨

Okay, so once the server has checked that the source IP address is allowed for this particular client, it authenticates the TLS connection using the PSK from that client's definition. If the PSK checks out ✅, the server accepts the connection and carries on with RADIUS/TLS as per [RFC6614].

If the PSK doesn't verify, the server MUST close the connection. TLS can fall back to other auth methods like client certificates, but there's zero reason for a client to be set up with multiple auth methods at once 💅

A client MUST use only one authentication method for TLS. That's either TLS-PSK, client certificates, or some other method TLS supports. Pick one and commit, bestie 🫶

Client config is honestly pretty chill: use one set of credentials to log in to one server. Clients can talk to multiple servers and do fail-over or load-balancing, but that setup is mostly separate from which credentials you choose 🦋

6.2.3. Resumption 🔁

It is NOT RECOMMENDED that servers enable resumption for sessions that use TLS-PSK. Real talk, there are very few practical perks and a whole lot of complexity 😭

BUT some systems need TLS-PSK and other TLS-based auth like certificates, and session resumption. So it's vital for servers to tell apart TLS-PSK with preconfigured identities from TLS-PSK that's being used for resumption 🎀

The stuff above about PSK Identities gets messy because TLS 1.3 uses PSKs for resumption too. A server that gets a PSK Identity over TLS usually can't ask the TLS layer whether it's for a resumed session (which could be for some other TLS auth method) or a static pre-provisioned identity. That confusion makes server implementations way harder 🙃

One way to spot the difference is by construction. Resumption identities can use a fixed format, like the one recommended in [RFC8446], Section 4.6.1. A static pre-provisioned identity could be in the format of an NAI, as given in [RFC7542]. So an implementation can look at the incoming identity and figure out what kind of authentication is happening, just from the identity itself 🔍

Another option is to keep two tables. One holds the static identities (the logical client table from earlier), and the other holds the identities handed out for resumption. The server looks up any PSK Identity in one table, and if it's not there, it checks the other. If the identity shows up in a table, it can be authenticated. If it's in neither table, it's unknown, and the server MUST close the connection 💀

As suggested in [RFC8446], TLS-PSK peers MUST NOT store resumption PSKs or tickets (and associated cached data) for longer than 604800 seconds (7 days), regardless of the PSK or ticket lifetime. Set a reminder, babe ⏰

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. The extra complexity comes with minimal extra benefits, so why bother? 🙅‍♀️

Where resumption is allowed with TLS-PSK, systems MUST cache data during the initial full handshake, enough to make authorization decisions during resumption. If that cached data can't be retrieved securely, resumption MUST NOT be done. Instead, the system MUST perform a full handshake 🛡️

The data that needs caching is typically things like the original PSK Identity, plus any policies tied to that identity 📦

Here's where it gets spicy 🌶️ Information from the original TLS exchange (like the original PSK Identity) and related info (like source IP addresses) may change between the initial full handshake and resumption. That change creates a "time-of-check time-of-use" (TOCTOU) security vulnerability. A malicious or compromised client could send one set of data during the initial authentication and a different set during resumption, potentially getting access they shouldn't have 😈

So if any authorization or policy decisions were made using information that has since changed between the initial full handshake and resumption, and if those changes could lead to a different decision, such decisions MUST be reevaluated. Systems MUST also reevaluate authorization and policy decisions during resumption, based on the information given in the new connection. Servers MAY refuse to perform resumption where the information supplied during resumption doesn't match the information supplied during the original authentication. If a safe decision isn't possible, servers MUST instead continue with a full handshake 🚦

6.2.4. Interaction with Other TLS Authentication Methods 🤝

When a server supports both TLS-PSK and client certificates, it MUST be able to accept authenticated connections from clients that may use either type of credentials, perhaps even from the same source IP address and at the same time. Servers are required to both authenticate the client and filter clients by source IP address. Both checks have to match before a client gets accepted. Double-check energy, always 👑

7. Privacy Considerations 🌸

We make no changes to [RFC6614] and [RFC7360]. Nothing new to see here, the privacy story stays the same 🫧

8. Security Considerations 🚨

The primary focus of this document is addressing security considerations for RADIUS. Okay, serious voice on, this section matters 🧐

Previous specifications discuss security considerations for TLS-PSK in detail. We refer the reader to Appendix E.7 of [RFC8446], [RFC9257], and [RFC9258]. Those documents are newer than [RFC6614] and [RFC7360], so they raise issues that weren't considered during the initial design of RADIUS/TLS and RADIUS/DTLS. Old design, new problems 📜

Using TLS-PSK across the wider Internet for RADIUS can have different security considerations than it does for other protocols. For example, if TLS-PSK were used for client/server communication with HTTPS, then a PSK being exposed or broken could affect one user's traffic. RADIUS, on the other hand, carries credentials and personally identifiable information (PII) for many users. So if an attacker could see inside a TLS-PSK connection for RADIUS, you'd get a massive leak of PII, possibly including passwords. That's a full-on disaster 😭🔥

When modes providing forward secrecy are used (for example, ECDHE_PSK as seen in [RFC5489] and [RFC8442]), such attacks are limited to future sessions, and historical sessions are still secure. Forward secrecy is the glow-up we need 💜

9. IANA Considerations 🧚

This document has no IANA actions. Nothing to register here, no registry drama ✨

10. References 📚

10.1. Normative References

10.2. Informative References

Acknowledgments 🫶

Huge thanks to the many reviewers in the RADEXT Working Group for their positive feedback. You all are iconic 🌈

Author's Address 🦋

Alan DeKok

InkBridge Networks

Email: alan.dekok@inkbridge.io

📦 where this page comes from