1.1 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.

1.1.1 Authentication

Authentication is the process of verifying a person's (or machine's) declared identity. You're familiar with the most common form of authentication, using a combination of logon ID and a password, in which the knowledge of the password is a representation that the user is authentic. Distributing the password, however, destroys this method of authenticating, which prompted creators of e-commerce sites and other Internet-business transactors to require a stronger, more reliable authenticator. Digital certificates is one of the solutions here, and over the next five to ten years it's likely that using digital certificates as a part of the public key infrastructure (PKI) will become the preferred authenticator on the Internet.

The key aspect of authentication is that it allows two unique objects to form a trust relationship—both are assumed to be valid users. Trust between systems allows for such key functionality as proxy servers, in which a system grants a request on behalf of another system and allows AAA implementations to span heterogeneous networks supporting different types of clients and services. Trust relationships can become quite complex, and I'll talk more about them in a later section.

1.1.2 Authorization

Authorization involves using a set of rules or other templates to decide what an authenticated user can do on a system. For example, in the case of an Internet service provider, it may decide whether a static IP address is given as opposed to a DHCP-assigned address. The system administrator defines these rules.

So-called "smart implementations" of AAA servers have logic that will analyze a request and grant whatever access it can, whether or not the entire request is valid. For instance, a dial-up client connects and requests multilink bonding. A generic AAA server will simply deny the entire request, but a smarter implementation will look at the request, determine that the client is only allowed one dial-up connection, and grant the one channel while refusing the other.

1.1.3 Accounting

Rounding out the AAA framework is accounting, which measures and documents the resources a user takes advantage of during access. This can include the amount of system time or the amount of data a user has sent and/or received during a session. Accounting is carried out by the logging of session statistics and usage information and is used for authorization control, billing, trend analysis, resource utilization, and capacity-planning activities.

Accounting data has several uses. An administrator can analyze successful requests to determine capacity and predict future system load. A business owner can track time spent on certain services and bill accordingly. A security analyzer can look at denied requests, see if a pattern emerges, and possibly ward off a hacker or freeloader. The moral here is that the accounting data is of great utility to an AAA server administrator. I'll cover many uses of accounting data and strategies for getting the most out of the logs in Chapter 4 and Chapter 7.