Accounts

Protocols, Applications, and the Future of AAA

by Sean Convery, Identity Engines

Network Authentication, Authorization, and Accounting has been used since before the days of the Internet as we know it today. Authentication asks the question, "Who or what are you?" Authorization asks, "What are you allowed to do?" And finally, accounting wants to know, "What did you do?" These fundamental security building blocks are being used in expanded ways today. The first part of this two-part series focused on the overall concepts of AAA, the elements involved in AAA communications, and high-level approaches to achieving specific AAA goals. It was published in IPJ Volume 10, No. 1 [0]. This second part of the series discusses the protocols involved, specific applications of AAA, and considerations for the future of AAA.

AAA Protocols

Although AAA is often thought of as the exclusive province of the Remote Authentication Dial-In User Service (RADIUS) protocol, in reality a range of protocols is involved at various stages of the AAA conversation. This section introduces these AAA protocols, organized according to the parties involved in the communication. We divide AAA communications into the following categories: Client to Policy Enforcement Point (PEP), PEP to Policy Decision Point (PDP), Client to PDP, and PDP to Policy Information Point (PIP). For easy reference, the AAA flow diagram from Part One of this article is reproduced here. Please refer to Part One [0] for the explanatory text associated with the diagram.

Client to PEP

AAA communications between the client and the PEP can travel at Layer 2 of the OSI model, or they can run at higher layers, relying on lower layers as essentially dumb transport. The most common protocols for client-to-PEP communication are the Point-to-Point Protocol (PPP) [1], PPP over Ethernet (PPPoE) [2], IEEE 802.1X [3], IP Security (IPsec), Secure Sockets Layer (SSL) VPN, and Hypertext Transfer Protocol (HTTP), each of which is discussed in this article.

PPP, the standard protocol for communicating across point-to-point links, includes an optional authentication step—the point at which the AAA element is introduced. During this authentication phase, protocols such as the Challenge Handshake Authentication Protocol (CHAP) can be used to identify the client to the PEP. (These protocols were discussed in the credential section of Part One of this article.) PPP is extensively used in dialup access but is otherwise not found in modern AAA. PPPoE, an adaptation of PPP to run over Ethernet, is used by many service providers rolling out broadband services.

PPPoE allows the broadband endpoint to authenticate itself to the service provider's network when making the initial connection. Because many broadband networks use shared Ethernet mediums, PPPoE allows Internet Service Providers (ISPs) to maintain the per-user accounting they were familiar with from dialup. The 802.1X protocol is an IEEE standard specifying a way to provide network access control at the port level for wired and wireless networks. The 802.1X standard specifies a way for the client to communicate with the PDP using the Extensible Authentication Protocol (EAP) [4], which is discussed in more detail later in this section. The 802.1X standard requires that the endpoint support 802.1X through a "supplicant" or client sign-on application. This application authenticates the client to the network through the PEP. (See the EAP section later in this article for an explanation showing how EAP and 802.1X can work together.)

For wireless networks, 802.1X has become the standard way of authenticating clients because it supports communicating unique key material to the client to secure its use of the wireless infrastructure. In wired Ethernet networks, 802.1X is rising in popularity as a way to authenticate clients as well. These applications are more fully described in the "AAA Applications" section, later in this article.

At a more generic level, the IPsec protocol has established a standard for securing IP communications, and this approach has become another common method of communicating from a client to a PEP (referred to as a VPN Gateway from an IPsec perspective). The initial authentication for IPsec communications uses the Internet Key Exchange (IKE) protocol. Version 1 [5] of the IKE protocol had no built-in method for authenticating users with credentials such as passwords, so an extension to IKE called XAUTH [6] was proposed.

XAUTH never became an official standard (though it certainly was a de facto one) because the IETF IPsec working group created a second version of IKE [7] that used EAP as a transport for credentials such as passwords. Finally, in the areas of HTTP and VPN communications, the SSL and Transport Layer Security (TLS) [28] standards are two closely related protocols for securing, among other things, Web communications. SSL/TLS VPNs use these protocols to create a secure session from the client to the PEP (VPN gateway). Client authentication with SSL and TLS can be done with client-side certificates, but more commonly they use passwords or One-Time Passwords (OTPs).

PEP to PDP

The three main protocols for communicating between a PEP and a PDP are TACACS+ [9], RADIUS, and Diameter [10]. First, consider TACACS+: Developed by Cisco, TACACS+ is a proprietary protocol that is used primarily in communicating administrator authorizations for network devices. TACACS+ uses TCP port 49 and features payload encryption for the entire TACACS+ message. Though developed by Cisco, TACACS+ is supported by other companies as well, including Juniper.

Although TACACS+ excels at command-level authorizations and accounting for administrator control, another protocol has become far more common for client AAA: RADIUS. Thanks to nearly ubiquitous support for this protocol in network hardware, RADIUS is the primary protocol for communication between a PEP and a PDP in most environments. RADIUS uses the User Datagram Protocol (UDP) port 1812 for authentication and authorization and UDP port 1813 for accounting [8] (early deployments used ports 1645 and 1646, which are still used sometimes today). RADIUS supports numerous different attributes for communicating information back and forth from the PEP to the PDP, such as client MAC address, username, filter information for enforcement, and so on. It also supports an extensible framework for Vendor-Specific Attributes (VSAs), which allow extensions of the functions of RADIUS to support whatever elements a given PEP might need to best serve its role on the network. For example, a PEP manufacturer might support VSAs that allow the assignment of a user to a particular enforcement profile. RADIUS in its default implementation encrypts only the Password field of RADIUS messages, making the RADIUS protocol more prone to leaking information that could be used by an adversary. Both RADIUS and TACACS+ are secured by only a shared secret that is configured on both the PEP and the PDP.

Finally, consider the Diameter protocol. Diameter (the name is a play on words from RADIUS) is the next-generation, de jure standard for AAA. It supports stronger security through either IPsec or TLS and greater extensibility than RADIUS. It uses port 3868 for either TCP or the Stream Control Transmission Protocol (SCTP) [11]. The strongest use of Diameter to date is in the carrier space, where it provides AAA for call processing and third-generation (3G) mobile networks.

However, the corporate market has been fairly reluctant to embrace Diameter, and that reluctance has translated into a lack of support for Diameter in corporate network infrastructure equipment.

At this point in the discussion, it makes sense to compare RADIUS and Diameter. Although Diameter is an obvious alternative, RADIUS continues to be used in both new and existing deployments, so the IETF has a working group specifically formed to extend RADIUS in the future. The relationship between RADIUS and Diameter is a little like the relationship between IPv4 and IPv6. IPv6 had IPsec as a standard feature, IPv4 integrated IPsec as well, and today, by a large margin, most IPsec deployments are on IPv4 networks. The situation is similar with AAA. RADIUS certainly had limitations, but since Diameter entered the picture, RADIUS has been extended to address some of those shortcomings, particularly with both protocols using EAP as a transport. The result is that RADIUS today does what most people want. Therefore, given the significant added complexity of Diameter, many organizations have elected not to migrate to Diameter. Both RADIUS and Diameter will be around for many years to come.

Client to PDP

Although most of the protocols in this article handle communication from one component to the next component in the AAA chain (that is, client to PEP, PEP to PDP, etc.), there is one protocol that deals with communication from the client to the PDP directly: the Extensible Authentication Protocol (EAP). As mentioned earlier, EAP is a flexible mechanism for com­municating almost any kind of credential over almost any lower-layer transport. Each technique for authenticating a client is referred to as an EAP Method. Originally conceived as an extension to PPP, EAP can now use many transports, including IKEv2 and 802.1X. Cisco's proprietary Network Admission Control (NAC) solution offers a deployment option that puts EAP inside UDP. When using 802.1X, for example, EAP uses LAN transport, referred to as EAPoL (EAP over LAN). This transport is only for the connection between the client and the PEP though. From the PEP to the PDP, EAP rides inside RADIUS [12, 13]. The actual conversation, however, takes place between the client and the PDP, with the PEP acting as a relay.

The major benefit of this approach is that the PEP does not need to understand the specifics of the EAP method selected—only the client and the PDP do. The EAP specification in the IETF specifies several different EAP methods, including EAP Message Digest Algorithm 5 (EAP-MD5, very similar in security to CHAP), EAP-OTP (which supports an IETF-defined OTP solution [14]), and EAP Generic Token Card (EAP-GTC). Of the methods explicitly called out in the EAP standard, EAP-GTC is the only one in much use today in production networks. EAP-GTC allows the use of OTP token cards within an EAP context.

Beyond the methods defined in the EAP standard, EAP by its nature can be extended to support additional methods. EAP Subscriber Identity Module (EAP-SIM) [15] specifies a method for authentication using SIM elements in the Global System for Mobile Communications (GSM). EAP-SIM was developed by the Third Generation Partnership Project (3GPP) as a solution for these second-generation (GSM) mobile networks. EAP-AKA [16] is the 3GPP's EAP authentication technique for third-generation ( Universal Mobile Telecommunications Service [UMTS] or Code Division Multiple Access 2000 [CDMA2000]) mobile networks. Both EAP-SIM and EAP-AKA support authenticating a mobile phone to a Wi-Fi network without using passwords. The problem is that without some sort of user identity federation solution in place, SIM-based authentication can work only with the mobile provider's network that supplied the SIM card. EAP-TLS [17] specifies a technique for mutual certificate authentication. Although it is widely supported, EAP-TLS is not commonly deployed because of its requirement for client-side certificates.

Though none of the following EAP methods are standards, they—somewhat confusingly—represent the vast majority of EAP deployments. Each of them is referred to as a Tunneled EAP Method because it establishes one outer EAP method as a base secure channel and then runs another method (one that may be less secure) over that secure channel. Protected EAP (PEAP) [18], well supported in Microsoft's Windows operating system, has become a de facto standard for EAP methods. Most clients and PDPs support PEAP today. PEAP works by establishing a TLS session authenticated by the server certificate, and then an inner authentication method rides inside that TLS session. The inner method is almost always Microsoft CHAP Version 2 (MS-CHAPv2), but other methods can be used as well. Another popular tunneled protocol is EAP Tunneled TLS (EAP-TTLS) [19]. This protocol is similar to PEAP except it supports a more arbitrary exchange of information inside the TLS tunnel. For example, one of the primary uses for EAP-TTLS is using the Password Authentication Protocol (PAP) as the inner authentication method, allowing an EAP-TTLS-capable PDP to authenticate clients against older password stores (such as those that support only PAP authentication).

Finally, in settings that use primarily Cisco equipment, a common tunneled protocol is EAP Flexible Authentication via Secure Tunneling (EAP-FAST) [20]. This protocol uses TLS to authenticate the PDP, and then a shared key is distributed to allow faster subsequent authentication. An inner EAP method such as MS-CHAPv2 can then be used to authenticate the client to the server. EAP-FAST is used extensively in Cisco products for wireless deployments.

PDP to PIP

The final set of AAA protocols we consider are the ones that govern the communication between the PDP and the PIP. The primary protocol of interest is the Lightweight Directory Access Protocol (LDAP) [21]. From a AAA context, LDAP allows a PDP to query a PIP (typically an X.500 directory [22]) for information about a client. This information is exposed through a series of group and attribute identifiers, which can include information about a client's home location, organizational role, job title (if referring to a user), and so on. LDAP includes several different authentication options [23]. This client information learned from the PIP enables the PDP to better make its policy decision. Also useful in the PDP-PIP communications context is the RADIUS protocol. Some large organizations or inter-organization federations use a hierarchy of RADIUS-speaking PDPs where one RADIUS PDP can act as a PIP for another RADIUS PDP further down the AAA hierarchy.

Finally, Microsoft Active Directory (AD) uses the LDAP protocol when acting as a PDP but also has its own extension, called Netlogon, for validating Microsoft credentials such as MS-CHAPv2. This means that integrating a PDP with Microsoft AD generally involves using LDAP to find information about the client and using Netlogon to validate the client's credential. Other options for PDP-to-PIP interaction—though less often used—include Structured Query Language (SQL) databases, Network Information Service (NIS), and Kerberos.

AAA Applications

This section surveys the different applications of AAA technology throughout networking. It is divided into three sections covering consumer, enterprise, and carrier applications, with a final section covering emerging applications of AAA technology.

Consumer-Managed Applications

Most consumer network deployments do not perform any advanced AAA beyond a shared key for authentication to a wireless network. In this example, the client is the consumer's host and the wireless access point acts as PEP, PDP, and PIP by validating that any client connecting to the access point presents the correct shared key.

Enterprise-Managed Applications

AAA has numerous enterprise applications, including remote access, wireless security, Voice over IP (VoIP), guest access, Role-Based Access Control (RBAC), and endpoint posture validation (also known as NAC). This section discusses each of these applications. Remote-access security is the original enterprise AAA application. In the remote-access scenario, remote users connect over a dialup connection or a VPN and authenticate themselves (and optionally their hosts) to the organization's network.

The client's credential is almost always a password, expressed in one of the forms discussed in the credential section of Part One of this article. The main purpose of AAA in the remote-access case is to validate that the client is a valid user of the organization's network.

Wireless security is similar in some respects to remote-access security. The goals of AAA in wireless security are twofold: first it must validate that the wireless client is an authorized user, and second, it must provide the client with a session key for cryptographic protection of the client's traffic. Given these goals, 802.1X using EAP are the ideal protocols to use because they support both client authentication and dynamic keying. Older wireless security approaches relied on an open wireless network and a VPN gateway separating that network from the rest of the organization's network. In that example, the wireless-security approach mimics the remote-access application just discussed. Other types of networking require different applications of AAA. For example, VoIP deployments have authentication requirements as well. The Session Initiation Protocol (SIP) [24] is used extensively for, well, session initiation in VoIP networks (for example, authenticating the calling parties prior to initiating a new call). Authentication can be handled natively within SIP using HTTP digest authentication, or the same request can be sent to a PDP using RADIUS. AAA for VoIP allows handsets to authenticate themselves to the network and gain access to call-processing services.

Another, very popular application of AAA is guest-access management for networks. This application has grown quickly with the recent growth of wireless networks. Guest access is a method by which guests can be granted temporary access to a network with a full audit trail [27]. Guest access generally involves creating a distinct PIP, which houses short-term user accounts, and a technique for creating and, after a configurable period of time, automatically deactivating those user accounts. The PIP is often co-resident with the PDP and allows this temporary access without having to provision these users into the organization's more permanent directory. The guest can communicate with the PEP using any of the client-PEP protocols discussed earlier, though HTTP is the most common. The PEP is told by the PDP that the client (because it is a guest) should have restricted access—typically access only to the Internet at large and not any communication with an organization's internal network.

Also growing in popularity as a AAA application is RBAC, an application of AAA that allows customization of the network session based on the role of the client. In fact, guest access is a simple form of RBAC whereby two classes of clients are created: guest and permanent. However, RBAC can be extended to include more levels of delineation, including guest, contractor, and specific classes of permanent users such as sales, human resources, and engineering.

This classification can be done with all forms of AAA-enabled network infrastructure, including wired, wireless, and remote access. Current scalability limitations of VLAN technology and Access Control Lists (ACLs) make creating large quantities of roles difficult, but a significant business benefit in audit and regulatory compliance can be realized with usually fewer than five roles.

To implement RBAC, most organizations choose a mix of 802.1X and HTTP authentication for wired and wireless access, combined with VPN technology for remote access. This approach is the most common one to RBAC, though others are used.

Finally, another important AAA application is Endpoint Posture Validation, also referred to as Network Access Control (NAC). Unfortunately NAC is an inappropriate name because of its almost complete overlap with the more general AAA term—leading to a fair amount of confusion in the market. Endpoint posture validation refers to many different parameters in the ind ustry as it is an emerging technology. These parameters range from very narrow device-centric posture checking to a more identity-centric approach for secure mobile computing. Because this entire article is concerned with the latter, we will consider NAC in its narrow context of endpoint posture checking. With this label, NAC simply acts as another PIP for the PDP to use.

This time, though, instead of checking the client's credential, NAC checks the client's software configuration. This checking generally focuses on security-sensitive configuration details of the endpoint security software and the operating system itself, such as the revision, configuration, and current operating status. This client configuration data is gathered by a host agent on the client and then sent to the PDP or PIP for evaluation. The host agent is either permanent on the client or downloaded dynamically to acquire the information. Some NAC applications rely exclusively on external scanning of the client, although this scanning generally yields far less granular information than an agent would.

The challenge with NAC today is deploying a system built on standards. The IETF and the Trusted Computing Group (TCG) are both pursuing standards in this space. Meanwhile Cisco, Microsoft, and a host of smaller companies have offerings not currently based on any standard. Recent announcements from the TCG and Microsoft are changing this. The TCG recently standardized the as-implemented NAC protocol used by Microsoft's NAC approach. Though there is much more work to do, this should allow the beginnings of standards-based interoperability in NAC solutions since a core protocol in Microsoft's NAC is now a standard from the TCG. There is a great base in standards at a low enough layer in all the NAC approaches though, as the emerging standards use the protocols discussed in this article including 802.1X, IPsec, RADIUS, and LDAP.

Carrier-Managed Applications

Some carrier-managed AAA applications are similar to those for the enterprise and others are different. The common distinctions for almost all carrier applications are their large scale and their emphasis on accounting. Carrier applications include dialup, DSL or cable PPPoE, mobile or 3G, wireless hotspot, and metro wireless. Dialup is similar to the remote-access application in the enterprise section, but on a massive scale. Network Access Servers (NASs) for a large ISP are geographically dispersed, as are the PDP and PIP systems that support them. Clients communicate with the PEP (NAS) with PPP using one of the password credential techniques discussed in Part One of this article, and the PEP communicates with the PDP using RADIUS or Diameter.

Now consider DSL or cable PPPoE. Though PPPoE-based broadband access seems to be on the decline, many ISPs are still using PPPoE for the enhanced audit trail it provides compared with an unauthenticated connection. In the realm of mobile telephone networks, service providers are increasingly providing data services in mobile phones, and these services require AAA for security and billing. Such data services come in several varieties on both the second- and third-generation mobile networks. Additionally, smartphones are increasingly supporting 802.11-based wireless access as well, creating a complex relationship between the smartphone, mobile voice network, mobile data network, 802.11 data network, and VoIP-based voice services. Previously discussed standards such as EAP-SIM and EAP-AKA are trying to bridge some of these worlds, but there is much work to be done. Ideally, any smartphone should take advantage of the network with the fastest and richest set of services, and callers trying to reach a smartphone user as well as the user himself, should be shielded from this discovery and association process. Business motivators and detractors within the carrier space may affect this convergence.

The next carrier-managed AAA application to discuss is the wireless hotspot. Hotspots work much like dialup providers in that regular users get a password-based credential that lets them authenticate to the hotspot. In this context, the 802.1X protocol is less commonly used because the required client software is not yet ubiquitous in the client install base. More common is Web-based authentication much like that used to access broadband in a hotel. A critical security consideration for a hotspot operator is the ability to ensure that a given client is not connected to two hotspots at the same time—a situation that would indicate an account was shared between two or more users. This stipulation places an increasing burden on the accounting aspect of AAA, as with any carrier-based AAA application.

Finally, the last AAA application we examine is the metropolitan wireless network, known as "metro wireless." In metro wireless, an 802.11 network is deployed throughout a metropolitan area, and access is provided free of charge or for a fee. I live in Mountain View, California, which is home to Google's headquarters, and is where Google has installed its free, citywide metro wireless network.

Although the service is free, AAA is still required: to sign on to the wireless net­work, you must authenticate to Google using an ID. This step, much like signing on to a wireless hotspot, allows Google to trace network use to an individual (if necessary) and switch to a fee-based model later on if desired. HTTP authentication is most common in metro wireless environments, and, because of the on/off nature of access, little sophistication in policy decision is required other than validating the client's credential.

Emerging Applications

Several interesting applications of network AAA are emerging. The first is in building just-in-time networks, such as when establishing an on-scene emergency operations center after a disaster. In this situation, emergency workers often need to communicate in a protected environment, and the press that covers the disaster needs network access to send in its reports. The AAA application required here is a cross between wireless security, guest access, and RBAC.

Another emerging application is what we call "granular RBAC." As opposed to RBAC, which associates users into coarse-grained classes of users, granular RBAC knows much more about the users and makes a more sophisticated access decision.

One example of the use of granular RBAC is for classroom control in higher education. Increasingly, classrooms are wireless-enabled as a convenience feature for faculty and students. However, during exam time it is often useful to disable this access to the students taking an exam. Without a granular understanding of which clients are connecting to the network, this setup is very difficult to achieve without physically disabling large portions of the wireless network during exam time. By using AAA, a school could put class schedules inside an LDAP store along with the rest of the students' information. Professors could also register exam times by time and location. AAA could then prevent students from getting on the network inside the classroom during their exam period, while still letting them connect to the network when inside their dorm room.

Finally, the last application we consider is what I call "punitive access restrictions." As networks become more and more an integral part of our lives, it is natural to want as fast a network connection as we can find, creating the situation where denying access to the network based on past behavior (network related or not) can be used as a punitive action. Today, your driver's license can be revoked based on your behavior while on the road. Punitive access restrictions on the network could mirror the same technique (for example, punishing people who propagate a virus by restricting their network access for a time) or could be used even if the infraction is not related to the network. Imagine a university that has trouble getting students to return overdue library books. Fines are one way to get the books back quickly, but if the student’s parents are paying the bill, this consequence may not be as effective as the university desires.

However, imagine if the student's account record (in the PIP) had a directory attribute containing a count of the student's overdue library books. The network could then use RBAC or Quality-of-Service (QoS) techniques to provide degraded access to the student until the books were returned.

The Future of AAA

AAA as a concept has remained relatively unchanged since its inception. However, as this article has demonstrated, the techniques and applications of AAA continue to evolve. This section discusses some of the ways AAA may change more fundamentally in the future.

Security and Identity Convergence

Today the security and identity services provided by physical building access, network access, and application access are completely distinct. Security can be improved by communicating among these layers. Imagine a user executing a $10 million purchase order in a financial application. The chance of fraud would be reduced if the application could know that the user was coming from an authorized client with an up-to-date antivirus configuration. The chance of fraud could be further reduced by checking that the same user had accessed the badge access system of the building that day, and that the point of badge-access entry was consistent with the location where the application request originated. Within computer security, the notion of defense-in-depth has been around for a long time and is considered a best practice. Security and identity convergence adds new layers to this defense, and can potentially make all the layers more intelligent in their interaction.

User-Centric AAA

In the Web application world, the notion of user-centric identity is gaining ground. Kim Cameron's "Laws of Identity" [25] makes a compelling case that identity information housed in silos to be used by one organization is problematic. Several circles in the Web and e-commerce communities are beginning to look at identity differently. One change, consistent with the notion of user-centric identity, is that users should own their own identity information and should control how that information is used. The simplest example I can offer is shopping preferences at an online store. Most online stores make suggestions to you based on prior purchases. This data is owned by the online store, though, and not you, the consumer. If you wanted to take your purchasing profile from Amazon.com and transfer it to Barnes and Noble, it would not work. With user-centric identity, this kind of process is possible.

Another example is asserting a user's age. Depending on what you are trying to do on the Internet, you may need to validate that you are above a certain age. To do that, you are often asked to enter your date of birth, but that is more information than the site really needs.

If you could assert, with an identity you control but that is validated by a trusted party, that you are over the required age, it would not be necessary to disclose your date of birth (a process that is sometimes used as an authentication factor when you call places such as your credit card company).

The idea here is that you control your own information and limit what you need to share with others. This is very beneficial for privacy. One user-centric identity approach is included in Windows Vista through an application called "Card Space." Other approaches include OpenID and the Higgins Project. All of these approaches are somewhat consumer-focused, but if they take hold, it seems natural that there will be pressure for similar identity approaches in the enterprise and carrier space.

Federation

One of the natural evolutions of AAA infrastructure is to start federating access between multiple organizations. Imagine if visiting professors at another university's campus could access the network as guests using their password from their home location? Federation promises to make this possible, but the most challenging hurdles are political and logistical rather than technological. Protocols such as the Security Assertion Markup Language (SAML) [26] combined with RADIUS and LDAP can overcome this hurdle. The challenge is how to set up the trust relationships between the organizations to make it work. Eduroam based on RADIUS is an early effort delivering federation in Europe today.

Summary

This article, with its companion piece, has explored all aspects of AAA. Part One described the overall approach of AAA, how it works, and the elements that provide authentication, authorization, and accounting. Part Two has explored all the protocols used in the communication between the various AAA elements, the applications of AAA, and some thoughts about the future of AAA. AAA is a giant topic, and each of these sections, protocol descriptions, and applications could be expanded into a paper all by itself. The information in this article, combined with the references provided, should be a good starting point for your own examination of the specific aspects of AAA that are of interest to you.