RFC 7360

Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS

📅 published September 2014, from ietf

RFC 7360: DTLS as a Transport Layer for RADIUS 🎀

Okay bestie, let's talk about RFC 7360, titled Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS. It was written by A. DeKok from FreeRADIUS 🧚 It's in the Experimental category, dated September 2014, with ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so it's standing on its own, no drama 💅

Table of Contents

   1. Introduction ....................................................4
      1.1. Terminology ................................................5
      1.2. Requirements Language ......................................5
      1.3. Document Status ............................................5
   2. Building on Existing Foundations ................................6
      2.1. Changes to RADIUS ..........................................7
      2.2. Similarities with RADIUS/TLS ...............................8
           2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ..............8
   3. Interaction with RADIUS/UDP .....................................9
      3.1. DTLS Port and Packet Types ................................10
      3.2. Server Behavior ...........................................10
   4. Client Behavior ................................................11
   5. Session Management .............................................12
      5.1. Server Session Management .................................12
           5.1.1. Session Opening and Closing ........................13
      5.2. Client Session Management .................................15
   6. Implementation Guidelines ......................................16
      6.1. Client Implementations ....................................17
      6.2. Server Implementations ....................................18
   7. Diameter Considerations ........................................18
   8. IANA Considerations ............................................18
   9. Implementation Status ..........................................18
      9.1. Radsecproxy ...............................................19
      9.2. jradius ...................................................19
   10. Security Considerations .......................................19
      10.1. Crypto-Agility ...........................................20
      10.2. Legacy RADIUS Security ...................................21
      10.3. Resource Exhaustion ......................................22
      10.4. Client-Server Authentication with DTLS ...................22
      10.5. Network Address Translation ..............................24
      10.6. Wildcard Clients .........................................24
      10.7. Session Closing ..........................................25
      10.8. Client Subsystems ........................................25
   11. References ....................................................26
      11.1. Normative References .....................................26
      11.2. Informative References ...................................27
   Acknowledgments ...................................................27

Abstract

Okay so the RADIUS protocol from RFC 2865 has pretty limited support for authentication and encryption of RADIUS packets, which is lowkey a problem 😭 The protocol sends data in the clear, although some parts of the packets can have obfuscated content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can coexist with current RADIUS systems 🦋

Status of This Memo

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. So it's a test drive, not a finished product 🌸

This document defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741 ✨

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7360.

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License 💜

1. Introduction ✨

Okay, so the RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], and others has traditionally used methods based on MD5 [RFC1321] for per-packet authentication and integrity checks. However, the MD5 algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. As a result, some specifications, such as [RFC5176], have recommended using IPsec to secure RADIUS traffic 🔐

While RADIUS over IPsec has been widely deployed, there are difficulties with this approach. The simplest point against IPsec is that there is no straightforward way for an application to control or monitor the network security policies. That is, the requirement that the RADIUS traffic be encrypted and/or authenticated is implicit in the network configuration, and it cannot be enforced by the RADIUS application. Literally the app can't check its own security, which is so not it 💀

This specification takes a different approach. We define a method for using DTLS [RFC6347] as a RADIUS transport protocol. This approach has the benefit that the RADIUS application can directly monitor and control the security policies associated with the traffic that it processes. The app gets to be in charge, main character energy 👑

Another benefit is that RADIUS over DTLS continues to be a UDP-based protocol. The change from RADIUS/UDP is largely to add DTLS support, and make any necessary related changes to RADIUS. This allows implementations to remain UDP based, without changing to a TCP architecture 🌈

This specification does not, however, solve all of the problems associated with RADIUS/UDP. The DTLS protocol does not add reliable or in-order transport to RADIUS. DTLS also does not support fragmentation of application-layer messages, or of the DTLS messages themselves. This specification therefore shares with traditional RADIUS the issues of order, reliability, and fragmentation. These issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS [RFC6614]. So not everything gets fixed here, but the other specs have it covered 🫶

1.1. Terminology

This document uses the following terms:

RADIUS/DTLS This term is a shorthand for "RADIUS over DTLS".

RADIUS/DTLS client This term refers both to RADIUS clients as defined in [RFC2865] and to Dynamic Authorization clients as defined in [RFC5176] that implement RADIUS/DTLS.

RADIUS/DTLS server This term refers both to RADIUS servers as defined in [RFC2865] and to Dynamic Authorization servers as defined in [RFC5176] that implement RADIUS/DTLS.

RADIUS/UDP RADIUS over UDP, as defined in [RFC2865].

RADIUS/TLS RADIUS over TLS, as defined in [RFC6614].

silently discard This means that the implementation discards the packet without further processing. Bye packet 🙈

1.2. Requirements Language

In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These are the official capital-letter key words, so read them carefully 📜

1.3. Document Status

This document is an Experimental RFC.

It contains one of several approaches to address known cryptographic weaknesses of the RADIUS protocol, such as described in [RFC6614]. This specification does not fulfill all recommendations for an Authentication, Authorization, and Accounting (AAA) transport profile as per [RFC3539]; however, unlike [RFC6614], it is based on UDP and therefore does not have head-of-line blocking issues. It's giving "one option in a crowded field" 🍓

If this specification is indeed selected for advancement to Standards Track, certificate verification options ([RFC6614], Section 2.3, point 2) will need to be refined.

Another experimental characteristic of this specification is the question of key management between RADIUS/DTLS peers. RADIUS/UDP only allowed for manual key management, i.e., distribution of a shared secret between a client and a server. RADIUS/DTLS allows manual distribution of long-term proofs of peer identity, by using TLS-PSK ciphersuites. RADIUS/DTLS also allows the use of X.509 certificates in a PKIX infrastructure. It remains to be seen if one of these methods will prevail or if both will find their place in real-life deployments. The authors can imagine pre-shared keys (PSKs) to be popular in small-scale deployments (Small Office, Home Office (SOHO) or isolated enterprise deployments) where scalability is not an issue and the deployment of a Certification Authority (CA) is considered too much of a hassle; however, the authors can also imagine large roaming consortia to make use of PKIX. Readers of this specification are encouraged to read the discussion of key management issues within [RFC6421] as well as [RFC4107]. Two options, and the jury's still out, which is so relatable 🦋

It has yet to be decided whether this approach is to be chosen for Standards Track. One key aspect to judge whether the approach is usable on a large scale is by observing the uptake, usability, and operational behavior of the protocol in large-scale, real-life deployments. We'll see how it does in the wild ✨

2. Building on Existing Foundations 🌸

Adding DTLS as a RADIUS transport protocol requires a number of changes to systems implementing standard RADIUS. This section outlines those changes, and defines new behaviors necessary to implement DTLS. Think of it as the glow-up checklist for RADIUS 💖

2.1. Changes to RADIUS 💖

okay so the RADIUS packet format is totally unchanged from [RFC2865], [RFC2866], and [RFC5176] 🎀 same vibe, same bones. specifically, all of these parts of RADIUS MUST be unchanged when you're using RADIUS/DTLS:

  • Packet format
  • Permitted codes
  • Request Authenticator calculation
  • Response Authenticator calculation
  • Minimum packet length
  • Maximum packet length
  • Attribute format
  • Vendor-Specific Attribute (VSA) format
  • Permitted data types
  • Calculations of dynamic attributes such as CHAP-Challenge, or Message-Authenticator.
  • Calculation of "obfuscated" attributes such as User-Password and Tunnel-Password.

in short 🧚 the app makes a RADIUS packet the normal way, but instead of sending it over a UDP socket, it hands the packet to a DTLS layer to get wrapped up. DTLS then acts as the transport layer for RADIUS, which is why they're called "RADIUS/UDP" and "RADIUS/DTLS" 💅

keeping RADIUS mostly unchanged is giving simplest possible implementation and the widest interoperability ✨

ngl there's a catch 👀 DTLS wrapping means RADIUS packets carry some extra overhead. Implementations MUST support sending and receiving encapsulated RADIUS packets of 4096 octets in length, with a corresponding increase in the maximum size of the encapsulated DTLS packets. This bigger packet size may make the packet larger than the Path MTU (PMTU), where a RADIUS/UDP packet may be smaller. See Section 5.2, below, for more discussion.

the only changes from RADIUS/UDP to RADIUS/DTLS are these two things 🔥

(1) The Length checks defined in [RFC2865], Section 3, MUST use the length of the decrypted DTLS data instead of the UDP packet length. They MUST treat any decrypted DTLS data octets outside the range of the Length field as padding and ignore it on reception.

(2) The shared secret used to compute the MD5 integrity checks and the attribute encryption MUST be "radius/dtls".

everything else about RADIUS is unchanged 🌸

2.2. Similarities with RADIUS/TLS 🦋

so RADIUS/DTLS can be thought of as RADIUS/TLS but over UDP instead of the Transmission Control Protocol (TCP) 💜 there are still some differences between the two, though. The bulk of [RFC6614] applies to this spec, so we aren't repeating it here.

this section lays out the differences between RADIUS/TLS and RADIUS/DTLS as semantic "patches" to [RFC6614] 🍓 the changes are:

  • We replace references to "TCP" with "UDP"
  • We replace references to "RADIUS/TLS" with "RADIUS/DTLS"
  • We replace references to "TLS" with "DTLS"

those swaps cover most of the differences between the two specs 🫶 the next section goes through the more detailed changes from [RFC6614], and only adds commentary where it's actually needed.

2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ✨

this section explains how particular sections of [RFC6614] apply to RADIUS/DTLS 🎀

Section 2.1 applies to RADIUS/DTLS, except the RADIUS/DTLS port is UDP/2083.

Section 2.2 applies to RADIUS/DTLS. Servers and clients need to be pre-configured to use RADIUS/DTLS for a given endpoint.

Most of Section 2.3 applies to RADIUS/DTLS too. Item (1) should be read as applying to DTLS session initiation, instead of TCP connection establishment. Item (2) applies, except for the recommendation that implementations "SHOULD" support TLS_RSA_WITH_RC4_128_SHA. That recommendation is a historical artifact of RADIUS/TLS, so it doesn't apply to RADIUS/DTLS 💀 Item (3) applies to RADIUS/DTLS. Item (4) applies, except the fixed shared secret is "radius/dtls", as described above.

Section 2.4 applies to RADIUS/DTLS. Client identities SHOULD be determined from DTLS parameters, instead of relying solely on the source IP address of the packet 🙈

Section 2.5 does not apply to RADIUS/DTLS. The relationship between RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from RADIUS/UDP.

Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS.

Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS packet is encapsulated in one DTLS packet, and there is no "stream" of RADIUS packets inside of a TLS session 🧚 Implementors MUST enforce the requirements of [RFC2865], Section 3, for the RADIUS Length field, using the length of the decrypted DTLS data for the checks. This check replaces the RADIUS method of using the Length field from the UDP packet.

Section 3.4 items (2), (3), (4), and (5) apply to RADIUS/DTLS.

Section 4 does not apply to RADIUS/DTLS. Protocol compatibility considerations are defined in this document.

Section 6 applies to RADIUS/DTLS.

3. Interaction with RADIUS/UDP 🦋

okay this part is a big deal 😭 transitioning to DTLS has to be done carefully. A badly handled transition is a headache for administrators and can open the door to security downgrade attacks.

Simply disabling RADIUS/UDP and enabling RADIUS/DTLS is NOT enough. RADIUS has no provisions for protocol negotiation, so just turning off RADIUS/UDP would cause timeouts, lost traffic, and network instabilities. Bestie, do not skip this 💀

the end goal of this spec is that nearly all RADIUS/UDP implementations should move over to a secure alternative 🔥 In some cases RADIUS/UDP may stay around where IPsec is used as a transport, or where implementation and/or business reasons block a change.

however, we do not recommend long-term use of RADIUS/UDP outside of isolated and secure networks 🙅‍♀️

this section covers how clients and servers should use RADIUS/DTLS, and how it plays with RADIUS/UDP 💖

3.1. DTLS Port and Packet Types 🎀

the default destination port for RADIUS/DTLS is UDP/2083 ✨ there are no separate ports for authentication, accounting, and dynamic authorization changes. The source port is arbitrary. The text in [RFC6614], Section 3.4, talks about the issues that come with using one port for multiple packet types 🧠 We know implementations may let RADIUS/DTLS run over non-standard ports. In that case, the references to UDP/2083 in this document should be read as applying to any port used to transport RADIUS/DTLS traffic.

3.2. Server Behavior 💅

when a server receives packets on UDP/2083, all packets MUST be treated as DTLS. RADIUS/UDP packets MUST NOT be accepted on this port.

Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports. Early versions of this spec allowed that, but it's forbidden here, because it depended on DTLS behavior that might change without notice 🙅‍♀️

Servers MUST authenticate clients. RADIUS is built for mutually trusted systems 🫶 Allowing anonymous clients would keep RADIUS/DTLS traffic private, but it would cancel out every other security feature of the protocol 😭

RADIUS has no capability signaling, so there's no way for a server to tell a client it should switch over to DTLS 🌈 That has to be arranged by the administrators of the two systems, using something other than RADIUS. It'll probably be out of band, or manual configuration will be needed.

some servers keep a list of allowed clients per destination port. Others keep one global list of clients that can send packets to any port 🧚 when a client can send to multiple ports, the server MUST maintain a "DTLS Required" flag per client.

this flag says whether the client is required to use DTLS. When it's set, the only traffic accepted from that client is over UDP/2083. When packets come in from a client on non-DTLS ports, where DTLS is required, the server MUST silently discard them, because there's no RADIUS/UDP shared secret available 🔒

the flag is often set by an administrator 🎀 but if a server gets DTLS traffic from a client, it SHOULD notify the administrator that DTLS is available for that client. It MAY mark the client as "DTLS Required".

It is RECOMMENDED that servers support these Perfect Forward Secrecy (PFS) ciphersuites 🔐

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

letting RADIUS/UDP and RADIUS/DTLS run from the same client exposes the traffic to downbidding attacks, so it is NOT RECOMMENDED 💀

4. Client Behavior 🌸

when a client sends packets to the assigned RADIUS/DTLS port, all packets MUST be DTLS. RADIUS/UDP packets MUST NOT be sent to this port.

Clients MUST authenticate themselves to servers using credentials that are unique to each client 🫶

It is RECOMMENDED that clients support these PFS ciphersuites ✨

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

RADIUS/DTLS clients SHOULD NOT probe servers to see if they support DTLS transport 🙈 Instead, clients SHOULD use DTLS as a transport layer only when it's administratively configured. If a client is set up to use DTLS and the server seems unresponsive, the client MUST NOT fall back to RADIUS/UDP. Instead, the client should treat the server as being down 💀

RADIUS clients often had several independent RADIUS implementations and/or processes that send out packets. That was simple to build, but it means each independent subsystem must separately discover network issues or server failures 😭 So it is RECOMMENDED that clients with multiple internal RADIUS sources use a local proxy, as described in Section 6.1, below 🧚

clients may set up "pools" of servers for fail-over or load-balancing 🍓 These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS servers.

5. Session Management 🧠

where [RFC6614] can lean on the TCP state machine to track sessions, this spec can't 🫠 So implementations of this spec may need to manage the DTLS session in the application layer. This section describes logically how that tracking works. Implementations may choose this method or another, equivalent one 💖

we note that [RFC5080], Section 2.2.2, already mandates a duplicate detection cache 🎀 The session tracking below can be seen as an extension of that cache, where the entries hold DTLS sessions instead of RADIUS/UDP packets.

[RFC5080], Section 2.2.2, describes how duplicate RADIUS/UDP requests lead to a previously cached RADIUS/UDP response being sent again. Because of DTLS sequence window requirements, a server MUST NOT retransmit a previously sent DTLS packet 🙅‍♀️ Instead, it should cache the RADIUS response packet, and re-process it through DTLS to create a new RADIUS/DTLS packet, every time a RADIUS response has to be retransmitted ✨

5.1. Server Session Management ✨

okay bestie, this part is where the server keeps track of every single DTLS conversation 💖

A RADIUS/DTLS server MUST track ongoing DTLS sessions for each one, based on this 4-tuple 👑:

  • source IP address
  • source port
  • destination IP address
  • destination port

pls note that this 4-tuple doesn't care whether you're on IPv4 or IPv6 🌈

Each 4-tuple points to a unique session entry, which usually holds the following info:

  • DTLS Session: any info needed to maintain and manage the DTLS session.
  • Last Traffic: a variable with a timestamp showing when this session last received valid traffic. If Last Traffic isn't used, this variable may not exist.
  • DTLS Data: an implementation-specific variable that may hold info about the active DTLS session. This variable may be empty or nonexistent. This data will typically hold stuff like idle timeouts, session lifetimes, and other implementation-specific data 🧚

5.1.1. Session Opening and Closing 🦋

okay so session tracking is a DoS target because an attacker can forge UDP traffic super easily 😭. RADIUS/DTLS servers SHOULD use the stateless cookie tracking technique described in [RFC6347], Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a ClientHello packet has arrived with an appropriate Cookie value. A server implementation SHOULD have a way of tracking DTLS sessions that are partially set up. Servers MUST limit both the number and impact on resources of partial sessions 🛡️

Sessions (both 4-tuple and entry) MUST be deleted when a TLS Closure Alert ([RFC5246], Section 7.2.1) or a fatal TLS Error Alert ([RFC5246], Section 7.2.2) is received. When a session gets deleted because it failed security requirements, the DTLS session MUST be closed, any TLS session resumption parameters for that session MUST be discarded, and all tracking information MUST be deleted 💀

Sessions MUST also be deleted when a RADIUS packet fails validation because it's malformed, or when it has an invalid Message-Authenticator or invalid Request Authenticator. There are other cases where the specs require that a packet received via a DTLS session be "silently discarded". In those cases, implementations MAY delete the underlying session as described above. There are few reasons to talk to a Network Access Server (NAS) that isn't implementing RADIUS 🙈

A session MUST be deleted when non-RADIUS traffic is received over it. This spec is for RADIUS, and there's no reason to allow non-RADIUS traffic over a RADIUS/DTLS session. A session MUST be deleted when RADIUS traffic fails to pass security checks. There's no reason to permit insecure networks. A session SHOULD NOT be deleted when a well-formed, but "unexpected", RADIUS packet is received over it. Future specifications may extend RADIUS/DTLS, and we do not want to forbid those specifications 🌸

the goal here is security AND flexibility, both at once. iconic 👑

The goal of the above requirements is to ensure security, while maintaining flexibility. Any security-related issue causes the connection to be closed. After the security restrictions have been applied, any unexpected traffic may be safely ignored, as it cannot cause a security issue. There's no need to close the session for unexpected but valid traffic, and the session can safely stay open ✨

Once a DTLS session is established, a RADIUS/DTLS server SHOULD use DTLS Heartbeats [RFC6520] to check connectivity between the two servers. A server SHOULD also use watchdog packets from the client to confirm that the session is still active 💅

As UDP doesn't guarantee delivery of messages, RADIUS/DTLS servers that don't implement an application-layer watchdog MUST also maintain a "Last Traffic" timestamp per DTLS session. The granularity of this timestamp isn't critical and could be limited to one-second intervals. The timestamp SHOULD be updated on reception of a valid RADIUS/DTLS packet, or a DTLS Heartbeat, but no more than once per interval. The timestamp MUST NOT be updated in other situations 🦋

When a session hasn't received a packet for a while, it gets labeled "idle". The server SHOULD delete idle DTLS sessions after an "idle timeout". The server MAY cache the TLS session parameters so it can provide fast session resumption 🧚

This session "idle timeout" SHOULD be exposed to the administrator as a configurable setting. It SHOULD NOT be set to less than 60 seconds and SHOULD NOT be set to more than 600 seconds (10 minutes). The minimum useful value for this timer is determined by the application-layer watchdog mechanism defined in the following section ⏰

RADIUS/DTLS servers SHOULD also monitor the total number of open sessions. They SHOULD have a "maximum sessions" setting exposed to administrators as a configurable parameter. When this maximum is reached and a new session starts, the server MUST either drop an old session in order to open the new one or not create a new session 🍓

RADIUS/DTLS servers SHOULD implement session resumption, preferably stateless session resumption as given in [RFC5077]. This practice lowers the time and effort needed to start a DTLS session with a client and increases network responsiveness 🌈

Since UDP is stateless, the client could start a new DTLS session using a particular 4-tuple before the server has closed the old session. For security reasons, the server MUST keep the old session active until either it has received secure notification from the client that the session is closed or the server decides to close the session based on idle timeouts. Taking any other action would let unauthenticated clients pull off a DoS attack, by reusing a 4-tuple and making the server close an active (and authenticated) DTLS session 😤

As a result, servers MUST ignore any attempts to reuse an existing 4-tuple from an active session. This requirement can likely be met by just processing the packet through the existing session, the same way as any other packet received via that 4-tuple. Non-compliant or unexpected packets will be ignored by the DTLS layer 🫶

The above requirement gets helped along by the suggestion in Section 6.1, below, that the client use a local proxy for all RADIUS traffic. That proxy can then track the ports it uses and make sure 4-tuple reuse is avoided. The exact process for doing this tracking is outside the scope of this document 👑

5.2. Client Session Management 📱

Clients SHOULD use PMTU discovery [RFC6520] to determine the PMTU between the client and server, before sending any RADIUS traffic. Once a DTLS session is established, a RADIUS/DTLS client SHOULD use DTLS Heartbeats [RFC6520] to check connectivity between the two systems. RADIUS/DTLS clients SHOULD also use the application-layer watchdog algorithm defined in [RFC3539] to determine server responsiveness. The Status-Server packet defined in [RFC5997] SHOULD be used as the "watchdog packet" in any application-layer watchdog algorithm 🎀

RADIUS/DTLS clients SHOULD proactively close sessions when they've been idle for a while. Clients SHOULD close a session when the DTLS Heartbeat algorithm shows that the session is no longer active. Clients SHOULD close a session when no traffic other than watchdog packets and (possibly) watchdog responses has been sent for three watchdog timeouts. This behavior makes sure clients don't waste the server's resources by making it track idle sessions 💅

When a client fails to implement both DTLS Heartbeats and watchdog packets, it has no way of knowing that a DTLS session has been closed. So there's a chance the server closes the session without the client knowing. When that happens, the client may later send packets in that session, and the server will ignore them. The client is then forced to time out those packets and then the session, which leads to delays and network instabilities 😭

For these reasons, it is RECOMMENDED that all DTLS sessions be configured to use DTLS Heartbeats and/or watchdog packets 🫶

DTLS sessions MUST also be deleted when a RADIUS packet fails validation because it's malformed, or when it has an invalid Message-Authenticator or invalid Response Authenticator. There are other cases where the specs require that a packet received via a DTLS session be "silently discarded". In those cases, implementations MAY delete the underlying DTLS session 💀

RADIUS/DTLS clients should not send both RADIUS/UDP and RADIUS/DTLS packets to different servers from the same source socket. This practice adds complexity to the client application and raises the potential for security breaches due to implementation issues 🙈

RADIUS/DTLS clients SHOULD implement session resumption, preferably stateless session resumption as given in [RFC5077]. This practice lowers the time and effort needed to start a DTLS session with a server and increases network responsiveness ✨

6. Implementation Guidelines 🧚

The text above describes the protocol. In this section, we give some extra implementation guidelines. These guidelines aren't part of the protocol, but they may help implementors create simple, secure, and interoperable implementations 🌸

Where a TLS-PSK method is used, implementations MUST support keys of at least 16 octets in length. Implementations SHOULD support key lengths of 32 octets and SHOULD allow for longer keys. The key data MUST be capable of being any value (0 through 255, inclusive). Implementations MUST NOT limit themselves to using textual keys. It is RECOMMENDED that the administration interface allow the keys to be entered as human-readable strings in hex format 🍓

When creating keys for use with PSK ciphersuites, it is RECOMMENDED that keys be derived from a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) instead of administrators inventing keys on their own. If managing keys is too complicated, a certificate-based TLS method SHOULD be used instead 🌈

6.1. Client Implementations 💅

okay bestie, RADIUS/DTLS clients should use connected sockets where possible ✨ A connected socket means the kernel does the session tracking, so the client subsystem doesn't have to juggle multiple sessions on one socket 🧠

RADIUS/DTLS clients should use a single source (IP + port) when sending packets to a particular RADIUS/DTLS server. Doing this keeps the number of DTLS session setups down, and it also means the home server state only gets discovered once 🎯

In practice, clients with multiple internal RADIUS sources should run a local proxy that arbitrates all RADIUS traffic between the client and all servers 🧚 The proxy should accept traffic only from the authorized subsystems on the client machine, and it should proxy that traffic to known servers. Each authorized subsystem should include an attribute that uniquely identifies that subsystem to the proxy, so the proxy can apply origin-specific proxy rules and security policies. We suggest using NAS-Identifier for this 🫶

The local proxy should be able to interact with multiple servers at the same time. There is no requirement that each server have its own unique proxy on the client, because that would be inefficient 🙅‍♀️

Using a local proxy also means there is only one process that discovers network and/or connectivity issues with a server. If every client subsystem talked directly to a server, each subsystem would have to figure out those issues on its own. The side effect would be slower re-routing, slower error reporting, and more network instability 😭

Each client subsystem can include a subsystem-specific NAS-Identifier in each request. The format of this attribute is implementation-specific ✨ The proxy should verify that the request came from the local system, ideally via a loopback address. The proxy MUST then rewrite any subsystem-specific NAS-Identifier to a NAS-Identifier that identifies the client as a whole, or remove the NAS-Identifier entirely and replace it with NAS-IP-Address or NAS-IPv6-Address. This part is non-negotiable, no cap 🔥

In traditional RADIUS, setting up a new "session" between a client and server was super cheap. The client subsystem could just open a port, send a packet, wait for the response, and close the port 🦋 With RADIUS/DTLS, the connection setup is way more expensive. There may also be a requirement to use DTLS to talk to a server, since that server may not support RADIUS/UDP at all 👀 So the knowledge of which protocol to use is best handled by a dedicated RADIUS subsystem, not by every individual subsystem on the client. Main character energy for that one subsystem 👑

6.2. Server Implementations 🌸

RADIUS/DTLS servers should not use connected sockets to read DTLS packets from a client. Here's why: a connected UDP socket only accepts packets from one source IP address and port. That limit would stop the server from accepting packets from multiple clients on the same port 🙈

7. Diameter Considerations ✨

This specification defines a transport layer for RADIUS, and it makes no other changes to the RADIUS protocol. So there are no Diameter considerations, periodt 💖

8. IANA Considerations 📋

No new RADIUS attributes or packet codes are defined. IANA has updated the "Service Name and Transport Protocol Port Number Registry" 🧾 The entries for port service name radsec, port number 2083, and transport protocol UDP have been updated like this:

  • Assignee: IESG
  • Contact: IETF Chair
  • Reference: This document
  • Assignment Notes: The UDP port 2083 was already previously assigned by IANA for "RadSec", an early implementation of RADIUS/TLS, prior to issuance of this RFC.

9. Implementation Status 🧩

This section records the status of known RADIUS/DTLS implementations at the time of writing. It's based on a proposal described in [RFC6982] 🔍

The implementations described here are meant to help the IETF make decisions as it moves Internet-Drafts forward to RFCs 🚀

9.1. Radsecproxy 🍓

   Organization: Radsecproxy

   URL:       https://software.uninett.no/radsecproxy/

   Maturity:  Widely used software based on early versions of this
              document.
              The use of the DTLS functionality is not clear.

   Coverage:  The bulk of this specification is implemented, based on
              earlier versions of this document.  Exact revisions that
              were implemented are unknown.

   Licensing: Freely distributable with acknowledgment.

   Implementation experience: No comments from implementors.

9.2. jradius 💜

   Organization: Coova

   URL:       http://www.coova.org/JRadius/RadSec

   Maturity:  Production software based on early versions of this
              document.
              The use of the DTLS functionality is not clear.

   Coverage:  The bulk of this specification is implemented, based on
              earlier versions of this document.  Exact revisions that
              were implemented are unknown.

   Licensing: Freely distributable with requirement to redistribute
              source.

   Implementation experience: No comments from implementors.

10. Security Considerations 🔐

Okay, this section is serious business, so read it carefully 😭

Most of this specification is about the security considerations for RADIUS. However, we discuss a few additional issues here 🛡️

This specification relies on the existing DTLS, RADIUS/UDP, and RADIUS/TLS specifications. That means all security considerations for DTLS apply to the DTLS portion of RADIUS/DTLS. In the same way, the TLS and RADIUS security issues discussed in [RFC6614] also apply to this specification. Most of the security considerations for RADIUS apply to the RADIUS portion of the specification.

Lowkey though, a lot of the RADIUS security issues are about RADIUS encryption and authorization. Those are mostly fixed when DTLS is used as the transport. The issues that this specification doesn't fix are about the RADIUS packet format and handling, which this specification doesn't change 🧐

This specification also suggests that implementations use a session tracking table. That table extends the duplicate detection cache mandated in [RFC5080], Section 2.2.2. The change is that DTLS-specific information gets tracked for each table entry. Section 5.1.1, above, describes steps to mitigate any DoS issues caused by tracking that extra information 🫣

The fixed shared secret given above in Section 2.2.1 is acceptable only when DTLS is used with a non-null encryption method. If a DTLS session uses a null encryption method, because of misconfiguration or an implementation error, then all of the RADIUS traffic can be read by an observer. That's why implementations MUST NOT use null encryption methods for RADIUS/DTLS. Absolutely not 🙅‍♀️

For systems that do protocol-based firewalling and/or filtering, it is RECOMMENDED that they be configured to permit only DTLS over the RADIUS/DTLS port 🧱

10.1. Crypto-Agility 🦋

Section 4.2 of [RFC6421] lists a bunch of recommendations about security properties for new RADIUS proposals. Using DTLS as the transport layer satisfies all of them ✅

Section 4.3 of [RFC6421] lists recommendations about backwards compatibility with RADIUS. Section 3, above, covers these concerns in detail 📖

Section 4.4 of [RFC6421] recommends that change control be ceded to the IETF, and that interoperability is possible. Both of those requirements are satisfied 🙌

Section 4.5 of [RFC6421] requires that the new security methods apply to all packet types. This is satisfied by allowing DTLS to be used for all RADIUS traffic. Section 3, above, also covers concerns about documenting the transition from legacy RADIUS to crypto-agile RADIUS 💫

Section 4.6 of [RFC6421] requires automated key management. This is satisfied by using DTLS key management 🔑

10.2. Legacy RADIUS Security 🚨

Okay, we have to say it again: legacy RADIUS is not secure. We suggest that RADIUS clients and servers implement either this specification or [RFC6614]. New attacks on MD5 have shown up over the past few years, and there's a real possibility that MD5 could be completely broken in the near future. If that happens, RADIUS/UDP would be completely insecure 😱

The existence of fast and cheap attacks on MD5 could lead to a total loss of all the network security that depends on RADIUS. Attackers could get user passwords and possibly gain complete network access. We cannot overstate how disastrous a successful attack on RADIUS would be 💀

We also want to caution implementors, especially client implementors, about using RADIUS/DTLS. It might be tempting to use the shared secret as the basis for a TLS-PSK method and leave the user interface otherwise unchanged. This practice MUST NOT be used. The administrator MUST be given the option to use DTLS. Any shared secret used for RADIUS/UDP MUST NOT be used for DTLS. Reusing a shared secret between RADIUS/UDP and RADIUS/DTLS would cancel out all of the benefits of using DTLS 🙈

RADIUS/DTLS client implementors MUST expose a configuration that lets the administrator choose the ciphersuite. Where certificates are used, RADIUS/DTLS client implementors MUST expose a configuration that lets an administrator configure all the certificates needed for certificate-based authentication. Those certificates include client, server, and root certificates 🎀

TLS-PSK methods are susceptible to dictionary attacks. Section 6, above, recommends deriving TLS-PSK keys from a Cryptographically Secure Pseudorandom Number Generator (CSPRNG), which makes dictionary attacks a lot harder. Servers SHOULD track failed client connections by TLS-PSK ID, and block TLS-PSK IDs that seem to be brute-forcing the keyspace 🕵️‍♀️

The historic RADIUS practice of using shared secrets (here, PSKs) that are minor variations of words is NOT RECOMMENDED, because it would cancel out all of the security DTLS gives you 🙅‍♀️

10.3. Resource Exhaustion 🧨

The use of DTLS allows DoS attacks and resource-exhaustion attacks that weren't possible in RADIUS/UDP. These attacks are similar to the ones described for TCP in [RFC6614], Section 6 🥺

Session tracking, as described in Section 5.1, can result in resource exhaustion. So servers MUST limit the absolute number of sessions they track. When the total number of tracked sessions is going to go over the configured limit, servers MAY free up resources by closing the session that has been idle for the longest time. Doing so may free up idle resources, which then lets the server accept a new session 💅

Servers MUST limit the number of partially open DTLS sessions. These limits SHOULD be exposed to the administrator as configurable settings 🌈

10.4. Client-Server Authentication with DTLS 🔐

okay so we expect the first DTLS rollout to copy the RADIUS/UDP vibe, which is statically configured client-server pairs 💅 dynamic discovery of RADIUS servers is still being cooked up in another spec, so we're not touching that here 🙈

static config for RADIUS/UDP means a client has a fixed IP address for a server plus a shared secret used to authenticate traffic sent to that address. the server gets its own fixed IP address for each client, plus a shared secret for traffic coming from that address. this model needs a glow-up for RADIUS/DTLS 🦋

instead of a shared secret, TLS credentials MUST be used by each party to authenticate the other. the identity part is trickier 😭 just like RADIUS/UDP, IP addresses can act as a key that picks which credentials a client presents to a server, or which credentials a server will accept from a client. it's the fixed IP address model of RADIUS/UDP, but the shared secret has been swapped out for TLS credentials ✨

there's extra drama with RADIUS/DTLS though 🎀 when a client is configured with a hostname for a server, the server may present a certificate containing a hostname. the client MUST then verify that the hostnames match. any mismatch is a security violation, and the connection MUST be closed 💀

any hostname mismatch is a security violation, so the connection MUST be closed. no exceptions, bestie 🚫

a RADIUS/DTLS server MAY be configured with a "wildcard" IP address match for clients, instead of a unique fixed IP address for each client. in that case, clients MUST be individually configured with a unique certificate. when the server gets a connection from a client, it MUST determine the client's identity from the client certificate, and MUST authenticate (or not) the client based on that certificate. see [RFC6614], Section 2.4, for a discussion of how to match a certificate to a client identity 🧚

servers SHOULD still use IP address filtering to minimize the possibility of attacks 🛡️ that means they SHOULD permit clients only from a limited IP address range or ranges, and they SHOULD silently discard all traffic from outside of those ranges 🙅‍♀️

since the client-server relationship is static, the authentication credentials for that relationship must also be statically configured 🍓 so a client connecting to a DTLS server SHOULD be pre-configured with the server's credentials (e.g., PSK or certificate). if the server fails to present the correct credentials, the DTLS session MUST be closed. each server SHOULD be pre-configured with enough information to authenticate connecting clients 🌸

the requirement for clients to be individually configured with a unique certificate can be met by using a private CA for certificates used in RADIUS/DTLS environments 🔒 if a client were configured to use a public CA, it could accept as valid any server with a certificate signed by that CA. the traffic would be secure from third-party observers, sure, but the server would have unrestricted access to ALL of the RADIUS traffic, including every user credential and password. not it 😭

so clients SHOULD NOT be pre-configured with a list of known public CAs by the vendor or manufacturer. instead, the clients SHOULD start off with an empty CA list 🫙 a CA SHOULD only be added when it's manually configured by an administrator 👑

this is the total opposite of web browsers, which come pre-loaded with a bunch of known CAs 🌈 the goal there is security from third-party observers, but also being able to talk to any unknown site that shows a signed certificate. RADIUS/DTLS is different. its goal is security from third-party observers AND being able to talk to only a small set of well-known servers 💜

this requirement does not stop clients from using hostnames instead of IP addresses to locate a particular server ✨ it just means the credentials for that server should be pre-configured on the client and associated with that hostname. this requirement does suggest that, until there's a spec for dynamic discovery, clients SHOULD use only those servers that have been manually configured by an administrator 🫶

10.5. Network Address Translation 🌐

okay this one is a certified mess 😭 Network Address Translation (NAT) is fundamentally incompatible with RADIUS/UDP. RADIUS/UDP uses the source IP address to figure out the shared secret for the client, and NAT hides many clients behind one source IP address. so RADIUS/UDP clients cannot be located behind a NAT gateway 🚫

it gets worse 💀 port reuse on a NAT gateway means packets from different clients may look like they came from the same source port on the NAT. a RADIUS server might receive a RADIUS/DTLS packet from one source IP/port combination, and then a RADIUS/UDP packet from that same source IP/port combination. if that's allowed, the server would have an inconsistent view of the client's security profile, which lets an attacker pick the most insecure method 🙈 main character villain arc, honestly

if more than one client sits behind a NAT gateway, then every client behind the NAT MUST use a secure transport such as TLS or DTLS 🔐 as discussed below, a method for uniquely identifying each client MUST be used too 🫶

10.6. Wildcard Clients 🃏

some RADIUS server implementations allow "wildcard" clients, meaning clients with an IPv4 netmask other than 32 or an IPv6 netmask other than 128 🌸 that practice is not recommended for RADIUS/UDP, because it means multiple clients end up sharing the same shared secret 😬

RADIUS/DTLS can make wildcards safe though ✨ when RADIUS/DTLS is used with wildcards, clients MUST be uniquely identified using TLS parameters, and any certificate or PSK used MUST be unique to each client. so the wildcard energy stays, but the sharing drama is gone 💅

10.7. Session Closing 🚪

okay, section 5.1.1 above says DTLS sessions MUST be closed when the transported RADIUS packets are malformed or fail the authenticator checks. the reason is that the session is only supposed to carry RADIUS packets 🎀

any non-RADIUS traffic on that session means the other party is misbehaving and is a potential security risk 🚨 similarly, any RADIUS traffic that fails authentication vector or Message-Authenticator validation means the two parties don't have a common shared secret, so the session is unauthenticated and insecure 🙅‍♀️

we really want to avoid a situation where a third party can send well-formed RADIUS packets that make a DTLS session close 🙈 so in other situations, the session SHOULD remain open in the face of non-conformant packets 🦋

10.8. Client Subsystems 🧩

many traditional clients treat RADIUS as subsystem-specific. that means each subsystem on the client has its own RADIUS implementation and configuration 🫠 those independent implementations are fine for simple systems, but they break down when multiple servers, fail-over, and load-balancing are needed. they have even worse issues when DTLS is enabled 💀

as noted in Section 6.1, above, clients SHOULD use a local proxy that arbitrates all RADIUS traffic between the client and all servers 👑 this proxy encapsulates all the knowledge about servers, including security policies, fail-over, and load-balancing. all client subsystems SHOULD communicate with this local proxy, ideally over a loopback address 🔁 the requirements on using strong shared secrets still apply 🔐

the benefit is that there's one place in the client that arbitrates all RADIUS traffic 🌈 subsystems that don't implement DTLS can stay blissfully unaware of it. DTLS sessions opened by the proxy can stay open for long periods of time, even when client subsystems get restarted ✨ the proxy can do RADIUS/UDP to some servers and RADIUS/DTLS to others 🧚

delegation of responsibilities and separation of tasks are important security principles 💜 by moving all RADIUS/DTLS knowledge into a DTLS-aware proxy, security analysis gets simpler, and enforcing correct security gets easier. it's giving organized and secure 💅

11. References 📚

11.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
  • [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
  • [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
  • [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
  • [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
  • [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, August 2010.
  • [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
  • [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, February 2012.
  • [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012.
  • [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, May 2012.

11.2. Informative References

  • [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
  • [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
  • [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
  • [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
  • [RFC6421] Nelson, D., Ed., "Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)", RFC 6421, November 2011.
  • [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, July 2013.
  • [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996.
  • [MD5Break] Wang, X. and H. Yu, "How to Break MD5 and Other Hash Functions", EUROCRYPT '05 Proceedings of the 24th annual international conference on Theory and Applications of Cryptographic Techniques, pp. 19-35, ISBN 3-540-25910-4, 2005.

Acknowledgments 🫶

parts of the text in Section 3 defining the Request and Response Authenticators were taken with minor edits from [RFC2865], Section 3 💖

Author's Address 🖋️

Alan DeKok The FreeRADIUS Server Project URI: http://freeradius.org EMail: aland@freeradius.org

📦 where this page comes from