RadSec (RADIUS over TLS)
termnetworkingsecuritycryptography
Stands for: Transport Layer Security Encryption for RADIUS (RFC 6614): RADIUS over TCP port 2083 inside TLS
RADIUS over TLS, RFC 6614: the whole RADIUS packet carried inside a TLS session on TCP port 2083, with both ends authenticated by X.509 certificates and the RADIUS shared secret fixed to the literal string "radsec".
RFC 6614 (Winter of RESTENA, McCauley, Venaas and Wierenga of Cisco, May 2012, Experimental) starts from a plain statement: "RADIUS security is based on the MD5 algorithm, which has been proven to be insecure", and only the password attribute was ever hidden anyway. RadSec "wraps the entire RADIUS packet payload into a TLS stream" over TCP, on port 2083, with mutual X.509 authentication, so the usernames, MAC addresses, EAP exchanges and policy attributes that plain RADIUS sends in the clear are encrypted and the peers are authenticated by certificates rather than by a shared secret per pair. Because the RADIUS packet format still requires a secret for its internal MD5 computations, the RFC fixes it to the string radsec. The main use the RFC names is roaming across administrative domains, where RADIUS proxies belonging to different organisations forward each other's authentications over the public Internet and a per-pair shared secret does not scale; large federations of universities and operators are the motivating case. Inside an enterprise it is the answer to the audit finding that authentication traffic between switches and the policy servers crosses the network unencrypted.
RADIUS leaves almost everything it carries in clear text and authenticates its packets with MD5 and a shared secret, a design the protocol's own successor documents stopped defending. RFC 6614, Transport Layer Security (TLS) Encryption for RADIUS, published in May 2012 by Winter of RESTENA, McCauley, Venaas and Wierenga of Cisco as an Experimental document, opens with the diagnosis: "RADIUS security is based on the MD5 algorithm, which has been proven to be insecure". Its remedy is not a new protocol but a new transport. RadSec "wraps the entire RADIUS packet payload into a TLS stream", carried over TCP on port 2083, and authenticates both ends with X.509 certificates.
The design keeps the packets and changes what surrounds them. A RADIUS packet inside the TLS stream is byte for byte the packet RFC 2865 defines, codes, identifier, authenticator and attributes, so servers, proxies and the attribute dictionaries are unchanged and a TLS-terminating front end can hand ordinary RADIUS to an existing back end. Because the format's internal MD5 computations, the User-Password hiding and the response authenticator, still need a shared secret, RFC 6614 fixes it: the secret is the literal string radsec, which carries no security and is there only so the arithmetic can be performed. Security comes from TLS: confidentiality for the usernames, MAC addresses, EAP exchanges and policy attributes that plain RADIUS exposes, integrity for every attribute rather than only the password, and peer authentication by certificate, which replaces the per-pair secret that had to be configured on both ends of every relationship.
The RFC names roaming across administrative domains as the main use, and the motivating deployments were the federations in which universities and operators forward each other's authentications so that a visitor's credentials are checked at home. In such a federation a RADIUS proxy may talk to hundreds of peers it does not operate, over networks nobody controls; a shared secret per pair is unmanageable and the clear-text payload is unacceptable. Certificates issued by a federation authority solve both, and a TCP connection with TLS also gives the proxies something UDP RADIUS never had, a reliable, long-lived channel whose health is observable.
For an enterprise the case is simpler and increasingly common. Auditors who find that every 802.1X conversation and every administrator login crosses the campus or the WAN in a protocol whose only protection is MD5 over a shared secret want it encrypted, and RadSec is how the switches, controllers and policy servers that support it do that. The caveats are support and operations: a device has to implement RadSec on the NAS side as well as the server side; certificates have to be issued to switches and controllers and renewed; and the reverse-direction messages of RFC 5176, Disconnect and Change of Authorization, are protected only where both ends carry them over the same TLS session.
The status is worth stating precisely. RFC 6614 is Experimental, and the IETF's subsequent work on RADIUS transport continued after it; what is deployed under the name RadSec today is this document's protocol, TLS on TCP 2083 with the fixed secret, implemented by the major AAA servers and a growing list of network equipment. The RADIUS entry describes what is being protected, and the article on RADIUS end to end shows where the transport sits in a full conversation.
Also known as: radius over tls, radius/tls, rfc 6614, tcp 2083