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.
\nIETF 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.
\nThe 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.
\nRemoving 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.
\nKeep 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.
\nDefine 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.
\nRetain 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.
\n