RADIUS Reinvigorated
When the RADIUS protocol was first introduced in 1991, it was intended to perform a very specific, narrowly delineated task, which was namely to provide distributed dial-in access devices with a lightweight protocol for verifying user logins against a centralized authentication server. Since then, RADIUS has been extended to accommodate each of the new network access technologies that have emerged for modern networking. Nowadays it's commonly used to provide authenticated access for VPNs, Ethernet switches, and wireless access points. Meanwhile, a variety of Application-layer services are also making use of RADIUS for centralized authentication, and ongoing enhancements to the core RADIUS protocol promise to make it usable for an even broader range of services.
For those of us who watch the space, this trend should come as no surprise. Protocols usually evolve over time to suit the needs of new technologies, and the continuing enhancement of RADIUS seems to fit the historical model nicely. What is surprising, however, is that things weren't supposed to be this way. Instead, most of the new development activity was supposed to have focused on the Diameter protocol, which was specifically intended to replace RADIUS.
Whereas RADIUS was originally created for dial-up authentication (hence the name Remote Authentication Dial-In User Service), Diameter was designed to provide robust access control services that overcome many of the shortcomings inherent in the original RADIUS design (its name also makes the point—Diameter is "RADIUS times two"). For example, RADIUS only supports the unreliable UDP transport protocol, while Diameter supports the reliable and stateful TCP and Stream Control Transmission Protocol (SCTP) transports, making it eminently more suitable to a wider array of applications. Similarly, RADIUS attributes use eight-bit identifier values (and over half of the 256 possible values are already assigned), while Diameter uses 32-bit code values and is therefore capable of supporting four billion individual attributes. There are many such differences, with Diameter having the technical advantage in almost all cases.
However, several forces have worked to RADIUS's advantage over the past years. For one thing, the first RADIUS RFC was published in 1997, while the specification for Diameter wasn't published by the IETF until August of this year. As a result, RADIUS is well-understood and implementations are widely available, whereas Diameter is relatively new and has far fewer field-tested implementations. For example, you can find free RADIUS servers bundled into the common Windows and Linux server platforms (using Microsoft's Internet Authentication Service in the former, and the FreeRADIUS project's server in the latter), or you can pursue specialty commercial software packages from vendors such as Funk Software (soon to be part of Juniper Networks) and Interlink Networks. There are even hardware-based RADIUS appliances such as ZyXEL Communications' Vantage Radius 50 and Infoblox's RADIUSone. Simply put, RADIUS implementations are widely available and widely supported, but the same can't be said for Diameter.
Furthermore, RADIUS technology didn't stagnate while Diameter was under development. Although RADIUS was originally intended for dial-up access gear, today it's capable of supporting a variety of connection types and is no longer limited to human identities. For the most part, this evolution has mirrored the evolution of Internet access technologies: As people moved from modems to full-time connections and managed access services, they dragged RADIUS along for the ride. According to Alan DeKok, director of RADIUS architecture for Infoblox and co-developer of the FreeRADIUS project, "RADIUS used to provide about 90 percent of the functionality in Diameter, but with all of the current and planned enhancements it will get close to 99 percent and there will only be a few corner cases where Diameter will still be needed."
As a result of these kinds of market and development forces, RADIUS has found new life as a general-purpose distributed authentication protocol for network connections of all types. However, Diameter's many technical improvements over RADIUS will likely translate into a technological and market advantage sometime down the line, and architects should keep their eye on it. But for the next few years, most organizations will likely treat RADIUS as the default choice, and for good reason.
Improved Topology Support
In some cases RADIUS has passively benefited from changes to the topology, while in others it has played a central role in advancing the overall technology. An obvious example of the former can be seen with broadband Internet connections that rely on PPP for carrier service, such as PPP over Ethernet, which is commonly used with DSL circuits. Because RADIUS is already used with PPP links over dial-up lines, RADIUS servers can continue providing the same basic functionality with PPP on DSL with only minor changes (namely in the form of additional calling-station identifier syntaxes). Another example of this phenomenon at work is the iSCSI specification, which dictates the use of the Challenge-Handshake Authentication Protocol (CHAP) for access control purposes. Because RADIUS has long supported CHAP, it's a natural technological fit for many iSCSI servers. For this reason, RADIUS is widely supported in that community, with no substantial effort being required of the RADIUS protocol or systems.
On the other hand, the widespread use of VPNs and per-user tunneling has required significant new development in order for RADIUS to provide the expected authorization and access control functionality needed for remote VPN admittance systems. Moreover, sometimes the access device needs to create a tunnel on behalf of the user (such as when dial-up is used to connect to a third-party provider that's contractually obligated to tunnel the user's traffic back to the corporate network), which requires an additional set of link-specific RADIUS attributes. Most of these extensions and attributes are defined in RFC 2868 (circa 2000), which has been widely supported in a variety of RADIUS servers and access devices for several years.
Another highly visible example of this is IEEE 802.1X, which defines port-level control mechanisms for managed-access 802 networks such as switched Ethernet and encrypted wireless links. Essentially, 802.1X devices block all traffic except for special L2 frames that carry user authentication requests inside Extensible Authentication Protocol (EAP) messages. When an access request is received, it's forwarded to an authentication server, which is usually a RADIUS server (this isn't mandated by the 802.1X specifications, but it's by far the most common configuration). The RADIUS server then returns an accept or reject response to the access device.
More RADIUS attributes and values were defined in RFC 3580 (circa 2003). Most of the VLAN-specific attributes are already widely supported by a variety of vendors and collectively provide the foundation for the current crop of network access control systems. Other attributes are being defined in draft-ietf-radext-ieee802, which promises to provide even greater control for dynamic per-user network connections.
Even the "free" parts of 802.1X have required some development work on the part of the RADIUS community. Technically, EAP is just a framework that allows for a multitude of authentication protocols to be defined as individual plug-ins. Because the network client and the RADIUS server are the actual EAP endpoints (the 802.1X access device merely acts as a translation proxy between the L2 frames and the RADIUS protocol), RADIUS servers that wanted to play in the 802.1X space had to incorporate several EAP plug-ins that weren't commonly found with dial-up PPP.
This is even more true with the 802.11i specification, which defines Wi-Fi Protected Access (WPA) encryption with dynamic rekeying for 802.11 wireless networks. In that model, the encryption keys are ultimately derived from special EAP interfaces to the canonical EAP plug-ins (such as using the key generation function in EAP-Transport Layer Security). This in turn means RADIUS servers have to support the needed EAP features—as well as the correct plug-ins—in order for the encryption system to work properly. These mechanisms are defined in the 802.1X-2004 and 802.11i specifications respectively, but are already widely supported by RADIUS vendors that implement the relevant EAP plug-ins.
Ongoing Enhancements
Apart from the network-level access mechanisms, there are also some enhancements being made to the core RADIUS protocol that promise to improve its overall functionality and expand its general utility. Most of this work is taking place under the auspices of the IETF's official RADIUS Extensions Working Group, although there are also some independent efforts under way.
One effort currently under development is described in draft-ietf-radext-rfc2486bis, which attempts to standardize the Network Access Identifier attribute value. This attribute identifies the canonical user and the user's home network and is especially common with roaming users, who may connect to a network through a variety of different paths (such as dial-up or VPN). Standardized syntax is important in general, but is especially so in international networks where multiple languages and character sets may be common.
Meanwhile, draft-ietf-radext-chargeable-user-id defines a Chargeable User Identity attribute, which provides transparency to encrypted logins. Some EAP plug-ins use anonymous usernames in the clear-text portion of RADIUS messages and rely on encryption in the EAP portion of the message to negotiate actual user identity. This provides privacy and security for RADIUS messages transmitted across the public Internet, but it also prevents the access device from seeing the actual username, which creates problems for billing systems. The use of a specific "chargeable" attribute resolves this problem.
A third draft, draft-ietf-radext-digest-auth, proposes an extension to define mechanisms for generating HTTP Digest messages, which are needed to authenticate SIP credentials such as those used in VoIP systems. At present, RADIUS is widely used for call accounting and billing systems (although these currently depend on vendor-specific attributes), but not for user or device authentication due to the lack of a bridge between SIP and RADIUS authentication methods. Later versions of this draft appear to resolve some of the flaws in earlier proposals and seem to be on track for adoption by the IETF. If things work out, this will provide a secure and standardized method of authentication for SIP endpoints within RADIUS, without requiring significant development of SIP.
Copyright © 2010-2017 Eric A. Hall.
Portions copyright © 2006 CMP Media, Used with permission.