Summary

  • RADIUS/1.1 removes the RADIUS shared secret and MD5-based packet mechanisms only on a TLS or DTLS connection that has negotiated the radius/1.1 ALPN value; it does not change RADIUS over UDP or plain TCP.
  • The meaningful migration evidence is a chain of observed states—supported, offered, selected, required and legacy-disabled—on every relevant hop, not the existence of an RFC or a compatible server release.

A correction written into the specification

Standards documents usually make their history sound inevitable. RFC 9765 does the opposite. Its introduction explains that the RADEXT working group once chose to keep the RADIUS shared secret and MD5 packet processing even when RADIUS was carried inside TLS. TLS was treated as a wrapper, leaving the familiar encoder, decoder and validation rules substantially intact. The document then judges that choice, in hindsight, as probably wrong. DeKok adds that he took part in making it.

That admission matters because it narrows the story. This is not a tale in which a new cryptographic fashion defeated an obviously foolish predecessor. Compatibility had a concrete attraction: RADIUS/TLS could be introduced without asking every implementation to reinterpret the packet at the same time. The cost appeared later. A secure transport still carried a second security mechanism based on a digest that many controlled environments could no longer permit.

DeKok had lived with both sides of that bargain. His IETF profile says he encountered RADIUS in 1997, started FreeRADIUS in 1999 and contributed across several authentication and protocol working groups. The FreeRADIUS project describes a running policy server and a surrounding set of client and integration components, not merely a paper implementation. RFC 9765 therefore comes from the junction of standards memory and software maintenance. It is still an IETF consensus document, not DeKok's private command to the network.

What is actually being replaced

The original RADIUS specification described a client-server exchange in which the client and server share a secret. That secret participates in authenticating transactions, while an MD5-based construction hides values such as the user password. Later specifications placed RADIUS over TLS and DTLS. They protected the connection, but historic RADIUS/TLS retained the packet-level shared secret and its MD5 operations.

RADIUS/1.1 changes that arrangement on a negotiated protected connection. The peers use ALPN during the TLS handshake and select the application name radius/1.1. The profile requires TLS 1.3 or later. Once selected, the RADIUS shared secret is not used on that connection. Request and Response Authenticator space becomes an opaque token for matching requests and replies; the old Identifier function is displaced; Message-Authenticator is neither sent nor relied upon; and attributes previously obscured with MD5 are carried in their ordinary encodings because TLS now supplies confidentiality.

Trust has moved, not disappeared. The implementation is trusting the TLS session to protect the hop and the ALPN result to tell both ends which packet rules apply. Certificate or peer authentication, authorization of that peer, TLS policy, key custody and monitoring become more—not less—important. Removing redundant packet cryptography is valuable precisely because the transport layer has accepted the job.

A new profile in an old-shaped packet

The name “1.1” can suggest a broad protocol generation. RFC 9765 is more conservative. It keeps the RADIUS header the same size. Code and Length mean what they meant before. Attributes that never used MD5 obfuscation retain their encoding and semantics. Existing TLS and DTLS ports remain. The document calls the result a transport profile rather than a wholesale rewrite.

Some fields do change purpose, and the two versions are not interchangeable on a connection. If a peer sends 1.0 packet semantics under a 1.1 selection, or the reverse, validation failures and discarded replies should expose the mismatch. This is useful failure containment, but it is not costless. An operator can still see authentication outages, confusing logs and a rollback decision at exactly the moment a more secure policy is being enforced.

Nor does the profile purify everything transported by RADIUS. CHAP and MS-CHAP material can remain opaque attributes. RADIUS/1.1 removes the shared-secret and MD5 machinery used to protect the RADIUS packet on this hop; it does not redefine every user authentication method, backend or credential that a RADIUS exchange may carry. “No MD5 in the transport profile” and “no legacy primitive anywhere in the access system” are different claims.

The hop is the unit of truth

The most important sentence in the design may be its scope: the profile applies to one client-to-server connection. Only the two peers that negotiated it know that it is active. In a roaming or proxy chain, the first hop may use RADIUS/1.1 while the next still uses historic RADIUS/TLS, UDP or another configured transport. A green check at an access controller says nothing by itself about the home server several proxies away.

ALPN makes that boundary observable. RFC 7301 defines the client offer and server selection inside the TLS handshake. RFC 9765 says that without the required ALPN signal a system must not assume RADIUS/1.1. Implementations supporting both generations are expected to begin by allowing both radius/1.0 and radius/1.1. Once administrators have verified both ends and observed successful negotiation, they can require 1.1 and monitor the result. If connections fail, the document permits a controlled return to dual negotiation while the fault is resolved.

That sequence is not weakness in the specification. It is the migration mechanism. Yet the compatibility default has a political economy of its own. “Capable of 1.1” can remain true for years while traffic continues to select 1.0. Procurement may count the capability, a vendor may advertise it, and an audit may find the software version—without any of them proving that the legacy profile has ceased to carry production authentication.

The durable state model is therefore explicit:

State Evidence
Supported Both products implement the profile and the required TLS version.
Offered The client actually sends the relevant ALPN name.
Selected Handshake telemetry records radius/1.1 on this connection.
Required Policy rejects a peer that cannot negotiate 1.1.
Legacy disabled Historic RADIUS/TLS and unprotected transports are no longer permitted on the scoped hop.

Skip one column and a migration report becomes an aspiration report.

Why DeKok's role is instructive

There is a tempting heroic version of this story: the creator of FreeRADIUS returns to eliminate a flaw. It is too simple. RADIUS predates FreeRADIUS; the relevant documents have many authors; the IETF review process, TLS implementers, vendors, network administrators and each owner of a proxy hop all hold part of the outcome. InkBridge identifies DeKok as the FreeRADIUS project's creator and leader, but that experience gives him influence, not sovereignty.

His more useful contribution is a method of correction. He names the earlier compromise, preserves the parts of the wire image that still carry value, moves security responsibility to the layer already doing the work, and makes the transition negotiable and measurable. The document is Experimental, so even that method remains open to implementation and evaluation. It is running code plus observed state—not authorship alone—that will decide whether the profile becomes ordinary infrastructure.

Sources