Pilot Experimental RADIUS/1.1 without silently breaking AAA

RADIUS/1.1 is published as an Experimental RFC. Its security and transport changes are technically significant, but that status calls for a bounded pilot and explicit interoperability evidence—not an assumption that every NAS, proxy, and server can adopt it safely.

Source fact:

IETF RFC 9765 defines Application-Layer Protocol Negotiation identifiers and protocol extensions for using Experimental RADIUS/1.1 over TLS and DTLS. In that protected transport, RADIUS/1.1 removes the RADIUS shared secret and the protocol’s MD5-based packet authentication and attribute-obfuscation mechanisms. The secure transport provides the cryptographic channel and peer authentication expected by the new mode.

The RFC does not change ordinary RADIUS over UDP or TCP. It explicitly has Experimental status, which means it is suitable for evaluation and experience rather than being presented as an Internet Standards Track requirement. Correct version negotiation through ALPN and correct handling at every proxy boundary are central to interoperability.

Boundary

Removing the RADIUS shared secret in RADIUS/1.1 does not remove the need for strong TLS identities, authorization, certificate lifecycle, or protection of the AAA service. Mixed transports can preserve legacy MD5-based behavior on other hops. A successful TLS handshake does not prove that attributes, message authentication, retransmission, duplicate detection, accounting, change-of-authorization, or policy decisions work as intended. Product support may be partial or labeled experimental itself.

Applicability questions

• Do the exact NAS, proxy, load balancer, and RADIUS releases implement RFC 9765 and the required ALPN behavior?
• Where does TLS or DTLS terminate, and what protocol protects every subsequent hop?
• Which certificate names, trust anchors, roles, renewal paths, and revocation behavior authenticate peers?
• What happens when ALPN negotiation fails or a peer supports only a legacy transport?
• Can fallback ever bypass the intended security or authorization policy?

DSE recommendation:

Keep the first implementation outside production access. Build a matrix that covers each client, server, proxy, transport, message class, and certificate state. Capture ALPN selection and verify the negotiated RADIUS version. Exercise accept, reject, challenge, accounting, retransmission, duplicate requests, proxying, disconnect or change-of-authorization where used, and failure during a live exchange.

Define legacy coexistence and fallback as policy, not whatever the products happen to do. An unsupported or failed secure session should produce a visible, approved result and must not silently move to a less protected route. Use dedicated pilot identities and segmentation, protect private keys, and establish certificate-expiry alerts through an independent channel. Obtain vendor confirmation before any wider use.

Verification and evidence

Retain the experimental approval, full component/version matrix, configurations, certificates and trust design without private keys, decoded negotiation traces, AAA decision comparisons, failure tests, and fallback results. Evidence should correlate the same test identity’s request, server decision, network authorization, and accounting record. Record unresolved interoperation limits as blockers rather than treating basic authentication success as completion.

Official references

• IETF RFC 9765