1.4 And Now, RADIUS

There's been much talk of AAA and so little of RADIUS. This is largely because RADIUS will not be eternally the access control protocol of choice. In fact, RADIUS was created by a separate working group long before the AAA design and fundamentals were brought to existence. The similarities are, however, remarkable.

AAA is the foundation of the next generation remote access protocol. Developments in creating the next protocol are being made as I write this, so the days of RADIUS being the standard aren't infinite. But on the same token, RADIUS has an established and well-respected presence in the industry, so it has a definite future.

1.4.1 A Brief History

RADIUS, like most innovative products, was built from a need. In this case, the need was to have a method of authenticating, authorizing, and accounting for users needing access to heterogeneous computing resources. Merit Networks, a big player in creating the Internet as we know it, operated a pool of dial-up resources across California. At the time, authentication methods were peculiar to specific pieces of equipment, which added a lot of overhead and didn't allow for much in the way of management flexibility and reporting. As the dial-up user group grew, the corporation realized they needed a mechanism more flexible and extensible than remaining with their proprietary, unwieldy equipment and scripts. Merit sent out a request for proposal, and Livingston Enterprises was one of the first respondents. Representatives for Merit and Livingston contacted each other, and after meeting at a conference, a very early version of RADIUS was written. More software was constructed to operate between the service equipment Livingston manufactured and the RADIUS server at Merit, which was operating with Unix. The developer of RADIUS, Steve Willins, still remains on the RFC document. From that point on, Livingston Enterprises became Lucent, and Merit and Lucent took the RADIUS protocol through the steps to formalization and industry acceptance. Both companies now offer a RADIUS server to the public at no charge.

1.4.2 Properties of RADIUS

The RFC specifications for the RADIUS protocol dictate that RADIUS:

• Is a UDP-based connectionless protocol that doesn't use direct connections

• Uses a hop-by-hop security model

• Is stateless (more to come on that later)

• Supports PAP and CHAP authentication via PPP

• Uses MD5 for password-hiding algorithms

• Provides over 50 attribute/value pairs with the ability to create vendor-specific pairs

• Supports the authentication-authorization-accounting model

In addition, RADIUS enjoys support by virtually every commercially available NAS product, ensuring its future well into the next 10 years.

1.4.3 Limitations of RADIUS

RADIUS, while having many positive attributes to its name, does have limitations. Doesn't everything, after all?

First, security is an obstacle in some implementations. Despite the irony, if an implementation in which there are several proxy RADIUS servers is used, all hops must view, perform logic on, and pass on all data in the request, hidden or not. This means that all data is available at every hop, which is not the most secure environment in which to place such sensitive data as certificates and passwords.

Second, RADIUS, at least in its most general incarnation, has no support for recalling and deallocating resources after an authorization has been issued. For instance, as mentioned earlier, it's possible to have a multi-hop proxy RADIUS chain in which the first server grants the request and subsequently contacts the necessary equipment to provision the services. If for some reason the service is not available (possibly because of a time-of-day restriction or an account suspension that the frontline RADIUS server isn't aware of), there is no provision in the RFC specification to deny and disconnect the service now that a rejection has been made. Some vendors have developed support for subsequent rejections—including knocking a user off at his specific time limit rather than just denying him access the next time he attempts to connect—but there's not a provision for this in the official specification.

Third, RADIUS is stateless (you heard about this earlier). That is to say, it does not keep track of configuration settings, transaction information, or any other data for the next session. When a program "does not maintain state" (is stateless) or when the infrastructure of a system prevents a program from maintaining state, it cannot take information about the last session into the next, such as settings the user made or conditions that arose during processing. In terms of using RADIUS, this complicates resource and session management solutions like I described previously.

And finally, users of RADIUS have noted that RADIUS has scalability problems. On the first page of the RFC is a note from the IESG: "Experience has shown that [RADIUS] can suffer degraded performance and lost data when used in large scale systems, in part because it does not include provisions for congestion control. Readers of this document may find it beneficial to track the progress of the IETF's AAA Working Group, which may develop a successor protocol that better addresses the scaling and congestion control issues."

If you were reading closely, you'd see that even the RADIUS RFC, itself, notes the fact that it's a limited protocol. Unfortunately, adding the complications of just some of the limitations I presented here can cause problems on a large-scale enterprise level. RADIUS is not always going to be the key authenticator protocol, but its basis on the AAA framework (and your familiarity with its underpinnings, because of this book) makes the transition from RADIUS to the next, more scalable protocol much easier.

So there's the overview of the key design aspects behind RADIUS. In the next chapter, I'll discuss RADIUS specifically and go through the RFC, explaining each part in detail.