Authentication, Authorization, and Accounting

The delivery of any type of services to customers by service providers normally requires three fundamental components so that the service provider can bill for service usage and deny service to undesirable customers. These components are Authentication, Authorization, and Accounting, commonly bundled together and identified by the acronym AAA:

Authentication is defined as the ability or act of the service provider or attendant to request from the user of a service or resource proof of his or her identity. This service component can come in different forms and technologies, and we will detail in the next section what these may be.
Authorization is the ability or act of a service provider to verify that a user whose identity is authenticated does indeed have the service access right. However, for anonymous access-based services, it may be sufficient that a user submit some credentials a trusted third party guarantees. One example may be a token-based service access paradigm, whereby an anonymous user gets access to the service simply by submitting to the service provider a token (for instance, some form of e-money or credits).
Accounting is the collection of usage data that can be processed by the service provider in order to issue bills or to limit the usage of the service itself. For instance, in times of trouble or by general policy, a company may decide to put a cap on the time an employee stays connected using the corporate network free phone-based remote access. A service provider may deny authorization to a prepaid user because, based on the accounting information, he or she has exhausted the credit limit.

Note

The entity providing service might not necessarily be a public network, like an ISP, but rather a corporation or an institution. In fact, for private enterprises AAA is a critical component in allowing employees access to corporate networks and protecting corporate network access from unauthorized users. In this respect, employees may be regarded as customers of the corporation, which is true also according to many modem books on management.

From the description of AAA components we have provided, it becomes clear that AAA is not only a set of three functionalities that a service provider's network usually supports but is also a set of three building blocks based on which some service logic, such as prepaid, discounting policies and network access policies, can be implemented.

User Authentication and Authorization

The user authentication and authorization process consists of two steps:

Collect authentication or authorization material from the user (which we may identify as the front-end process).
Verify material (referred to as the back-end process). Normally, the back-end process is the service provider's part of AAA functions. The front-end mechanism is technology-dependent, and the back-end process tends to be technology-independent.

Typical examples of front-end mechanisms for collection of the user's AAA material include the PPP authentication phase Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP), login information and the password sent in the clear by a Telnet application client to a Telnet server at the beginning of a Telnet session, a TLS-protected Web page where the user needs to input his or her data, and smart-card-based interfaces with Extensible Authentication Protocol (EAP) transfer of authentication information to a server that interprets the smart card information. Also, there are ways to measure biometric parameters and, for instance, identify individuals by scanning their retinas or fingerprints. In cellular networks, during the MS attach procedure (that is, when the user registers with the network its whereabouts and the network starts to manage the MS mobility) the network collects user authentication data that gets checked against data retrieved from the Home Location Register (HLR). This may come from direct user input, like in AMPS and CDMA networks, or from a chipcard known as Subscriber Identity Module (SIM) in GSM, or USIM in UMTS.

Examples of back-end process include a password file locally stored at the host device where the authentication data is collected or the query of a remote database or trusted third party for authorization and authentication decisions. In the wireless industry, for example, the approach chosen to authenticate subscribers is to download to the serving node all the necessary information to check authentication data collected from the mobile stations. Once this process is completed, the MS is then authorized to use the wireless network data services. Access to packet data networks via a wireless network may require an additional level of authentication (see Chapters 6 and 7 for some real life examples).

Accounting Data Collection

There are two approaches for accounting data collection. One approach is storing data locally at the serving node, such as an NAS, or an application host. Drawbacks to this approach include security problems, fate sharing (if the node fails, accounting data may also be lost), and often an overly complex procedure to collect accounting data if the user is mobile and can access multiple serving nodes. The preferred approach, which is being increasingly frequently adopted in the industry, is based on sending accounting data to a gateway or server function—periodically or in an event driven fashion—and then letting the billing system access a centralized point of contact for accounting data retrieval. Of course, this centralized accounting data collection functionality requires highly reliable platforms, data integrity protection, and disaster recovery mechanisms, but all of these requirements have to be satisfied only once, while local serving nodes do not have to support such complex and specialized functionality.

Let's examine how accounting is supported in wireless systems (see Figure 2.13). In GPRS systems, accounting data is transferred to a centralized Charging Gateway Function (CGF) based on ASN-1 specified Charging Data Record (CDR) formats using the GTP'(to be read "GTP prime") protocol described in [3GPP TS 32.015]. Also in GPRS, in some cases, like corporate or ISP network access, the corporation and the ISP may collect accounting data using RADIUS instead of or simultaneously with CGF, and the wireless carrier may decide to turn off GTP'-based accounting data collection, or keep it active, depending on whether flat rate or usage based bills are delivered to subscribers or on whether data is collected for trend analysis. In CDMA2000, accounting data is collected using RADIUS (extended with attributes specified in IS-835), thus sharing the same method used in data networking industry. More details on these systems is provided in Chapters 4, 6, and 7.

Figure 2.13: Accounting data collection architecture in UMTS/GPRS and CDMA2000.

AAA and Network Access Services: RADIUS

In dial-up access as well as other network access services applications, it has been recognized that storing files at each network access server would be impractical and result in security and management headaches. Consequently, the IETF chose an approach based on a client/server protocol to perform AAA functions. The standard defines a base protocol for authentication and authorization (RADIUS—[RFC2865]) and its extension for accounting (RADIUS Accounting—[RFC2866]). The network access server collects authentication data using one of the protocols described in the following sections, and then it queries a RADIUS server by sending to it a RADIUS Access Request message to obtain a decision on whether to admit the user to the network. If the user is admitted, the RADIUS server returns a RADIUS Access Accept message; otherwise, it returns a RADIUS Access Reject. In the RADIUS Access Accept, the RADIUS server may include attributes for configuration of the network access service delivered to the user, such as the user IP address, the allowed duration of the session, and the IP address and password information necessary to tunnel PPP frames to an LNS using L2TP.

Authentication Methods for Network Access

In the data networking industry, AAA has been so far largely based on the use of PPP, so most network access authentication methods have been developed to support the PPP authentication phase. The authentication phase takes place after the PPP link configuration phase has completed and before the network configuration phase starts, so that if the authentication phase is unsuccessful, no network layer configuration stage happens, the link gets turned down, and network access is denied. In the next paragraphs we consider three of the more popular methods: PAP, CHAP, and EAP.

The Password Authentication Protocol (PAP) described in [RFC1334] is a simple protocol that lets a PPP endpoint—normally a host—deliver the username and password in cleartext mode to the peer—normally an NAS—so that the peer can check their validity and allow or deny continuation of the PPP session and subsequent network access. This protocol has a weakness; an attacker may store the value of the username and password sent in the open using PAP and mount playback-based attacks on the NAS.

In response, the IETF defined a way to protect the authentication process from replay-based attacks via a three-way handshake protocol named Challenge Handshake Authentication Protocol (CHAP) described in [RFC1994]. In this protocol, a PPP endpoint can periodically challenge a peer using a random value string of bits, called a challenge, and the peer node must respond with a response built based on a secret shared with the challenger endpoint, scrambled using the value of the challenge according to an MD-5 digest function [RFC1321]. The endpoint then checks the value of the MD-5 digest contained in the response against an expected value because of its knowledge of the secret. If these results match, then the PPP session can continue; otherwise, the link is disconnected.

Flexibility in choosing the authentication protocol while the authentication phase is occurring allows authentication protocols to evolve without a software upgrade to the PPP endpoints. In fact, the selection of authentication protocols typically happens at PPP link configuration time, and the PPP link endpoints need to have hardwired implementation of all the necessary authentication protocols and the ability to negotiate them at link set-up phase. The Extensible Authentication Protocol (EAP) in [RFC2284] has been defined so that the selection of the authentication protocol can be deferred until the authentication phase and so that a back-end server can be used to implement the authentication algorithms, instead of requiring the endpoints to implement them. In fact, a PPP endpoint may be agnostic to the authentication mechanism and simply exchange EAP messages to external authentication servers implementing the authentication mechanisms. This allows you, for instance, to upgrade authentication clients on customers' hosts and servers in the operator's network without impacting the infrastructure. This may make possible a more smooth migration from password-based access to smart-card-based access and not require hard dates for the migration of all nodes. For instance, an NAS may route EAP frames to different authentication servers depending on the value of the selected authentication protocol.

The username- and password-based authentication method, such as those we just described (also known as two-factor authentication methods), have always been unpopular with network administrators because the maintenance of the password poses some burden on the supporting staff. In very large network deployments, frequent changes of password are counterproductive, since this normally pushes users to pick simple passwords that can be algorithmically changed (for instance, by appending two digits) at the end of a password prefix that does not change. Therefore, three-factor authentication methods are becoming more and more popular, since they do not require the user to manage a password. In fact, the user will be required to remember his or her identity (username) and a secret PIN that normally is not required to be changed over time. The user then reads some digits from a secure token card and inputs them in an appropriate area in the sign-on window, or a chipcard reader appends automatically these digits that allow for the generation of a one-time password.

AAA and Roaming: The Network Access Identifier

When a subscriber wants to use the same service as in the home network—that is, the network with which the customer-vendor relationship is in place—even when roaming to different service provider's networks (also known as visited of foreign networks), the serving visited network and the home network must be able to exchange AAA information. The way this has been addressed in the industry is to have the visited network AAA server dialogue with the home AAA server in a configuration known as RADIUS proxy. In this configuration, the visited network AAA server acts as an AAA client of the home network AAA server. This requires the visited network to be able to route the AAA messages to the right home AAA server. The IETF has laid out the method by defining a user identifier composed of the username and the domain (also known as the realm or Home Network Identifier). The format of the identifier is user@domain, and it is known as a Network Access Identifier [RFC2486].

When an NAI-formatted user identifier is received in an AAA message, the visited network AAA server can interpret the NAI part and route it to the home network AAA server. This model implies that there exists a trust relationship between the visited network and the home network, which in turn requires setting up security between the visited network AAA server and the home network AAA server. This does not scale well, since it has an n2 complexity—that is, each service provider needs to set up security with all the service providers. This has been addressed by allowing third parties like clearinghouses to act as a middleman or broker. In this arrangement, the broker is the entity with which each service provider establishes a trust relationship, and this reduces the complexity to be linear. In other words, the provider needs a single security arrangement, and the complexity is offloaded to the broker, which becomes an entity specialized to handle the agreements and in the process may offer settlement services. For enhanced security, the broker may simply act as a redirector of AAA transactions, so that the visited network AAA server and the home network AAA server could be put in direct communication after the initial query directed to the broker AAA server results in redirection of the transaction to the home AAA server. This feature is not part of RADIUS capabilities and is allowed by the next-generation AAA protocol, DIAMETER. Figure 2.14 illustrates the two different models.

Figure 2.14: AAA proxy and broker architecture examples: CDMA2000.

AAA Evolution: DIAMETER

One of the goals of the IETF AAA WG is to address deficiencies of the RADIUS protocol, both from a feature and a transport point of view. The DIAMETER protocol has been selected to solve issues related to the fact that RADIUS is a client/server-based protocol, by defining a peer-to-peer relationship between DIAMETER peer entities. This allows things like AAA server-initiated procedures. It also adds enhancements in server-to-server communication, allowing better performance in large proxy-based deployments, where server-to-server communication may lead to hundreds-of-transactions-per-second support requirements. These enhancements span the transport level, with the introduction of the Stream Control Transmission Protocol, [RFC2960]; the data model level, with hierarchical, object-oriented data models as opposed to the RADIUS flat, non-hierarchical model; and the security level, with the addition of integrity checks that would address frauds caused by malicious or unintentional alteration of AAA data by intermediate parties acting as brokers or proxies in a proxy chain. Also, DIAMETER allows for AAA brokers to act as redirect agents, thus making the communication between the visited AAA server and the home AAA server direct and mitigating the possibility of man-in-the-middle attacks.

The wireless industry is now considering DIAMETER for many other uses, such as for the interaction with a Home Subscriber Server by SIP servers in wireless networks complying with 3GPP Release 5 (R5). Work on DIAMETER is still ongoing in the IETF AAA WG at this writing, and indeed it may take some time for it to stabilize and be deployed commercially.