1.3 The Authorization Framework

Moving on in the soup of terminology, we come to the AAA Authorization Framework, an RFC document from the subset of the AAA Working Group set up by the IETF. Like an architecture document, a framework is designed as a roadmap, but it tends to be a bit more specific. Frameworks designate how systems interact with one another, but frameworks generally concentrate more on models specific to certain environments, such as an Internet wholesaler, a corporate VPN center, or other similar situations.

First, though, we should point out the distinctions in terminology. The authorization framework introduces the concept of a User Home Organization (UHO), which is an entity that has a direct contractual relationship with an end user. Also, the Service Provider (SP) is involved, which maintains and provisions the tangible network resources. The UHO and the SP need not be the same organization; a good example of this is, again, an ISP wholesaler or reseller that provides its own network resources to other organizations. For the purposes of this overview, I'll first look at scenarios in which the UHO and SP are one and the same, and then I'll cover a more detailed scenario that is commonly found.

1.3.1 Authorization Sequences

There are several different methods in which the end user, the AAA server, and the network equipment communicate during a transaction. Specifically, there are three different sequences in which each machine is contacted.

The agent sequence

In this sequence, the AAA server acts as a middleman of sorts between the service equipment and the end user. The end user initially contacts the AAA server, which authorizes the user's request and sends a message to the service equipment notifying it to set that service up. The service equipment does so, notifies the AAA machine, and the notification is passed on to the end user, who then begins using the network. This sequence is typically used in broadband applications in which quality of service (QoS) is part of an existing contract.

The pull sequence

Dial-in users frequently encounter this sequence. The end user in this situation connects directly to the service equipment (terminal gear or other NAS machinery), which then checks with an AAA server to determine whether to grant the request. The AAA server notifies the service equipment of its decision, and the service equipment then either connects or disconnects the user to the network.

The push sequence

The push sequence alters the trust relationship between all of the machines in a transaction. The user connects to the AAA server first, and when the request to the server is authorized, the AAA server distributes some sort of authentication "receipt" (a digital certificate or signed token, perhaps) back to the end user. The end user then pushes this token along with his request to the service equipment, and the equipment treats the ticket from the AAA server as a green light to provision the service. The main distinction is that the user acts as the agent between the AAA server and the service equipment.

Here are some diagrams of the sequences that visually indicate the authorization transaction sequence.

Figure 1-3 shows the agent sequence, in which an AAA server acts as the middleman between the client and the service equipment responsible for provisioning the client's request.

Figure 1-3. The agent sequence

Figure 1-4 shows the pull sequence, in which the user contacts the service equipment directly. The equipment then "pulls" an authorization from the AAA server.

Figure 1-4. The pull sequence

Figure 1-5 shows the push sequence, in which the client system gets an authorization from the AAA server and then pushes it to the service equipment.

Figure 1-5. The push sequence

1.3.2 Roaming

To add an interesting twist to the progression, let's talk about roaming. The examples I've presented thus far assume that the service equipment and AAA server are all under the direct control and ownership of a single entity, the user's home organization (UHO). But what happens when the service equipment is owned and operated by another organization? This model is called roaming, and the Roaming Operations Working Group (Roamops) has been formed to explore this situation. Roaming is actually quite common: revisiting an earlier example, a user connecting to a set of dial-up ports that his ISP is renting from a larger service provider is roaming, since the service equipment is in another provider's domain.

The same combinations of authorization sequences—agent, push, and pull—are possible with roaming. Figure 1-6 through Figure 1-8 depict typical roaming authorization sequences.

Figure 1-6. The roaming agent sequence

Figure 1-7. The roaming pull sequence

Figure 1-8. The roaming push sequence

1.3.3 Distributed Services

Now consider a situation in which a service provider contracts with numerous wholesalers to provide services to its user base. For example, a provider could guarantee a certain amount of bandwidth across the country for a particular company. The frontline ISP with which the company, as a client, contracts needs to set a QoS policy on equipment across the country to maintain its contractual duty to the customer. The customer, in this situation, is using a distributed service. Figure 1-9 illustrates this.

Figure 1-9. A model of distributed services

In Figure 1-9, we make the assumption that the user first contacts his UHO and gains authorization from its servers, which then provision his service from the other organizations involved in his contract. But this is not necessarily the case. The contacts between the equipment at the first and second organizations can use any of the three authorization sequences we described earlier. For instance, the user can contact the service equipment in the first hop, using the pull authorization sequence. Following that, the ISP's equipment will use a push sequence: it will contact the AAA server at the second organization, obtain authorization, and push the service equipment. This process can be carried out as many times as necessary to fulfill the frontline ISP's contractual obligations. Figure 1-10 demonstrates this type of distributed service that involves three different service-provider organizations.

Figure 1-10. Using the push and pull authorization sequences to provide a user with distributed services

These models open up possibilities for new features in protocols based around the AAA design. First, examine the possibility of an organization using a type of "credit" for another system. For example, the length and traffic of a certain route from Philadelphia to San Francisco could result in delays for AAA traffic being sent from the east coast ISP to the west coast ISP. The Philadelphia ISP equipment, knowing about the delays, could proceed and grant authorization ahead of time to the San Francisco equipment without having express authorization from the west coast provider. However, there needs to be a provision in whatever AAA-based protocol is used to revoke that authorization should either the west coast equipment deny the request once it receives it, or the delays be so long that the response from the San Francisco equipment is lost.

As well, distributed services in concert with roaming can create entirely new business and IT infrastructure models. For example, an organization could exist solely to provide authentication and authorization functions to a variety of diverse networks. Such an "AAA broker" would be able to provide AAA services to ISP wholesalers, individual service providers, and corporations outsourcing their own dial-up pools. The various RFCs that make up the AAA design allow for such an organization to exist based on the capabilities they specify.

1.3.4 Policies

Policies, in short, are what an AAA server analyzes and uses to determine whether a request is valid and should be granted. Any server that meets the generic AAA requirements must have some way of storing and retrieving policy information. These policies are stored in a policy repository, which can be virtually anything that stores information: a database, a flat text file, or some other storage mechanism. The one key point about the policy repository in general is that it requires a unique namespace—the name of the server, to be simple—so that remote devices can query and make requests for that AAA server's resources.

The AAA framework provides for a policy set that spans across multiple domains and entities. It lists three specific tasks for an AAA server in terms of using policies: they must be retrieved, evaluated, and enforced. How this is done can vary greatly depending on the environment. It can even involve directory queries via an open-directory protocol, such as LDAP.

A great deal of work goes into policy evaluation. A simple dial-up user doesn't require much analysis on the part of the AAA server: it examines a rather simple policy, perhaps one that states whether the user is allowed to log on and then appropriately answers the request. However, authorization might also involve the provisioning of distributed services, and current status information could be vital in servicing the request. The AAA server might not have that information at hand, so it has to have a way to contact the appropriate resources, gather the information it needs, and then analyze that information against its policy.

Policies can also be distributed. In the previous example, let's say a user requires a 512 KB connection with no greater than three hops to a destination. The AAA server gathers the relevant information and authorizes the request, since it knows from its requests to the service equipment at each hop that traffic is light and there are ports and bandwidth available for the connection. The AAA server, having authorized the request, can then distribute a policy to the routers at each hop, ensuring the contractual QoS threshold. It can also set limits, via IP address restrictions, on where requests made over the connection can go.

Policy Framework Points Some more terminology is required to understand how systems interact to use policies. RFC policies are retrieved using a policy retrieval point (PRP) from a policy repository. They are then evaluated at a policy decision point (PDP) and enforced at a policy enforcement point (PEP), or the target. The requests of other devices for information (like in the previous example) are made of policy information points (PIPs) and are queried and retrieved using policy information blocks (PIBs). In general, AAA servers can be PRPs and PDPs, and various pieces of service equipment serve as PEPs. Policy repositories are present anywhere on the network, including various AAA servers or in dedicated database servers. In network designs involving distributed services, multiple service providers may have their own AAA equipment with their own policy repositories that can be queried using PIPs and PIBs. The RFC requires that the " . . . AAA protocol . . . be able to transport both policy definitions and the information needed to evaluate policies. It must also support queries for policy information."

1.3.5 Resource and Session Management

The final components of the authorization framework (at least the final in terms of the scope of this book) are the specifications for resource and session management. The problem with covering this is that, so far, the RFC waxes theoretical much more than it offers concrete dimensions and mechanisms. But let's first look into what resource and session management are and how they can benefit a protocol that is based on the AAA model.

Resource management is basically the ability to monitor resources that have been previously allocated. A program or utility called the "resource manager" would be able to receive and display information on a resource in real time. Such a program could, for example, monitor a pool of dial-up ports on a terminal server and report information to the monitor program.

This is perhaps the simpler mechanism of the two to implement into a protocol, but there are inherent problems. With fewer AAA servers, there isn't much traffic involved in real-time monitoring, and the equipment is more likely to be confined to one entity's realm. Once the AAA server group expands and, particularly, begins to span multiple domains, it becomes increasingly problematic to maintain the identity of specific servers. Uniqueness of sessions is critical, and in addition, some method of combining session and resource information with a unique identifier is needed. As has been well documented in a variety of applications, network synchronization has its own problems as well, such as resource contentions and deadlocks.

Session management is the capability of a protocol or piece of equipment to notify an AAA server of a change in conditions, and more ideally, to modify an existing session. That session could be changed, put on hold, or terminated based on changing conditions recorded by the resource manager. Consider a connection based on a contract that offers a specific QoS threshold (2 MB, for example) during working hours and another based on traffic load during non-working hours. A session manager would use the information from the resource manager (which in this case would monitor the session time and traffic load) and dynamically alter the parameters of the session when the traffic load became heavier and the clock struck 5 P.M. It would then send a note back to the AAA servers at the UHO, allowing them to record accounting information that could help with later billing requirements.

The combination of resource and session management allows complicated policies to be implemented and provisioned with ease, even across a distributed policy platform. The agility to change based on varied conditions is the focus of more research and development on the part of the AAA Working Group. They face numerous problems in designing a model to incorporate these desires. For one, it's been difficult up to now to synchronize a session database with the real state of a session. Connection delays and packet losses all come into contention when real-time monitoring is used. Although there are commercial database products that claim to have solved this "inter-domain database replication problem," there is yet to be an official specification of this inside an RFC.

The significance of monitoring data and traffic can easily be seen when you consider the oft-referenced ISP wholesaler. He often makes agreements with providers to offer a certain number of ports for a certain length of time, say 1,000 ports in any of 10 locations from 7 A.M. to 9 P.M., and 650 ports in any of these locations from 9:01 P.M. to 6:59 A.M. With possibly 1,000 requests coming in at the same time (the dreaded "overload" factor capacity planners try to stifle) from 10 different locations, it would be crucial in the financial interests of both companies to ensure that only 1,000 ports (or 650 ports) were used. If monitoring was not used, it would be impossible for the wholesaler to determine that only 1,000 ports were used: that is to say, the ISP could exceed his allotment and the wholesaler would not be aware of it. This is especially bad if the wholesaler's modem:user ratio were particularly low, even 1:1, since any overage would result in a legitimate user from another organization being denied access.

As I mentioned earlier, the details and complications of resource and session management are far beyond what I intend to cover in this book. However, you should be aware of how the authorization framework and session management can be implemented and what the limitations are.