RFC 9765

RADIUS/1.1: Leveraging Application-Layer Protocol Negotiation (ALPN) to Remove MD5

📅 published April 2025, from ietf

RFC 9765: RADIUS/1.1: Leveraging Application-Layer Protocol Negotiation (ALPN) to Remove MD5 🎀

(Part 1 of 9)

Okay bestie, so this is RFC 9765 💖 It's an IETF document written by A. DeKok from FreeRADIUS, dated April 2025. Its category is Experimental, and its ISSN is 2070-1721. The title block says it updates RFCs 2865, 2866, 5176, 6613, 6614, and 7360 ✨ and it doesn't list any obsoletes, so that's the whole story up top.

Abstract 🌸

Okay so this doc is all about ALPN (Application-Layer Protocol Negotiation) 🦋 It defines ALPN extensions for RADIUS/TLS and RADIUS/DTLS. These extensions let the two sides agree on an application protocol variant of RADIUS called "RADIUS/1.1" ✨ RADIUS/UDP and RADIUS/TCP aren't touched at all 🙈 The main event is that RADIUS/1.1 lets you negotiate a transport profile where the RADIUS shared secret isn't used anymore, and every MD5-based packet authentication and attribute obfuscation method is removed 💀 no more MD5, periodt 💅

This document updates RFCs 2865, 2866, 5176, 6613, 6614, and 7360.

Status of This Memo 📜

This is not an Internet Standards Track spec, bestie 🍓 It's published for examination, experimental implementation, and evaluation 🧪

It's an Experimental Protocol for the Internet community, and it's a product of the Internet Engineering Task Force (IETF) 🌈 It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 👑 Not every IESG-approved document is a candidate for any level of Internet Standard, though. Check Section 2 of RFC 7841 for the details 🤓

You can find the current status of this document, any errata, and how to send feedback at https://www.rfc-editor.org/info/rfc9765 🔗

Copyright (c) 2025 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 (https://trustee.ietf.org/license-info) as they stand on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📖 Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License 🫶

Table of Contents 🗂️

   1.  Introduction
   2.  Terminology
   3.  The RADIUS/1.1 Transport Profile for RADIUS
     3.1.  ALPN Name for RADIUS/1.1
     3.2.  Operation of ALPN
     3.3.  Configuration of ALPN for RADIUS/1.1
       3.3.1.  Using Protocol-Error for Signaling ALPN Failure
       3.3.2.  Tabular Summary
     3.4.  Miscellaneous Items
     3.5.  Session Resumption
   4.  RADIUS/1.1 Packet and Attribute Formats
     4.1.  RADIUS/1.1 Packet Format
     4.2.  The Token Field
       4.2.1.  Sending Packets
       4.2.2.  Receiving Packets
   5.  Attribute Handling
     5.1.  Obfuscated Attributes
       5.1.1.  User-Password
       5.1.2.  CHAP-Challenge
       5.1.3.  Tunnel-Password
       5.1.4.  Vendor-Specific Attributes
     5.2.  Message-Authenticator
     5.3.  Message-Authentication-Code
     5.4.  CHAP, MS-CHAP, and Similar Attributes
     5.5.  Original-Packet-Code
   6.  Other Considerations When Using ALPN
     6.1.  Protocol-Error
     6.2.  Status-Server
     6.3.  Proxies
   7.  Other RADIUS Considerations
     7.1.  Crypto-Agility
     7.2.  Error-Cause Attribute
     7.3.  Future Standards
   8.  Privacy Considerations
   9.  Security Considerations
   10. IANA Considerations
   11. References
     11.1.  Normative References
     11.2.  Informative References
   Acknowledgments
   Author's Address

1. Introduction ✨

Okay bestie, so the RADIUS protocol [RFC2865] uses MD5 [RFC1321] to authenticate packets and to obfuscate certain attributes 🙈. Then people made transport protocols for TCP [RFC6613], TLS [RFC6614], and DTLS [RFC7360]. But ngl, those transports still use MD5 to authenticate individual packets. So the shared secret was used along with MD5 even when the RADIUS packets were riding inside (D)TLS 💀. At the time, the RADEXT Working Group agreed that keeping MD5 was acceptable. TLS was basically seen as a simple "wrapper" around RADIUS, with a fixed shared secret. The plan was to let people use (D)TLS while changing essentially nothing about RADIUS encoding, decoding, authentication, and packet validation 🎀.

Issues with MD5 security have been known for decades, most notably in [RFC6151] and in Section 3 of [RFC6421], among others 😬. Because RADIUS relies on MD5 for security, it's impossible to use RADIUS in secure systems that forbid digest algorithms with known vulnerabilities. For example, FIPS 140 forbids systems from relying on insecure cryptographic methods for security [FIPS-140-3]. Not it 🙅‍♀️.

Now, while the use of MD5 in RADIUS/TLS hasn't been proven to be insecure, it also hasn't been proven to be secure. That gap is a big deal, because it makes RADIUS really hard to use in organizations that need systems with proven security. Those orgs tend to just ban insecure digests like MD5 entirely, even if MD5 has no known security impact 🙃. The resulting system might still not be secure, but at least it doesn't contain any known insecurities. Lowkey iconic, but also kinda sad.

In addition, the use of MD5 in RADIUS/TLS and RADIUS/DLTS adds no security or privacy over what TLS already provides. In hindsight, the RADEXT Working Group's decision to keep MD5 for historic RADIUS/TLS was likely wrong. It was an easy call in the short term, but it has caused ongoing problems, and this document is here to fix them 💅. The author of this document played a part in that original decision, which is now being corrected by this document. Honest and iconic 🫶.

This document defines an Application-Layer Protocol Negotiation (ALPN) [RFC7301] extension for RADIUS over (D)TLS that removes the need to use MD5 for (D)TLS. We call it RADIUS/1.1 ✨. This specification makes no changes to UDP or TCP transport. The RADIUS/1.1 protocol is best understood as a transport profile for RADIUS over TLS, rather than a full-on revamp of the RADIUS protocol. Main character energy, but make it a profile 🦋.

Systems that implement this transport profile can be more easily verified to be FIPS 140 compliant 🌈. A preliminary implementation showed that only minor code changes are required to support RADIUS/1.1 on top of an existing RADIUS/TLS server implementation. These include:

  • A method to set the list of supported ALPN protocols before the TLS handshake starts.
  • A method to query if ALPN has chosen a protocol (and if yes, which protocol was chosen) after the TLS handshake has completed.
  • Changes to the packet encoder and decoder, so that the individual packets are not authenticated, and no attribute is encoded with the historic obfuscation methods.

So the bulk of the ALPN protocol can be left to the underlying TLS implementation 🧚. This document discusses the ALPN exchange in detail so that you get simplified descriptions, and so that you don't have to read or understand all of [RFC7301]. Thank me later 🫶.

The detailed list of changes from historic TLS-based transports to RADIUS/1.1 is as follows:

  • ALPN is used for negotiation of this extension.
  • TLS 1.3 or later is required.
  • All uses of the RADIUS shared secret have been removed.
  • The now unused Request and Response Authenticator fields have been repurposed to carry an opaque Token that identifies requests and responses.
  • The functionality of the Identifier field has been replaced by the Token field, and the space previously taken by the Identifier field is now reserved and unused.
  • The Message-Authenticator attribute ([RFC3579], Section 3.2) is not sent in any packet, and is ignored if received.
  • Attributes such as User-Password, Tunnel-Password, and MS-MPPE keys are sent encoded as "text" ([RFC8044], Section 3.4) or "octets" ([RFC8044], Section 3.5), without the previous MD5-based obfuscation. This obfuscation is no longer necessary, as the data is secured and kept private through the use of TLS 🔐.
  • The conclusion of the efforts stemming from [RFC6421] is that crypto-agility in RADIUS is best done via a TLS wrapper, and not by extending the RADIUS protocol 👑.
  • [RFC5176] is updated to allow the Error-Cause attribute to appear in Access-Reject packets.

The following items are left unchanged from historic TLS-based transports for RADIUS, and I'm so here for the stability 🌸:

  • The RADIUS packet header is the same size, and the Code and Length fields ([RFC2865], Section 3) have the same meaning as before.
  • The default 4096-octet packet size from [RFC2865], Section 3 is unchanged, although [RFC7930] can still be leveraged to use larger packets.
  • All attributes that have simple encodings (that is, attributes that do not use MD5 obfuscation) have the same encoding and meaning as before.
  • As this extension is a transport profile for one "hop" (client-to-server connection), it does not impact any other connection used by a client or server. The only systems that are aware that this transport profile is in use are the client and server who have negotiated the use of this extension on a particular shared connection 🍓.
  • This extension uses the same ports (2083/tcp and 2083/udp) that are defined for RADIUS/TLS [RFC6614] and RADIUS/DTLS [RFC7360].

A major benefit of this extension is that a server that implements it can also be more easily verified for FIPS 140 compliance 💖. That is, a server can remove all uses of MD5, which means those algorithms are provably not used for security purposes. In that case, though, the server will not support the Challenge Handshake Authentication Protocol (CHAP) or any authentication method that uses MD5. The choice of which authentication method to accept is always left to the server. This specification does not change any authentication method carried in RADIUS, and it does not mandate (or forbid) the use of any authentication method for any system.

As for proxies, there was never a requirement that proxies implement CHAP or Microsoft CHAP (MS-CHAP) authentication. So far as a proxy is concerned, attributes relating to CHAP and MS-CHAP are simply opaque data that is transported unchanged to the next hop. Therefore, it's possible for a FIPS 140 compliant proxy to transport authentication methods that depend on MD5, so long as that data is forwarded to a server that supports those methods 🦋.

We reiterate that the decision to support (or not support) any authentication method is entirely site local, and is not a requirement of this specification 💅. The contents or meaning of any RADIUS attribute other than the Message-Authenticator (and similar attributes) are not modified. The only change to the Message-Authenticator attribute is that it is no longer used in RADIUS/1.1.

Unless otherwise described in this document, all RADIUS requirements apply to this extension. That is, this specification defines a transport profile for RADIUS. It is not an entirely new protocol, and it defines only minor changes to the existing RADIUS protocol. It does not change the RADIUS packet format, attribute format, etc. This specification is compatible with all RADIUS attributes of the past, present, and future 🌈.

This specification is compatible with existing implementations of RADIUS/TLS and RADIUS/DTLS. Systems that implement this specification can fall back to historic RADIUS/TLS if no ALPN signaling is performed, and the local configuration permits such fallback 🫶.

This specification is also compatible with all existing RADIUS specifications. There's no need for any RADIUS specification to mention this transport profile by name or to make provisions for it. This document defines how to transform RADIUS into RADIUS/1.1, and no further discussion of that transformation is necessary ✨.

We note that this document makes no changes to previous RADIUS specifications. Existing RADIUS implementations can keep being used without modification. Where previous specifications are explicitly mentioned and updated, those updates or changes apply only when the RADIUS/1.1 transport profile is being used 🎀.

In short, when negotiated on a connection, the RADIUS/1.1 transport profile lets implementations avoid MD5 when authenticating packets or when obfuscating certain attributes. Bestie, that's the whole glow-up 💜.

2. Terminology 📚

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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🔥.

The following list describes the terminology and abbreviations used in this document. Let's get into it 💖.

ALPN Application-Layer Protocol Negotiation (as defined in [RFC7301]).

RADIUS Remote Authentication Dial-In User Service (as defined in [RFC2865], [RFC2866], and [RFC5176], among others).

While this protocol can be viewed as "RADIUS/1.0", for simplicity and historical compatibility, we keep the name "RADIUS" 🧁.

RADIUS/UDP RADIUS over the User Datagram Protocol (see [RFC2865], [RFC2866], and [RFC5176], among others).

RADIUS/TCP RADIUS over the Transmission Control Protocol [RFC6613].

RADIUS/TLS RADIUS over Transport Layer Security [RFC6614].

RADIUS/DTLS RADIUS over Datagram Transport Layer Security [RFC7360].

RADIUS over TLS Refers to any RADIUS packets transported over TLS or DTLS. This terminology is used instead of alternatives such as "RADIUS/(D)TLS" or "either RADIUS/TLS or RADIUS/DTLS". This term is generally used when referring to TLS-layer requirements for RADIUS packet transport 🦋.

historic RADIUS/TLS Refers to RADIUS over (D)TLS (as defined in [RFC6614] and [RFC7360]). This term does not include the protocol defined in this specification 🙈.

RADIUS/1.1 RADIUS version 1.1, i.e., the transport profile defined in this document. We use RADIUS/1.1 to refer interchangeably to TLS and DTLS transport ✨.

TLS Transport Layer Security. Generally, when we refer to TLS in this document, we are referring interchangeably to TLS or DTLS transport 🌸.

3. The RADIUS/1.1 Transport Profile for RADIUS 🎀

This section describes the ALPN transport profile in detail. It first gives the name used for ALPN, and then describes how ALPN is configured and negotiated by the client and server. It then concludes by discussing TLS issues, such as what to do for ALPN during session resumption 🧚‍♀️.

3.1. ALPN Name for RADIUS/1.1 ✨

okay so the ALPN name for RADIUS/1.1 is "radius/1.1" 🦋 and it just means "the protocol this spec defines." iconic, right?

Now the important bit 👀: if ALPN isn't configured, or it isn't received in a TLS connection, systems that support ALPN MUST NOT use RADIUS/1.1. so no sneaking it in without ALPN, bestie 🙅‍♀️

Where ALPN is configured, the client shows it's into RADIUS/1.1 by sending a list of the ALPN strings it supports 💅. The server can take one of those proposals and reply with a matching ALPN string, or it can reject the proposal and not reply with any ALPN string at all. a full step-by-step walkthrough of the whole negotiation is coming up right below 🧚

Implementations MUST signal ALPN "radius/1.1" in order for it to be used in a connection. no signal, no RADIUS/1.1, periodt 💀

next up, we look at how ALPN actually works 🌸

3.2. Operation of ALPN

okay, quick overview for anyone who isn't already obsessed with [RFC7301] 🫶 ALPN is negotiated on a per-connection basis as described in [RFC7301], and the flow goes like this ✨

  1. The client sends an ALPN extension in the ClientHello 📨. That extension lists one or more application protocols by name, and those names are basically the protocols the client is claiming it can speak 🎀
  2. The server gets the extension and checks the application protocol name(s) against the list it's been configured with 🔍

If the server finds no acceptable common protocols (ALPN or otherwise), it closes the connection. 😭 rip, no vibes match, so it's bye bye.

  1. Otherwise, the server sends back a ServerHello with either no ALPN extension, or an ALPN extension holding exactly one application protocol name 🌈 and that name HAS to be one of the names the client proposed. (fun fact: if the client didn't signal ALPN, or the server doesn't accept the proposal, the server doesn't reply with any ALPN name at all 🙈)
  2. The client gets the ServerHello, checks the received application protocol (if there is one) against the names it sent, and writes down which protocol got picked 📝

this check is super necessary, honestly 🧐 it's how the client finds out which protocol the server chose, and makes sure that choice is one the client is actually okay with. no surprises allowed ✨

The next step in defining RADIUS/1.1 is to spell out how ALPN gets configured on the client and server, and to give more detailed requirements for how it's configured and how it operates 💜

3.3. Configuration of ALPN for RADIUS/1.1 🎀

okay so, clients or servers that support this spec can do it by adding a new TLS configuration variable, which we're calling Version here 💅 You don't have to use that exact name, but it is RECOMMENDED that admin interfaces or programming interfaces use a similar one so everyone's speaking the same language ✨ This variable controls how the implementation signals use of this protocol via ALPN.

When it's set, this variable should contain the list of permitted RADIUS versions as numbers, like "1.0" or "1.1" 🌸 The implementation may allow multiple values in one variable, allow multiple variables, or use two configs for the "minimum" and "maximum" allowed versions instead 🦋 We're assuming there's one variable here, which can hold either nothing or a list of one or more versions the current implementation supports. In this spec, the possible values, ALPN strings, and what they mean are:

+==========+========================+=============================+
| Value    | ALPN String(s)         | Interpretation              |
+==========+========================+=============================+
| unset    |                        | no ALPN strings are sent    |
+----------+------------------------+-----------------------------+
| 1.0      | radius/1.0             | require historic RADIUS/TLS |
+----------+------------------------+-----------------------------+
| 1.0, 1.1 | radius/1.0, radius/1.1 | allow either historic       |
|          |                        | RADIUS/TLS or RADIUS/1.1    |
+----------+------------------------+-----------------------------+
| 1.1      | radius/1.1             | require RADIUS/1.1          |
+----------+------------------------+-----------------------------+

                              Table 1

This config is also extensible to future RADIUS versions if that ever becomes necessary 🔮 New values and ALPN names can simply be added to the list, and implementations can then negotiate the highest version that's supported by both client and server. Iconic. 👑

Implementations SHOULD support both historic RADIUS/TLS and RADIUS/1.1. Such implementations MUST set the default value for this configuration variable to "1.0, 1.1". This setting makes sure both versions of RADIUS can be negotiated 🫶

Implementations MAY support only RADIUS/1.1. In that case, the default value for this configuration variable MUST be "1.1". This behavior is NOT RECOMMENDED, because it's incompatible with historic RADIUS/TLS 💀 It can only be a reasonable default when all (or nearly all) RADIUS clients have been updated to support RADIUS/1.1.

A more detailed definition of the variable and the meaning of the values is given below 🧚

Configuration Variable Name

Version

For "Value":

  • A. If unset, ALPN is not used. Any connection MUST use historic RADIUS/TLS. This variable is only included here for logical completeness 🙈 Implementations of this specification SHOULD be configured to always send one or more ALPN strings. That data tells the other side the implementation can do ALPN negotiation, even if it isn't currently set up to use RADIUS/1.1.
    • Client Behavior: The client MUST NOT send any protocol name via ALPN.
    • Server Behavior: The server MUST NOT signal any protocol name via ALPN. If the server gets an ALPN name from the client, it MUST NOT close the connection. Instead, it just doesn't reply with ALPN and finishes the TLS connection setup the way it's defined for historic RADIUS/TLS. Note that if a client sends radius/1.1, the client will see that the server didn't acknowledge that request and will close the connection. For any other client configuration, the connection will use historic RADIUS/TLS.
  • B. If set to "1.0", "1.0, 1.1", "1.1", or future values:
    • Client Behavior: The client MUST send the ALPN string(s) associated with the configured version. For example, send radius/1.0 for "1.0". The client will get either no ALPN response from the server, or an ALPN response with one version string that MUST match one of the strings it sent, or else they'll get a TLS alert of "no_application_protocol" (120). If the connection stays open, the client MUST treat it as using the matching ALPN version.
    • Server Behavior: If the server gets no ALPN name from the client, it MUST use historic RADIUS/TLS. If the server gets one or more ALPN names from the client, it MUST reply with the highest mutually supported version and then use the latest supported version for this connection. If the server gets one or more ALPN names but none of them match the versions supported by (or configured on) the server, it MUST reply with a TLS alert of "no_application_protocol" (120), and then it MUST close the TLS connection. These negotiation requirements aren't specific to RADIUS/1.1, so they can be used unchanged if any new version of RADIUS gets defined 🦋

By requiring the default configuration to allow historic RADIUS/TLS, implementations will be able to negotiate both historic RADIUS/TLS connections and RADIUS/1.1 connections. Any other recommended default setting would stop either historic RADIUS/TLS or RADIUS/1.1 from being negotiated 🚫

Once administrators verify that both ends of a connection support RADIUS/1.1, and that it's been negotiated successfully, the configurations SHOULD be updated to require RADIUS/1.1. The connections should be monitored after that change to make sure the systems stay connected 👀 If there are connection issues, the configuration should go back to allowing both "radius/1.0" and "radius/1.1" ALPN strings until the administrator has fixed the problems 🛠️

We're repeating this on purpose: systems implementing this spec but configured with settings that forbid RADIUS/1.1 will behave largely the same as systems that don't implement it. The only difference is that clients may send the ALPN name radius/1.0 🌈

Systems implementing RADIUS/1.1 SHOULD NOT be configured by default to forbid that protocol. That setting exists mainly for completeness, and to give administrators the flexibility to control their own deployments ✨

While [RFC7301] doesn't talk about servers sending a TLS alert of "no_application_protocol" (120) when the client doesn't use ALPN, this behavior seems useful. So servers MAY send a TLS alert of "no_application_protocol" (120) when the client doesn't use ALPN.

However, some TLS implementations may not let an application send a TLS alert of its choice at a time of its choice 😭 That means it isn't always possible for an application to send the TLS alert we just talked about. The impact is that an implementation may try to connect and then see the connection fail, without being able to tell why. Implementers and administrators should know that unexplained connection failures may come from ALPN issues 🕵️‍♀️

The server MAY send this alert during the ClientHello if it requires ALPN but doesn't receive it. In other words, there may not always be a need to wait for the TLS connection to be fully established before realizing that no common ALPN protocol can be negotiated ⭐

Where the client does perform signaling via ALPN, and the server determines there's no compatible application protocol name, then as per [RFC7301], Section 3.2, it MUST send a TLS alert of "no_application_protocol" (120) 🚨

The server MUST close the connection whether or not it sent a TLS alert for no compatible ALPN. The above ALPN requirements apply to both new sessions and resumed sessions 💜

On the flip side, the client doesn't need to signal that there are no compatible application protocol names. The client sends zero or more protocol names, and the server responds as above. From the client's point of view, the list it sent ends up as either a connection failure or a connection success 🎀

It is RECOMMENDED that the server logs a descriptive error in this situation, so an administrator can figure out why a particular connection failed. The log message SHOULD include information about the other end of the connection, such as the IP address, certificate information, etc. Similarly, when the client receives a TLS alert of "no_application_protocol" (120), it SHOULD log a descriptive error message. These error messages are critical for helping administrators diagnose connectivity issues 📝

3.3.1. Using Protocol-Error for Signaling ALPN Failure 🧯

When it isn't possible to send a TLS alert of "no_application_protocol" (120), the only option left for one party to signal the other is to send application data inside the TLS tunnel 🦋 So, when one end of a connection requires ALPN but the other end doesn't support it, the end requiring ALPN MAY send a Protocol-Error packet [RFC7930] inside the tunnel and then MUST close the connection. If this is done, the Token field of the Protocol-Error packet can't be copied from any request, so that field MUST be set to all zeros 🙃

The Protocol-Error packet SHOULD contain a Reply-Message attribute with a text string describing the cause of the error. The packet SHOULD also contain an Error-Cause attribute with the value 406 (Unsupported Extension). The packet SHOULD NOT contain other attributes 💅

An implementation sending this packet could skip the RADIUS encoder and just write the packet as a predefined, fixed set of data to the TLS connection 🍓 That's probably simpler than calling the normal RADIUS packet encoder to build a reply packet that has no matching request packet.

Since this packet is an unexpected response packet, existing client implementations of RADIUS over TLS will ignore it. They may either log an error and close the connection, or discard the packet and leave the connection open. If the connection stays open, the end supporting ALPN will close it, so sending this packet has no side effects. So even though using a Protocol-Error packet this way is unusual, it's both informative and safe 🌸

The point of this packet isn't for the other end to automatically work out what went wrong and fix it. It's meant to (eventually) be seen by an administrator, who can then take action 🫶

3.3.2. Tabular Summary ✨

okay so the preceding bit dumps a LOT of recommendations on you 😭 so the spec made a table that boils down what happens for each client/server combo of Version variable values 💅 the row and column headings are the RADIUS version numbers sent in ALPN (or no ALPN at all), and the cells show which RADIUS version ends up negotiated 🦋 to keep it clean, they only list the version numbers, not the full ALPN strings like "radius/1.0" 🌸

this table and the names below are just for vibes and explaining things, not rules 🫶

            +==========+======================================+
            | Client   |                Server                |
            |          +=========+=======+==========+=========+
            |          | no ALPN | 1.0   | 1.0, 1.1 | 1.1     |
            +==========+=========+=======+==========+=========+
            | no ALPN  | TLS     | TLS   | TLS      | Close-S |
            +==========+---------+-------+----------+---------+
            | 1.0      | TLS     | TLS   | TLS      | Alert   |
            +==========+---------+-------+----------+---------+
            | 1.0, 1.1 | TLS     | TLS   | 1.1      | 1.1     |
            +==========+---------+-------+----------+---------+
            | 1.1      | Close-C | Alert | 1.1      | 1.1     |
            +==========+---------+-------+----------+---------+

                    Table 2: Possible Outcomes for ALPN

here's what each entry means 💖

Alert The client sends ALPN, and the server does NOT agree to what the client proposed 🙈 so the server replies with a TLS alert of "no_application_protocol" (120) and then closes the TLS connection 💀

since the server replies with a TLS alert here, the Protocol-Error packet isn't used in this case ✨

Close-C The client sends ALPN, but the server doesn't respond with ALPN 😭 the client closes the connection.

like we said in the last bit, the client MAY send a Protocol-Error packet to the server before closing the connection 🧚

Close-S The client doesn't send any ALPN strings, but the server requires ALPN 🙅‍♀️ the server closes the connection.

like we said in the last bit, the server MAY send a Protocol-Error packet to the client before closing the connection 🍓 the server MAY also send a TLS alert of "no_application_protocol" (120) before closing the connection 🔥

TLS historic RADIUS/TLS is used here 🕰️ the client either sends no ALPN string or sends "radius/1.0", and the server either replies with no ALPN string or with "radius/1.0" 🌈 the connection MUST use historic RADIUS/TLS 👑

1.1 the client sends the ALPN string "radius/1.1" 🎀 the server acknowledges that with a reply of "radius/1.1", and then RADIUS/1.1 is used ⭐ main character energy 💅

implementations should note that this table might get extended in future specifications 🦋 the text above is informative and doesn't mandate that only the ALPN strings listed are used. the actual ALPN stuff happens as defined in the earlier sections of this doc and in [RFC7301] 🫶

3.4. Miscellaneous Items

okay bonus stuff ✨ implementations of this spec MUST require TLS version 1.3 or later 💜 that's a hard line, no cap 🔥

the "radius/1.0" ALPN string is technically unnecessary, because it's basically the same as not sending any ALPN string 🙈 but it's still useful for RADIUS admins 🧑‍💻 a system that sends "radius/1.0" is explicitly saying "hey, I support ALPN, but I'm not currently set up for RADIUS/1.1" 🌸 admins can use that to figure out which devices are ALPN-capable 🔍

sending "radius/1.0" also lets server implementations send a TLS alert of "no_application_protocol" (120) when they can't find a matching ALPN string 💅 experiments with TLS library implementations suggest that in some cases you can send that alert even when ALPN isn't used 🤔 but that scenario isn't covered in [RFC7301] and probably isn't universal 🙃 so ALPN as defined in [RFC7301] lets servers send that alert in situations where it would otherwise be forbidden, or maybe just unsupported 🌈

last but not least, defining ALPN strings for all known RADIUS versions makes it way easier to add more ALPN strings later if that's ever needed 🧚✨

3.5. Session Resumption

[RFC7301], Section 3.1 says ALPN is negotiated on each connection, even when session resumption is used 🎟️ quoting it directly:

When session resumption or session tickets [RFC5077] are used, the previous contents of this extension are irrelevant, and only the values in the new handshake messages are considered.

(Note: RFC 5077 was obsoleted by [RFC8446].) 📝

okay now the important part 😤 to prevent down-bidding attacks, RADIUS systems that negotiate "radius/1.1" MUST associate that info with the session ticket and enforce the use of "radius/1.1" on session resumption 🔐 so if "radius/1.1" was negotiated for a session, both clients and servers MUST behave as if the RADIUS/1.1 variable was set to "require" for that session 💖 no sneaky downgrades allowed bestie 🚫⬇️

a client resuming a "radius/1.1" connection MUST advertise only the capability to do "radius/1.1" for the resumed session 🎀 so even if the client config allows historic RADIUS/TLS for new connections, it MUST signal "radius/1.1" when resuming a session that already negotiated "radius/1.1" 💅

same energy on the server side 🫶 when a server does resumption for a session that had previously negotiated "radius/1.1", and the client tries to resume without signaling RADIUS/1.1, the server MUST close the connection 😱 the server MUST send an appropriate TLS error, and it also SHOULD log a descriptive message like we talked about above 📜

on the flip side, there's no requirement for a client or server to force the use of RADIUS/TLS from [RFC6614] on session resumption 🦋 clients are free to signal support for "radius/1.1" on resumed sessions, even if the original session didn't negotiate "radius/1.1" 🌸 and servers are free to accept that request and negotiate "radius/1.1" for those sessions 🌈

4. RADIUS/1.1 Packet and Attribute Formats

this section is about the application-layer data that gets sent inside (D)TLS when you're using the RADIUS/1.1 protocol 🎀 unless it's discussed otherwise here, the application-layer data is the same as historic RADIUS 🕰️ this protocol is ONLY used when "radius/1.1" has been negotiated by both ends of a connection 💜

4.1. RADIUS/1.1 Packet Format

when RADIUS/1.1 is in use, the RADIUS header is modified from standard RADIUS 🔧 the header is still the same size, but some fields mean different things now 🙃 the Identifier and the Request and Response Authenticator fields are no longer used in RADIUS/1.1 💀 any operations that depend on those fields MUST NOT be performed 🚫 and since packet authentication, secrecy, and security are handled by the TLS layer, the RADIUS-specific cryptographic primitives aren't needed or used in RADIUS/1.1 anymore 🔐✨

here's a summary of the RADIUS/1.1 packet format 🧚 fields go left to right, obviously 💅

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Reserved-1   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Token                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           Reserved-2                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

                   Figure 1: The RADIUS/1.1 Packet Format

Code 🎯 the Code field is one octet and tells you what type of RADIUS packet it is 💖

the meaning of the Code field is unchanged from previous RADIUS specs ✨

Reserved-1 🌸 the Reserved-1 field is one octet 🧸

this field used to be the "Identifier" in historic RADIUS/TLS 🕰️ it's unused now, because the Token field replaces it, both as the way to identify requests and to match responses to requests 🦋

when sending packets, the Reserved-1 field MUST be set to zero 0️⃣ and the Reserved-1 field MUST be ignored when receiving a packet 👂

Length 📏 the Length field is two octets 🎀

the meaning of the Length field is unchanged from previous RADIUS specs 💅

Token 🪙 the Token field is four octets long and helps match requests and replies, replacing the Identifier field 🔑 the RADIUS server can detect a duplicate request if it gets the same Token value for two packets on a particular connection 👀

ALL values are possible for the Token field 🌈 implementations MUST treat the Token as an opaque blob when comparing Token values 🫥

more requirements for sending packets are below in Section 4.2.1, and for receiving packets in Section 4.2.2 📚

Reserved-2 🧊 the Reserved-2 field is twelve (12) octets long 📐

these octets MUST be set to zero when sending a packet 🙅‍♀️

these octets MUST be ignored when receiving a packet 🙉

these octets are reserved for future protocol extensions 🔮

4.2. The Token Field

okay this section gets into the nitty-gritty of how the Token field works 🧠 let's go 🚀💖

4.2.1. Sending Packets 🎀

okay bestie, the big rule here is that the Token field MUST change for every new unique packet you send on the same connection. 💅 but here's the twist: over DTLS transport you can retransmit duplicates, and when you do, the Token value MUST NOT be changed when that duplicate packet is (re)sent. ✨ and if the contents of a retransmitted packet change for any reason (like changing Acct-Delay-Time, which is covered in [RFC2866], Section 5.2), then the Token value MUST be changed. 🦋 ngl this is so specific it's giving legal paperwork 😭 but it matters! Also, on reliable transports packets are never retransmitted, so every new packet you send has a unique Token value anyway. 🫶

okay so back in the older RADIUS specs, the Identifier field could have the same value for different packets on the same connection. 🙈 for example, an Access-Request (Code 1) and an Accounting-Request (Code 4) could both use ID 3 and still count as different packets. that means clients and servers had to track the Identifier not just per connection but per Code too. 💀 that's a LOT of extra complexity for implementers, and nobody wants that drama.

so in RADIUS/1.1, the Token values MUST be generated from a 32-bit counter that is unique to each connection. 🌸 the counter SHOULD be initialized to a random value, taken from a random number generator, whenever a new connection is opened. 🍓 then the counter MUST be incremented for every unique new packet the client sends. retransmissions of the same packet MUST use the same unchanged Token value. 👑 since the Token is supposed to be unique per packet, a duplicate Token value is the only way a server can detect duplicate transmissions. iconic. 🔥

this counter method keeps Tokens unique and totally independent of any Code value in the RADIUS packet header. 💖 it's mandated because any other way of making unique, non-conflicting Tokens is more complex, gives no extra benefit, and just brings more bugs and interop headaches. 🙄 other methods would need way more resources to track outstanding Tokens and their expiry times. and the chance that initial values cause confusion by being reused across two connections is one in 2^32, which is acceptable. ✨

why the random starting point? mainly so admins can debug stuff. 🧚 if every connection used the same sequence, it'd be way easier for a human to mix up different packets with the same Token. starting at a random value spreads the values across the allowed set, so they're more likely to be unique. lowkey genius. 🌈

also, there's no special meaning for the Token, so when the counter "wraps" from a high value back to zero, nothing special happens. the sender just keeps incrementing and moves on. 💅

once a RADIUS response to a request has been received and you don't need to track the packet anymore, the Token value can be reused. 🦋 this only happens when the counter wraps around after 2^32 packets have been sent over one connection. that gives a long gap (2^32 packets) between uses of the same Token. so the only real conflict case is when a client sends billions of packets a second on one connection, or sends billions of packets without getting replies. we think those situations are vanishingly rare. 🥹 the best fix for them would be to keep outstanding packets on one connection way below billions. 🫧

if a RADIUS client has multiple independent subsystems sending packets to a server, each subsystem MAY open a new connection unique to that subsystem. 🌷 there's no requirement that all packets go over one particular connection. so even with the 32-bit Token field, RADIUS/1.1 clients are still allowed to open multiple source ports, as discussed in [RFC2865], Section 2.5. 🎀

that said, multiple connections are allowed, but we're reiterating the suggestion from [RFC3539], Section 3.3 that a single connection is preferred. 💜 one connection can improve throughput and latency and makes it easier for the client to figure out server status. main character energy for a single connection ✨

4.2.2. Receiving Packets 🌸

okay so a server that receives RADIUS/1.1 packets MUST perform packet deduplication in every situation where RADIUS requires it. 🫶 where RADIUS doesn't require deduplication (like TLS transport), the server SHOULD NOT do deduplication. but DTLS transport is UDP-based, so it still needs deduplication. 🦋

when you're using RADIUS/1.1, implementations MUST do deduplication only on the Token field, and not on any other field or fields in the packet header. 💅 a server MUST treat the Token as an opaque field with no intrinsic meaning. this is what keeps receiver behavior independent of how the Counter gets generated. 🧚

where Token deduplication is done, it MUST be done per connection. 🌈 if two packets received on different connections have the same Token value, they MUST be treated as distinct (different) packets. systems doing deduplication MAY still track the packet Code, Length, and Attributes associated with a Token value. 👑 if they figure out the sender is reusing Token values for distinct outstanding packets, an error should be logged and the connection MUST be closed. 💀 there's no way to negotiate correct behavior in the protocol. either both parties operate normally and can talk, or one end misbehaves and nothing gets through. no in-between, bestie. 😭

once a reply has been sent, a system doing deduplication SHOULD cache the replies, as discussed in [RFC5080], Section 2.2.2:

Each cache entry SHOULD be purged after a period of time. This time SHOULD be no less than 5 seconds, and no more than 30 seconds. After about 30 seconds, most RADIUS clients and end users will have given up on the authentication request. Therefore, there is little value in having a larger cache timeout.

this change from RADIUS means the Identifier field is no longer useful for RADIUS/1.1. 🙈 the Reserved-1 field (which used to be the Identifier) MUST be set to zero when encoding all RADIUS/1.1 packets. and implementations of RADIUS/1.1 that receive packets MUST ignore this field. 🍓

5. Attribute Handling 🎀

most attributes in RADIUS have no special encoding "on the wire" and no special meaning between client and server. 🦋 unless this section says otherwise, all RADIUS attributes are unchanged in this specification. that includes attributes with a tag, as defined in [RFC2868]. ✨

5.1. Obfuscated Attributes 🔐

since the (D)TLS layer already handles connection authentication, integrity checks, and confidentiality, there's no need to hide an attribute's contents on a hop-by-hop basis. 💖 so every attribute defined as obfuscated via the shared secret no longer gets the obfuscation step when RADIUS/1.1 is used. instead, those attributes MUST be encoded using the encoding for their underlying data type, with any encryption / obfuscation step omitted. 🌸 for example, User-Password is no longer obfuscated and is sent as data type "text".

but yikes, there are still risks with sending passwords over the network, even under TLS. 😭 one big one is the common practice of multi-hop RADIUS routing. since all RADIUS security is hop-by-hop, every proxy that receives a RADIUS packet can see (and modify) all the info in it. 💀 sites that want to avoid proxies SHOULD use dynamic peer discovery [RFC7585], which lets clients connect directly to authoritative servers for a realm. 🧚

there are other ways to mitigate this. the simplest is to follow the requirements of item (3) from [RFC6614], Section 3.4, and also follow [RFC7360], Section 10.4, which mandates that RADIUS over TLS implementations validate the peer before sending any RADIUS traffic. 🫶

another option is for the system being authenticated to use an authentication protocol that never sends passwords (like an Extensible Authentication Protocol (EAP) method such as EAP-pwd [RFC5931]), or one that sends passwords protected by a TLS tunnel (like EAP Tunneled Transport Layer Security (EAP-TTLS) [RFC5281]). 🌈 choosing and configuring an authentication protocol is super site-dependent, so further discussion of these issues is outside this document. the goal is just to make sure you have enough info to make an informed decision. 👑

and since the RADIUS shared secret is no longer used in this spec, it's no longer possible or necessary for any attribute to be obfuscated on a hop-by-hop basis using the previous RADIUS methods. 🔥

5.1.1. User-Password 💖

the User-Password attribute ([RFC2865], Section 5.2) MUST be encoded the same as any other attribute of data type "string" ([RFC8044], Section 3.5). 🎀

the contents of the User-Password field MUST be at least one octet in length and MUST NOT be more than 128 octets in length. 🦋 this limit is kept from [RFC2865], Section 5.2 for compatibility with historic transports. ✨

note that User-Password is not of data type "text". the original reason in [RFC2865] was that the attribute was encoded as an opaque, obfuscated binary blob. 🙈 this document doesn't change User-Password's data type, even though it's no longer obfuscated. the contents don't have to be printable text or UTF-8 data, per the definition of the "text" data type in [RFC8044], Section 3.4. 💅

however, implementations should know that passwords are often printable text, and where they are, it can be useful to store and display them as printable text. 🌸 where implementations can process non-printable data in the "text" data type, they MAY use "text" for User-Password. 🧚

5.1.2. CHAP-Challenge 🔐

[RFC2865], Section 5.3 lets the CHAP challenge come from either the CHAP-Challenge attribute ([RFC2865], Section 5.40) or the Request Authenticator field. 🍓 since RADIUS/1.1 connections no longer use a Request Authenticator field, you can't use the Request Authenticator as the CHAP-Challenge when this transport profile is in use. 💀

clients that send a CHAP-Password attribute ([RFC2865], Section 5.3) in an Access-Request packet over a RADIUS/1.1 connection MUST also include a CHAP-Challenge attribute ([RFC2865], Section 5.40). 👑

proxies might need to receive Access-Request packets over a non-RADIUS/1.1 transport and then forward them over a RADIUS/1.1 connection. 🫶 in that case, if the received Access-Request has a CHAP-Password attribute but no CHAP-Challenge attribute, the proxy MUST create a CHAP-Challenge attribute in the proxied packet using the contents from the incoming Request Authenticator of the received packet. 🌈 bestie, that's the whole plan for CHAP in RADIUS/1.1 💜

5.1.3. Tunnel-Password 🔐

okay so the Tunnel-Password attribute ([RFC2868], Section 3.5) MUST be encoded the same way as any other attribute of data type "string" that contains a tag, like Tunnel-Client-Endpoint ([RFC2868], Section 3.3) 🏷️. Since it's no longer obfuscated in RADIUS/1.1, there's no need for a Salt field or Data-Length fields like in [RFC2868], Section 3.5. The password's text can just be encoded as is ✨.

ngl this is so satisfying: it's giving "less wrapping, more clarity" 💅. Tunnel-Password is not of data type "text". The reason in [RFC2868] was that the attribute was an opaque, obfuscated binary blob, and we keep that data type here even though it isn't obfuscated anymore 🧩. So the contents of Tunnel-Password don't have to be printable text or UTF-8 data, which is the definition of the "text" data type in [RFC8044], Section 3.4.

But bestie, implementations should know that passwords are often printable text 👀. When they are, it can be super useful to store and display them as printable text 📝. Where an implementation can handle non-printable data in the "text" data type, it MAY use the data type "text" for Tunnel-Password 🌸.

5.1.4. Vendor-Specific Attributes 🎀

Any Vendor-Specific attribute that uses similar obfuscation MUST be encoded according to its base data type 💜. Specifically, the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes ([RFC2548], Section 2.4) MUST be encoded as any other attribute of data type "string" ([RFC8044], Section 3.4) 🫶.

5.2. Message-Authenticator 🛡️

The Message-Authenticator attribute ([RFC3579], Section 3.2) MUST NOT be sent over a RADIUS/1.1 connection 🙅‍♀️. That attribute isn't used or needed in RADIUS/1.1 💀.

If the Message-Authenticator attribute is received over a RADIUS/1.1 connection, it MUST be silently discarded or treated as an "invalid attribute", as defined in [RFC6929], Section 2.8 🫥. Basically, Message-Authenticator is no longer used to authenticate packets for the RADIUS/1.1 transport. Whether it's there or not on this transport is meaningless 🤷‍♀️.

A system that receives a Message-Authenticator attribute in a packet MUST treat it as an "invalid attribute" as defined in [RFC6929], Section 2.8 🙈. The packet can still be processed, even if the Message-Authenticator attribute is ignored ✨.

For proxies, Message-Authenticator has always been defined as created and consumed on a "hop-by-hop" basis 🔁. So a proxy that received a Message-Authenticator attribute from a client would never forward that attribute as is to another server 🚫. Instead, the proxy would either suppress it or recreate the Message-Authenticator attribute in the outgoing request 🧁. RADIUS/1.1 leans on this existing behavior to suppress the use of Message-Authenticator over a RADIUS/1.1 connection 🦋.

A proxy may receive an Access-Request packet over a RADIUS/1.1 connection and then forward that packet over a RADIUS/UDP or a RADIUS/TCP connection 🌈. In that situation, the proxy SHOULD add a Message-Authenticator attribute to every Access-Request packet that is sent over an insecure transport protocol 🔐.

The original text in [RFC3579], Section 3.3, Note 1 required the Message-Authenticator attribute to be present for certain Access-Request packets 📜. It also required using Message-Authenticator when the Access-Request packet contained an EAP-Message attribute 🧾. Experience has shown that some RADIUS clients never use Message-Authenticator, even in the situations where its use is suggested 😭.

When Message-Authenticator is missing from Access-Request packets, it's often possible to trivially forge or replay those packets 🚨. So it is RECOMMENDED that RADIUS clients always include Message-Authenticator in Access-Request packets when using UDP or TCP transport 💖. This document's scope is limited to defining RADIUS/1.1, so we can't mandate that behavior here 🥺. What we can say is that there are no known negatives to this behavior, and there are definite positives, such as increased security 🔥.

Further issues related to Message-Authenticator are discussed in [DEPRECATE-RADIUS] 📚.

5.3. Message-Authentication-Code 🧾

Similarly, the Message-Authentication-Code attribute defined in [RFC6218], Section 3.3 MUST NOT be sent over a RADIUS/1.1 connection 🚫. If it's received in a packet, it MUST be treated as an "invalid attribute" as defined in [RFC6929], Section 2.8 ⚠️.

Because Message-Authentication-Code is no longer used in RADIUS/1.1, the related MAC-Randomizer attribute ([RFC6218], Section 3.2) MUST NOT be sent over a RADIUS/1.1 connection 🙅‍♀️. If it's received in a packet, it MUST be treated as an "invalid attribute" as defined in [RFC6929], Section 2.8 🫠.

5.4. CHAP, MS-CHAP, and Similar Attributes 🧁

While some attributes, like CHAP-Password, depend on insecure cryptographic primitives such as MD5, these attributes are treated as opaque blobs when sent between a RADIUS client and server 📦. Their contents aren't obfuscated, and they don't depend on the RADIUS shared secret 🔑. So these attributes stay unchanged in RADIUS/1.1 ✨.

MS-CHAP depends on MD4, and RADIUS/1.1 does not change the definition of any MS-CHAP attributes 🙃. But MS-CHAP has been broken for decades, as noted in [ASLEAP] 💀. The only appropriate use case for MS-CHAP is when it's protected by a secure transport such as RADIUS/TLS or RADIUS/DTLS, or when it's used for "inner tunnel" authentication methods, like with the Protected Extensible Authentication Protocol (PEAP) or TTLS 🛡️.

A server implementing this specification can proxy and authenticate CHAP, MS-CHAP, etc. without any issue 👑. RADIUS/1.1 changes how RADIUS packets are authenticated and how "secret" data is obfuscated inside of a RADIUS packet 🎭. It does not change any authentication method that's transported inside of RADIUS 💅.

5.5. Original-Packet-Code 🔍

[RFC7930], Section 4 defines an Original-Packet-Code attribute 📖. This attribute is needed because otherwise it's impossible to correlate the Protocol-Error response packet with a particular request packet 🧩. The definition in [RFC7930], Section 4 describes the reasoning behind this need:

|  The Original-Packet-Code contains the code from the request that
|  generated the protocol error so that clients can disambiguate
|  requests with different codes and the same ID.

Original-Packet-Code is no longer needed in RADIUS/1.1 🥳. The Identifier field is unused, so it's impossible for two requests to have the "same" ID 🙌. Instead, the Token field lets clients and servers correlate requests and responses, no matter what Code value is being used 🎀.

So the Original-Packet-Code attribute ([RFC7930], Section 4) MUST NOT be sent over a RADIUS/1.1 connection 🚫. If it's received in a packet, it MUST be treated as an "invalid attribute" as defined in [RFC6929], Section 2.8 ⚠️.

6. Other Considerations When Using ALPN ✨

Most of the differences between RADIUS and RADIUS/1.1 are in the packet header and attribute handling, as we covered above 💜. The remaining issues are a small set of unrelated topics, and we'll cover them here 🌸.

6.1. Protocol-Error 🚨

There are a number of situations where a RADIUS server is unable to respond to a request 😩. One is when the server depends on a database and the database is down 🗄️. Arguably, the server should close all incoming connections when it can't do anything, but that action isn't always effective 🙃. A client may aggressively try to open new connections or send packets to an unconnected UDP destination where the server isn't listening 📡. Another situation is when the server is proxying packets and the outbound connections are either full or failed 🧱.

In all RADIUS specifications before this one, there was no way for the server to send a client the positive signal that it received a request but couldn't send a response 😵. Instead, the server usually just discards the request, which to the client looks exactly like the server being down 👻. It gets worse because some proxied packets might succeed while others fail 🎢. The client can only conclude that the server is randomly dropping packets and is unreliable 💀.

It would be super useful for servers to signal clients that they received a request but can't process it 🫶. This specification uses the Protocol-Error packet ([RFC7930], Section 4) as that signal 📣. Protocol-Error allows for both hop-by-hop signaling in the case of proxy forwarding errors, and end-to-end signaling from server to client 🔁. This kind of signaling should greatly improve the robustness of the RADIUS protocol 🦋.

When a RADIUS/1.1 server determines that it's unable to process an Access-Request or Accounting-Request packet, it MUST respond with a Protocol-Error packet containing an Error-Cause attribute 🧾. A proxy that can't forward the packet MUST respond with either 502 (Request Not Routable (Proxy)) or 505 (Other Proxy Processing Error) 🛑. This requirement helps distinguish failures in the proxy chain from failures at the final (i.e., home) server 🏠.

For a home server, if none of the Error-Cause values match the reason for the failure, then the value 506 (Resources Unavailable) MUST be used 🙏.

When a RADIUS proxy receives a Protocol-Error reply, it MUST examine the value of the Error-Cause attribute 🔎. If there's no Error-Cause attribute, or if its value is something other than 502 (Request Not Routable (Proxy)), 505 (Other Proxy Processing Error), or 506 (Resources Unavailable), then the proxy MUST return the Protocol-Error response packet to the client and include the Error-Cause attribute from the response it received 📬. This process allows for full "end-to-end" signaling of servers to clients 💖.

In all situations other than those in the preceding paragraph, a client that receives a Protocol-Error reply MUST reprocess the original outgoing packet through the client forwarding algorithm 🔄. This includes both clients that originate RADIUS traffic and proxies that see an Error-Cause attribute of 502 (Request Not Routable (Proxy)) or 505 (Other Proxy Processing Error) 🫠.

The expected result is that the client forwards the packet to a different server 🏃‍♀️. Clients MUST NOT forward the packet over the same connection, and they SHOULD NOT forward it over a different connection to the same server 🚫.

This process may continue over multiple connections and multiple servers, until the client either times out the request or fails to find a forwarding destination for the packet 🌀. A proxy that can't forward a packet MUST reply with a Protocol-Error packet containing an Error-Cause, as defined above 🧾. A client that originates packets MUST treat such a request as if it had received no response 🙈.

This behavior is meant to improve the stability of the RADIUS protocol by addressing issues first raised in [RFC3539], Section 2.8 🌈.

6.2. Status-Server 💅

okay so [RFC6613], Section 2.6.5, and by extension [RFC7360], suggest that the Identifier value zero (0) be reserved for use with Status-Server as an application-layer watchdog 🧚. This practice MUST NOT be used for RADIUS/1.1, bc the Identifier field is not used in this transport profile 🙅‍♀️.

the reason for reserving one value of the Identifier field was that there were only 256 Identifiers to go around 🥺, and Access-Request packets and Status-Server packets could overlap on them. if all 256 Identifier values had been used to send Access-Request packets, then there would be no Identifier value left for sending a Status-Server packet 💀.

but RADIUS/1.1 is giving main character energy here 👑. the Token field allows for 2^32 outstanding packets on one RADIUS/1.1 connection 😭🔥. if there is a need to send a Status-Server packet, it is nearly always possible to allocate a new value for the Token field ✨. if instead there are 2^32 outstanding packets for one connection, then it is likely that something has gone catastrophically wrong 🙈. in that case, the safest way forward is likely to just close the connection 🫶.

6.3. Proxies 🦋

a RADIUS proxy normally decodes and then re-encodes all attributes, including obfuscated ones 🍓. a RADIUS proxy will not generally rewrite the content of the attributes it proxies (unless site-local policy requires such a rewrite) 💜. some attributes may be modified due to administrative or policy rules on the proxy, but the proxy will generally not rewrite the contents of attributes such as User-Password, Tunnel-Password, CHAP-Password, MS-CHAP-Password, MS-MPPE keys, etc. ✨. so, all attributes are transported through a RADIUS/1.1 connection without changing their values or contents 🌸.

a proxy may negotiate RADIUS/1.1 (or not) with a particular client or clients, and it may negotiate RADIUS/1.1 (or not) with a server or servers it connects to, in any combination 🌈. as a result, this specification is fully compatible with all past, present, and future RADIUS attributes 🎀😭.

7. Other RADIUS Considerations 🌷

this section talks about issues in RADIUS that need to be addressed in order to support ALPN, but which aren't directly part of the RADIUS/1.1 protocol 🧚‍♀️.

7.1. Crypto-Agility 🔐

the crypto-agility requirements of [RFC6421] are addressed in [RFC6614], Appendix C and in [RFC7360], Section 10.1 ✨. this specification makes no changes or additions to those specifications 💅. the use of ALPN and the removal of MD5 has no impact on the security or privacy of the protocol 🫶.

RADIUS/TLS has been widely deployed in at least eduroam ([RFC7593] and [EDUROAM]) and in OpenRoaming [OPENROAMING] 🌍✨. RADIUS/DTLS has seen less adoption, but it is known to be supported in many RADIUS clients and servers 🦋.

It is RECOMMENDED that all implementations of historic RADIUS/TLS be updated to support this specification 💖. where a system already implements RADIUS over TLS, the additional effort to implement this specification is minimal 🥰. once implementations support it, administrators can gain the benefit of it with little or no configuration changes 🎀. this specification is backwards compatible with [RFC6614] and [RFC7360] 💜. it is only potentially subject to down-bidding attacks if implementations do not enforce ALPN correctly on session resumption 😱⚠️.

⚠️ down-bidding attacks are only a possibility if ALPN isn't enforced correctly on session resumption. bestie, please make sure your implementation enforces it 🙏💀

all crypto-agility needed or used by this specification is implemented in TLS 🔒. this specification also removes all cryptographic primitives from the application-layer protocol (RADIUS) being transported by TLS 🧁. as discussed in the following section, this specification also bans the development of all new cryptographic or crypto-agility methods in the RADIUS protocol 🚫🌸.

7.2. Error-Cause Attribute 🎀

the Error-Cause attribute is defined in [RFC5176] 📜. the "Table of Attributes" section given in [RFC5176], Section 3.6 permits that attribute to appear in CoA-NAK and Disconnect-NAK packets 👀. as no other packet type is listed, the implication is that the Error-Cause attribute cannot appear in any other packet 🙃. [RFC7930] also permits Error-Cause to appear in Protocol-Error packets 🧚.

BUT, [RFC5080], Section 2.6.1 suggests that Error-Cause may appear in Access-Reject packets 😳. no explanation is given for this change from [RFC5176] 🤨. there is not even an acknowledgment that this suggestion is a change from any previous specification 💀. we fix that issue here 💪✨.

this specification updates [RFC5176] to allow the Error-Cause attribute to appear in Access-Reject packets 🎉. It is RECOMMENDED that implementations include the Error-Cause attribute in Access-Reject packets where appropriate 💖.

so basically, the reason for sending the Access-Reject packet (or the Protocol-Error packet) may match a defined Error-Cause value 🎯. in that case, it is useful for implementations to send an Error-Cause attribute with that value 🙌. this behavior can help RADIUS system administrators debug issues in complex proxy chains 🕵️‍♀️🔍.

for example, a proxy may normally forward Access-Request packets that contain EAP-Message attributes 📦. the proxy can determine if the contents of the EAP-Message are invalid 🧐. one example of an invalid EAP-Message is where the first octet has value larger than 4 🙅‍♀️. in that case, there may be no benefit to forwarding the packet, as the home server will reject it 😤. it may then be possible for the proxy (with the knowledge and consent of involved parties) to immediately reply with an Access-Reject containing an Error-Cause attribute with value 202 (Invalid EAP Packet (Ignored)) 💫.

another possibility is that a proxy is configured to forward packets for a particular realm, but it has determined that there are no available connections to the next hop for that realm 🫠. in that case, it may be possible for the proxy (again, with the knowledge and consent of involved parties) to reply with an Access-Reject containing an Error-Cause attribute with value 502 (Request Not Routable (Proxy)) 🚏.

these examples are given only for illustrative and informational purposes 📚. while it is useful to return an informative value for the Error-Cause attribute, proxies can only modify the traffic they forward with the explicit knowledge and consent of all involved parties 🤝💜.

7.3. Future Standards 🔮

future work may define new attributes, packet types, etc. 🛠️. it is important to be able to do such work without requiring that every new standard mention RADIUS/1.1 explicitly 🙏. this document defines RADIUS/1.1 as having functional overlap with legacy RADIUS: the protocol state machine is unchanged, the packet header Code field is unchanged, and the attribute format is largely unchanged 🧩. as a result, any new packet Code or attribute defined for RADIUS is explicitly compatible with RADIUS/1.1; the field contents and meanings are identical 🥹💕. the only difference between the two protocols is that obfuscated attributes in RADIUS are not obfuscated in RADIUS/1.1, and this document defines how that mapping is done 🗺️.

any future specification only needs to mention RADIUS/1.1 if it adds fields to the RADIUS/1.1 packet header 📝. otherwise, transport considerations for RADIUS/1.1 are identical to RADIUS over (D)TLS 🧃.

we reiterate that this specification defines a new transport profile for RADIUS 🎀. it does not define a completely new protocol 🙅‍♀️. Any future specification that defines a new attribute MUST define it for RADIUS/UDP first, and afterwards those definitions can be applied to this transport profile 🪄.

New specifications MAY define new attributes that use the obfuscation methods for User-Password as defined in [RFC2865], Section 5.2 or for Tunnel-Password as defined in [RFC2868], Section 3.5 🔑. there is no need for those specifications to describe how those new attributes are transported in RADIUS/1.1 🙌. since RADIUS/1.1 does not use MD5, any obfuscated attributes will by definition be transported as their underlying data type "text" ([RFC8044], Section 3.4) or "string" ([RFC8044], Section 3.5) 📦💅.

New RADIUS specifications MUST NOT define attributes that can only be transported via RADIUS over TLS 🛑. the RADIUS protocol has no way to signal the security requirements of individual attributes 😬. any existing implementation will handle these new attributes as "invalid attributes" ([RFC6929], Section 2.8) and could forward them over an insecure link 😱. as RADIUS security and signaling is hop-by-hop, there is no way for a RADIUS client or server to even know if such forwarding is taking place 👻. for these reasons and more, it is therefore inappropriate to define new attributes that are only secure if they use a secure transport layer 🙅‍♀️💀.

the result is that specifications do not need to mention this transport profile or make any special provisions for dealing with it ✨. this specification defines how RADIUS packet encoding, decoding, authentication, and verification are performed when using RADIUS/1.1 🧠. so long as any future specification uses the existing schemes for encoding, decoding, etc., that are defined for RADIUS, no additional text in future documents is necessary in order to be compatible with RADIUS/1.1 🫶🌈.

we note that it is theoretically possible for future standards to define new cryptographic primitives for use with RADIUS/UDP 🤔. in that case, those documents would likely have to describe how to transport that data in RADIUS/1.1 📮. we believe that such standards are unlikely to be published, as other efforts in the RADEXT Working Group are forbidding such updates to RADIUS 🚫✋.

8. Privacy Considerations 🕊️

this specification requires secure transport for RADIUS 🔐. RADIUS/1.1 has all of the privacy benefits of RADIUS/TLS [RFC6614] and RADIUS/DTLS [RFC7360] and none of the privacy or security issues of RADIUS/UDP [RFC2865] or RADIUS/TCP [RFC6613] 🥺💜✨.

9. Security Considerations 🔐✨

Okay so, bestie, this is the part where we talk about what can go wrong and why it's (mostly) not a disaster. 😭 The main focus of this document is security for RADIUS 💅. This spec leans on TLS and ALPN for a LOT of its safety, so if you want the deep dive, go read [RFC8446] and [RFC7360] 📚. This section is only about the stuff that's unique to this spec, no cap 🫶.

Implementations should rely on the underlying TLS library to do ALPN version negotiation 🎀. Like, supply a list of permitted ALPN strings to the TLS library and let it hand back the negotiated value. Don't reinvent the wheel, babe 💖.

There aren't a ton of other openings for security issues 🌸. But if an implementation gets ALPN wrong, the wrong application data gets sent inside TLS 💀. RADIUS/1.0 and RADIUS/1.1 have similar packet formats, but they are NOT mutually compatible 🙈. (Yes, I'm yelling, because it matters 📣.)

When an implementation gets packets for a RADIUS version the connection doesn't support, it won't be able to process them 🥺. It can log messages saying the application-layer data is unexpected and then close the connection 🔒. Also, the implementations that see the incorrect data already have full access to all the secrets and passwords being transported 👀, so any protocol differences don't create new security issues 🍓. And since ALL of the application data is protected by TLS, an attacker can't get any extra data out of this misconfiguration 🛡️✨. Safe and sound, iykyk 🦋.

RADIUS/1.0 requests sent over a RADIUS/1.1 connection MAY be accepted by the RADIUS/1.1 server 🎀. The server ignores the ID field and tries to use parts of the Request Authenticator as a Token 🤔. But the reply from the RADIUS/1.1 server will FAIL the Response Authenticator validation at the RADIUS/1.0 client 😬. So those responses get dropped 🗑️. The client will usually log these failures, and an administrator will go fix the issue 🧑‍💻💅.

RADIUS/1.1 requests sent over a RADIUS/1.0 connection will generally be discarded by the RADIUS/1.0 server 💀, because the packets fail the Request Authenticator checks 🚫. Basically, all request packets like Accounting-Request, CoA-Request, and Disconnect-Request get thrown out by the server 😭. For Access-Request packets containing EAP-Message, the packets are missing Message-Authenticator, so they get discarded too 🙅‍♀️. Other Access-Request packets with obfuscated attributes like User-Password get those attributes decoded into nonsense 🌀, which results in Access-Reject responses 💔.

RADIUS/1.1 Access-Request packets containing non-obfuscated attributes like CHAP-Password MAY be accepted by a RADIUS/1.0 server ✨. But the response will contain a Response Authenticator (an MD5 hash) instead of a Token that matches the Token in the request 🧩. A similar analysis applies to Access-Request packets containing Service-Type = Authorize-Only 🎀.

So, in conclusion 💅: any version mismatch between client and server means most request packets get discarded by the server, and all response packets get discarded by the client 🫠. The two protocols are INCOMPATIBLE, and that's what keeps us safe from misconfigurations and buggy implementations 👑🌈.

10. IANA Considerations 📋🦋

IANA has updated the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry with two new entries 🎀:

Protocol:  RADIUS/1.0
Identification Sequence:  0x72 0x61 0x64 0x69 0x75 0x73 0x2f 0x31
   0x2e 0x30 ("radius/1.0")
Reference:  RFC 9765
Protocol:  RADIUS/1.1
Identification Sequence:  0x72 0x61 0x64 0x69 0x75 0x73 0x2f 0x31
   0x2e 0x31 ("radius/1.1")
Reference:  RFC 9765

11. References 📚💖

11.1. Normative References 🌟

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
           "Remote Authentication Dial In User Service (RADIUS)",
           RFC 2865, DOI 10.17487/RFC2865, June 2000,
           <https://www.rfc-editor.org/info/rfc2865>.

[RFC6421]  Nelson, D., Ed., "Crypto-Agility Requirements for Remote
           Authentication Dial-In User Service (RADIUS)", RFC 6421,
           DOI 10.17487/RFC6421, November 2011,
           <https://www.rfc-editor.org/info/rfc6421>.

[RFC6614]  Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
           "Transport Layer Security (TLS) Encryption for RADIUS",
           RFC 6614, DOI 10.17487/RFC6614, May 2012,
           <https://www.rfc-editor.org/info/rfc6614>.

[RFC6929]  DeKok, A. and A. Lior, "Remote Authentication Dial In User
           Service (RADIUS) Protocol Extensions", RFC 6929,
           DOI 10.17487/RFC6929, April 2013,
           <https://www.rfc-editor.org/info/rfc6929>.

[RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
           "Transport Layer Security (TLS) Application-Layer Protocol
           Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
           July 2014, <https://www.rfc-editor.org/info/rfc7301>.

[RFC7360]  DeKok, A., "Datagram Transport Layer Security (DTLS) as a
           Transport Layer for RADIUS", RFC 7360,
           DOI 10.17487/RFC7360, September 2014,
           <https://www.rfc-editor.org/info/rfc7360>.

[RFC8044]  DeKok, A., "Data Types in RADIUS", RFC 8044,
           DOI 10.17487/RFC8044, January 2017,
           <https://www.rfc-editor.org/info/rfc8044>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

11.2. Informative References 🦄

[ASLEAP]   "asleap - recovers weak LEAP and PPTP passwords", commit
           254acab, November 2020,
           <https://github.com/joswr1ght/asleap>.

[DEPRECATE-RADIUS]
           DeKok, A., "Deprecating Insecure Practices in RADIUS",
           Work in Progress, Internet-Draft, draft-ietf-radext-
           deprecating-radius-05, 26 November 2024,
           <https://datatracker.ietf.org/doc/html/draft-ietf-radext-
           deprecating-radius-05>.

[EDUROAM]  eduroam, "eduroam", <https://eduroam.org>.

[FIPS-140-3]
           NIST, "Security Requirements for Cryptographic Modules",
           NIST FIPS 140-3, DOI 10.6028/NIST.FIPS.140-3, March 2019,
           <https://nvlpubs.nist.gov/nistpubs/FIPS/
           NIST.FIPS.140-3.pdf>.

[OPENROAMING]
           Wireless Broadband Alliance, "OpenRoaming: One global Wi-
           Fi network", <https://wballiance.com/openroaming/>.

[RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
           DOI 10.17487/RFC1321, April 1992,
           <https://www.rfc-editor.org/info/rfc1321>.

[RFC2548]  Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
           RFC 2548, DOI 10.17487/RFC2548, March 1999,
           <https://www.rfc-editor.org/info/rfc2548>.

[RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866,
           DOI 10.17487/RFC2866, June 2000,
           <https://www.rfc-editor.org/info/rfc2866>.

[RFC2868]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
           M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
           Support", RFC 2868, DOI 10.17487/RFC2868, June 2000,
           <https://www.rfc-editor.org/info/rfc2868>.

[RFC3539]  Aboba, B. and J. Wood, "Authentication, Authorization and
           Accounting (AAA) Transport Profile", RFC 3539,
           DOI 10.17487/RFC3539, June 2003,
           <https://www.rfc-editor.org/info/rfc3539>.

[RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
           Dial In User Service) Support For Extensible Authentication
           Protocol (EAP)", RFC 3579, DOI 10.17487/RFC3579, September
           2003, <https://www.rfc-editor.org/info/rfc3579>.

[RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
           "Transport Layer Security (TLS) Session Resumption without
           Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
           January 2008, <https://www.rfc-editor.org/info/rfc5077>.

[RFC5080]  Nelson, D. and A. DeKok, "Common Remote Authentication
           Dial In User Service (RADIUS) Implementation Issues and
           Suggested Fixes", RFC 5080, DOI 10.17487/RFC5080, December
           2007, <https://www.rfc-editor.org/info/rfc5080>.

[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,
           DOI 10.17487/RFC5176, January 2008,
           <https://www.rfc-editor.org/info/rfc5176>.

[RFC5281]  Funk, P. and S. Blake-Wilson, "Extensible Authentication
           Protocol Tunneled Transport Layer Security Authenticated
           Protocol Version 0 (EAP-TTLSv0)", RFC 5281,
           DOI 10.17487/RFC5281, August 2008,
           <https://www.rfc-editor.org/info/rfc5281>.

[RFC5931]  Harkins, D. and G. Zorn, "Extensible Authentication
           Protocol (EAP) Authentication Using Only a Password",
           RFC 5931, DOI 10.17487/RFC5931, August 2010,
           <https://www.rfc-editor.org/info/rfc5931>.

[RFC6151]  Turner, S. and L. Chen, "Updated Security Considerations
           for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
           RFC 6151, DOI 10.17487/RFC6151, March 2011,
           <https://www.rfc-editor.org/info/rfc6151>.

[RFC6218]  Zorn, G., Zhang, T., Walker, J., and J. Salowey, "Cisco
           Vendor-Specific RADIUS Attributes for the Delivery of
           Keying Material", RFC 6218, DOI 10.17487/RFC6218, April
           2011, <https://www.rfc-editor.org/info/rfc6218>.

[RFC6613]  DeKok, A., "RADIUS over TCP", RFC 6613,
           DOI 10.17487/RFC6613, May 2012,
           <https://www.rfc-editor.org/info/rfc6613>.

[RFC7585]  Winter, S. and M. McCauley, "Dynamic Peer Discovery for
           RADIUS/TLS and RADIUS/DTLS Based on the Network Access
           Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October
           2015, <https://www.rfc-editor.org/info/rfc7585>.

[RFC7593]  Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
           Architecture for Network Roaming", RFC 7593,
           DOI 10.17487/RFC7593, September 2015,
           <https://www.rfc-editor.org/info/rfc7593>.

[RFC7930]  Hartman, S., "Larger Packets for RADIUS over TCP", RFC 7930,
           DOI 10.17487/RFC7930, August 2016,
           <https://www.rfc-editor.org/info/rfc7930>.

[RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
           Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
           <https://www.rfc-editor.org/info/rfc8446>.

Acknowledgments 🫶🌷

Thanks to Bernard Aboba, Karri Huhtanen, Heikki Vatiainen, Alexander Clouter, Michael Richardson, Hannes Tschofenig, Matthew Newton, and Josh Howlett for reviews and feedback 💕. You all are literally the best 😭🙌.

Author's Address 📮

Alan DeKok FreeRADIUS Email: aland@freeradius.org

📦 where this page comes from