In an ideal world, we wouldn’t have to use authentication of any type to gain access to anything. But as long as free enterprise exists and access to private resources is sold, authentication will exist.
You may have experienced authentication as recently as an hour ago, when you used a dial-up Internet account to log on and surf the Web for the latest headlines. You may have checked your corporate email on your PalmPilot to see if your biggest client had returned your message about the newest proposal. And this weekend, when you use a VPN to connect to your office network so you can revise that presentation that’s due early Monday morning, you’ll have to authenticate yourself.
But what goes on behind the scenes when you prove your identity to a computer? After all, the computer has to have a set of processes and protocols to verify that you are indeed who you say you are, find out what you are allowed to access, and finally, tell you all of this. There’s one protocol that does this all: the Remote Access Dialin User Service, or RADIUS.
RADIUS, originally developed by Livingston Enterprises, is an access-control protocol that verifies and authenticates users based on the commonly used challenge/response method. (I’ll talk more about challenge/response authentication later.) While RADIUS has a prominent place among Internet service providers, it also belongs in any environment where central authentication, regulated authorization, and detailed user accounting is needed or desired.
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.
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.
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.
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 are 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.
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.
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.