RADIUS

Key Points About AAA Architecture

The AAA architecture, simply put, is an attempt to map out a design of how the AAA pieces fit together. AAA implementations can be as simple or as complex as they need to be, mainly because of the efforts of the Internet Research Task Force (IRTF) AAA Architecture Working Group to make a model as application-neutral as possible. In other words, the AAA model is designed to work in environments with varied user requirements and equally varied network design. There are some key attributes of the model that make this possible.

First, the AAA model depends on the client/server interaction, in which a client system requests the services or resources of a server system. In simple implementations, these roles generally stick—the server never acts as the client and vice versa. Client/server environments allow for a good load-balancing design, in which high availability and response time are critical. Servers can be distributed and decentralized among the network. Contrast this with the opposite network model, a peer-to-peer (P2P) network. With P2P networks, all systems display characteristics of both client and server systems, which can introduce such demons as processing delays and unavailability.

A proxying capability is a slight variation of this. An AAA server can be configured to authorize a request or pass it along to another AAA server, which will then make the appropriate provisions or pass it along again. In essence, a proxy chain is created, in which AAA servers make requests of both clients and other AAA servers. I said “slight variation” earlier because when a server proxies another server, the originator displays the characteristics of a client. Thus, a trust relationship has to be created for each client/server hop until the request reaches equipment that provisions the needed resources.

Proxying is a very useful feature of the AAA model and a boon to enterprise and distributed network implementations, in which some AAA equipment can be configured to always proxy requests to machines in other locations. An example of proxying at its best is with an ISP reseller agreement. Often a major networking company will make a significant investment in network infrastructure and place points of presence in multiple locations. Armed with this distributed network, the company then resells to smaller ISPs that wish to expand their coverage and take advantage of a better network. The reseller has to provide some form of access control over the tangible resources in each location, but the smaller ISP doesn’t wish to share personal information about its users with the reseller. In this case, a proxying AAA machine is placed at each of the reseller’s points of presence, and those machines then communicate with the appropriate NAS equipment at the smaller ISP.

Clients requesting services and resources from an AAA server (and in this case, clients can include AAA proxies) can communicate with each other by using either a hop-to-hop or an end-to-end transaction. The distinction is where the trust relationship lies in the transaction chain. Consider the following circumstances to get a better picture.

In a hop-to-hop transaction, a client makes an initial request to an AAA device. At this point, there is a trust relationship between the client and the frontline AAA server. That machine determines that the request needs to be forwarded to another server in a different location, so it acts as a proxy and contacts another AAA server. Now the trust relationship is with the two AAA servers, with the frontline machine acting as the client and the second AAA machine acting as the server. It’s important to note that the trust relationship is not inherently transitive, meaning that the initial client and the second AAA machine do not have a trust relationship. Figure 1-1 shows how the trusts are sequential and independent of each other.

Figure 1-1. Independent trust relationships in a hop-to-hop transaction

Differing from the hop-to-hop model is the end-to-end transaction method. The key difference is, again, where the trust relationship lies—in this model, it’s between the initial, requesting client and the AAA server that finally authorizes the request. In an end-to-end model, the proxy chain is still very much functional as the model doesn’t necessarily mean the transaction is end-to-end: it’s the trust relationship that is. Because it is poor design to pass sensitive information in proxy requests, some other mean of authenticating a request and validating data integrity is needed when the initial request jumps through the hops in the proxy chain. Most commonly, digital certificates and other PKI certifications are used in these situations. RFCs 2903 and 2905 describe the requirements of implementing end-to-end security, which is shown in Figure 1-2.

Figure 1-2. Client/server trust relationship in the end-to-end model