RADIUS

An Overview of AAA

The framework around which RADIUS is built is known as the AAA process, consisting of authentication, authorization, and accounting. While there’s nothing specific to RADIUS in the AAA model, a general background is needed to justify most of RADIUS’s behavior. RADIUS was created before the AAA model was developed, but it was the first real AAA-based protocol exhibiting the AAA functionality to earn industry acceptance and widespread use. However, that’s not to say there aren’t other protocols that satisfy the architecture’s requirements.

This model serves to manage and report all transactions from start to finish. The following questions serve well as a mimicking of the functionality by asking:

• Who are you?

• What services am I allowed to give you?

• What did you do with my services while you were using them?

To begin, let’s look at why the AAA architecture is a better overall strategy than others. Before AAA was introduced, individual equipment had to be used to authenticate users. Without a formal standard, each machine likely had a different method of authentication—some might have used profiles, while others might have used Challenge/Handshake Authentication Protocol (CHAP) authentication, and still others might have queried a small internal database with SQL. The major problem with this helter-skelter model is one of scalability: while keeping track of users on one piece of network equipment might not be a huge manageability obstacle, increasing capacity by adding other equipment (each with its own authentication methods) quickly ballooned the process into a nightmare. Kludgy scripts were written to halfway automate the process, but there was no real way to monitor usage, automatically authenticate users, and seamlessly provide a variety of services.

The AAA Working Group was formed by the IETF to create a functional architecture that would address the limitations of the system described above. Obviously, there was a need to focus on decentralizing equipment and monitoring usage in heterogeneous networks. ISPs began offering services other than just standard dial-up, including ISDN, xDSL, and cable-modem connectivity, and there needed to be a standard way in which users could be verified, logged on, and monitored throughout the network. After much work, the AAA architecture was born.

A Word About Terminology

When discussing AAA and RADIUS, the terms “client” and “server” often come up. However, there can be some confusion about which of these roles a particular machine is playing in a specific transaction. Let’s take a look at each of these roles.

A client, in the traditional sense, is a machine that makes requests of and uses resources on another machine. In the AAA framework, and with RADIUS specifically, the client can be the end user who wants to connect to a network’s resources—in other words, a service consumer. However, in another context, an AAA client can be the machine that sends AAA-style packets to and from an AAA server. This is the strictest sense of the “client” term.

A server is commonly known as the machine of which clients request resources. In AAA, this can be the network server—a NAS machine or some other concentrator—or an AAA server that authenticates, authorizes, and performs accounting functions. How the word “server” is meant really depends on the context of the architecture on which the discussion is based.

In this book, I will use the contextually based meanings of these terms interchangeably, as there is no clear-cut and non-kludgy method to provide any additional degree of consistency. I have tried to specifically identify clients and servers as AAA or RADIUS clients and servers where possible.

The AAA model focuses on the three crucial aspects of user access control: authentication, authorization, and accounting, respectively. I will now take a closer look at each of these steps.