AAA (Authentication, Authorization and Accounting)

Download

AAA stands for Authentication, Authorization and Accounting.

This protocol was defined by the Internet Engineering Task Force in RFC 6733 and is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations.

AAA Working

• Authentication is the process of identifying an individual, usually based on a username and password. Authentication is based on the idea that each individual user will have unique information that sets him or her apart from other users.

• Authorization is the process of granting or denying a user access to network resources once the user has been authenticated through the username and password. The amount of information and the amount of services the user has access to depend on the user's authorization level.

• Accounting is the process of keeping track of a user's activity while accessing the network resources, including the amount of time spent in the network, the services accessed while there and the amount of data transferred during the session. Accounting data is used for trend analysis, capacity planning, billing, auditing and cost allocation.

AAA is used in scenarios where a NAS(Network Access Server) or a RAS(Remote Access server) Acts like a switch granting or denying access to the internet or intranet for a user based on AAA authentication & authorization.

Elements of Authentication

When performing authentication, numerous elements can be evaluated before a PDP reaches its access decision. At a high level, these elements can be broken down into three categories: the principal itself (the user, device, or service requesting access), the credential the principal submits (shared key, one-time password, digital certificate, or biometric credential), and the contextual information describing the transaction (location, time of day, software state, and so on).

• Principal: The principal is the entity requesting authorization. It is generally some combination of user, device, or service. When concerned with a user, the PIP can provide attributes about the user such as role or group affiliations, job title, e-mail address, physical address, and so on.

• Credential: The next element the PDP considers is the credential the user or device submits as proof of identity. There are four main types of credentials: shared key (password), one-time password (OTP), digital certificate, and biometric credential. This section examines each of these types. The first and most widely used form of credential is the shared key, typically a user password. AAA deployments that use shared keys can be subdivided based on the protocol the system uses to verify the password, including the Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), and Microsoft CHAP Extensions (MS-CHAP) Versions 1 and 2. PAP authentication is a plaintext authentication method that is not recommended for use in security-sensitive environments.

Authorization Approaches

At its core, authorization means determining what a client is allowed to do on the network. However, the granularity of this authorization is only as good as the sophistication of the PDP and the enforcement capabilities of the PEP. This section examines the authorization options for network AAA, including Layer 2 segmentation, Layer 3 filtering, and Layer 7 entitlements. It closes with an examination of some of the challenges encountered when sending or "provisioning" the authorizations from the PDP to the PEP.

• Null Authorization (Authentication Only): Strangely the most common authorization in AAA is no authorization at all. After the authentication event occurs, the client is immediately granted full access to the network. This characteristic is a holdover from the original goal of remote-access AAA: to perform an authentication check that simply determines whether the client should be trusted as if it were connected to the organization's home network.

• Layer 2 Segmentation: For wireless access points and Ethernet switches, the most common form of authorization enforcement is Layer 2 segmentation, which works by splitting the network into multiple logical segments, isolating certain classes of client from one another.

• Layer 3 Filtering: Layer 3 filtering authorizes access to resources through ACLs configured on Layer 3 devices (routers, Ethernet switches, security gateways, and so on). These ACLs (which generally encompass Layer 4 of the OSI stack as well) can enforce authorizations to a range of hosts, specific hosts, or services on those hosts. As mentioned earlier, Layer 3 filtering can be combined with Layer 2 segmentation to provide aggregate authorizations for an entire VLAN.

• Layer 7 Entitlements: Increasingly, security gateways are able to go beyond Layer 3 and 4 filtering and are starting to become application-aware, meaning that the authorizations handed from the PDP to the PEP can be very granular, focusing on the specific applications that are needed rather than broader filters based on segments or hosts on the network. Because this technology is still relatively new, there are no standards yet to make this interaction work transparently. As a result, most granular application filters are written on the PEP itself in order to allow the PDP to trigger a pre-existing profile on the PEP.

• Provisioning Challenges: In AAA parlance, the term "provisioning" refers to communicating a user's session rights and constraints to the PEP so that the PEP can grant and enforce these permissions. One of the most difficult aspects of provisioning access rights on a PEP is communicating the decision of the PDP in a format the PEP can understand. This fact is one of the reasons that many PEPs come with a lightweight PDP. This approach solves the narrow problem for that PEP but creates management challenges when coordinating network AAA across a broader enterprise, because the enterprise AAA policies must be implemented individually on each unique type of PEP on the network. Because RADIUS is the most commonly used network AAA protocol, it is natural to communicate the PDP decision using that protocol. RADIUS attributes such as the "filter-id" allow the PDP to trigger a preexisting filter on the PEP.

Network Access Server (NAS)

The Network Access Server (NAS) is a service element that clients dial in order to get access to the network. An NAS is a device having interfaces both to the backbone and to the POTS or ISDN, and receives calls from hosts that want to access the backbone by dialup services. NAS is located at an Internet provider's point of presence to provide Internet access to its customers.

Basic Architecture of NAS/Radius/AAA

A Network Access Server is:

• A single point of access to a remote resource.
• A Remote Access Server, because it allows remote access to a network.
• An Initial Entry Point to a network.
• A Gateway to guard to protected resource.

AAA Flow

A Client Connects to a AAA-Protected Network

1. The client attempts to connect to the network, is challenged for identity information, and sends this information to the PEP. In this example, let's assume the client is a laptop with a worker attempting to access an organization's VPN from a remote location. Additionally, we'll assume this is a valid, permitted use of the network.
2. The PEP sends the collected identity information to the PDP. In some cases (discussed in part two of this article), the PEP cannot see the specific identity information provided but instead relays the information directly to the PDP.
3. The PDP queries any configured PIPs for information about the client and validates that the credential provided by the client is valid. In this example, the PIP is an LDAP directory.
4. The PIP returns a success or failure message from the credential validation step and sends additional information about the client to the PDP for evaluation. This information could include the role of the user, the home location for the user, and so on.
5. The PDP evaluates information learned about the client through the client, PEP, and PIP; the role of the PEP and PIP that serviced the request; and any contextual information (such as time of day) against its configured policies. Based on this information, the PDP makes an authorization decision.
6. The PDP sends the PEP the authentication result and any authorizations specific to the client. These authorizations trigger specific PEP actions to apply to the client. For example, the authorization data might trigger specific Access Control Lists (ACLs) or IP pool assignments for the client.
7. The PDP also sends the result of this transaction to the accounting system.
8. The PEP applies the authorization profile learned from the PDP and sends the "authentication successful" message to the client. The PEP can also be configured to send accounting information on this new connection to the accounting and reporting system.
9. The client accesses the production network through the PEP.

Types of AAA Servers

• Access Network AAA (AN-AAA): Communicates with the RNC in the Access Network (AN) to enable authentication and authorization functions to be performed at the AN. The interface between AN and AN-AAA is known as the A12 interface.
• Broker AAA (B-AAA): Acts as an intermediary to proxy AAA traffic between roaming partner networks (i.e., between the H-AAA server in the home network and V-AAA server in the serving network). B-AAA servers are used in CRX networks to enable CRX providers to offer billing settlement functions.
• Home AAA (H-AAA): The AAA server in the roamer's home network. The H-AAA is similar to the HLR in voice. The H-AAA stores user profile information, responds to authentication requests, and collects accounting information.
• Visited AAA (V-AAA): The AAA server in the visited network from which a roamer is receiving service. The V-AAA in the serving network communicates with the H-AAA in a roamer's home network. Authentication requests and accounting information are forwarded by the V-AAA to the H-AAA, either directly or through a B-AAA.

Core Components of AAA

• Client: The client is the device attempting to access the network. The client either authenticates itself, or it acts as a proxy to authenticate the user.

• Policy Enforcement Point (Authenticator): The Policy Enforcement Point (PEP) is sometimes called the authenticator or dial-in server, VPN concentrator, firewall, gateway General Packet Radio Service (GPRS) support node, Ethernet switch, wireless access point, or an inline security gateway. The PEP is responsible for enforcing the terms of a client's access. This enforcement varies based on the capabilities of the PEP and is discussed later in this article.

• Policy Information Point: The Policy Information Point (PIP) is a repository of information to help make the access decision. It could be a database of device IDs, a user directory such as the Lightweight Directory Access Protocol (LDAP), a one-time password (OTP) token server, or any other system that houses data relevant to a device or user access request.

• Policy Decision Point (AAA Server): The Policy Decision Point (PDP) is the brain of the AAA decision. It collects the access request from the client through the PEP. It also queries any relevant PIPs to gather the information it needs to make the access decision. The PDP, as its name implies, is the entity that makes the final decision around network access. It also can send specific authorizations back to the PEP that apply settings or constraints to the client's network traffic.

• Accounting and Reporting System: Whether on a dedicated system or built as part of a PDP, tracking use of the network with accounting is one of the best features of AAA. With all forms of network access now offering controlled access, the AAA service can tell you who got on the network, from where, and what that person was granted access to.

AAA Protocols

Radius is an AAA protocol for applications such as Network Access or IP Mobility. Besides Radius, we have the following protocols in AAA:

• Terminal Access Controller Access Control System (TACACS)

TACACS is a remote authentication protocol that is used to communicate with an authentication server commonly used in Unix networks. TACACS allows a remote access server to communicate with an authentication server in order to determine if the user has access to the network.

• TACACS+

TACACS+ provides access control for routers, network access servers, and other networked computing devices via one or more centralized servers. It uses TCP and provides separate authentication, authorization, and accounting services. It works on port 49.

• DIAMETER

Diameter is a planned replacement of Radius.

Benefits of Using AAA

AAA provides the following benefits:

• Increased flexibility and control of access configuration
• Scalability
• Standardized authentication methods, such as RADIUS and TACACS+
• Multiple backup devices

Choosing between Radius and Tacacs

• RADIUS Advantages

The main advantage of RADIUS is availability. Although all modern Cisco devices support TACACS+, support outside the Cisco community is limited. If you work on a mixed vendor network, RADIUS is likely the best option available.

• TACACS+ Advantages

As an extension of the RADIUS protocol, TACACS+ implements most of the features of RADIUS. The advantages of TACACS+ are in how it changes the implementation of RADIUS, as well as how it extends the protocol to meet the needs of modern networks.

1. TACACS+ uses TCP instead of UDP. TCP guarantees communication between the client and server. Unlike UDP, which is connectionless, TCP initiates a connection with the server and is not as susceptible to situations such as network congestion and server crashes.
2. TACACS+ encrypts all of the data in the TACACS+ packet. Although RADIUS does encrypt the password in the packet, it doesn't protect against other data interception such as username and accounting information.
3. TACACS+ allows for different methods of authentication, authorization, and accounting. RADIUS couples authentication and authorization, making it difficult to use different servers for these purposes.
4. TACACS+ allows a network administrator to define what commands a user may run. This fine grain level of control allows more controlled access for a greater number of users on a network.

When choosing an AAA protocol to use on a Cisco-based network, TACACS+ is the obvious choice. RADIUS (or a combination of TACAS+ and RADIUS) may be required if the network uses non-Cisco devices that do not support the TACACS+ protocol.

Basic AAA Configuration on IOS

Steps to configuring AAA:

• Enable AAA

Router(config)# aaa new-model

• Configure authentication, using RADIUS or TACACS+

There are two approaches to configuring TACACS+ servers. In the first, servers are specified in global configuration mode using the command tacacs-server to specify an IP address and shared secret key for each server:

Router(config)# tacacs-server host 192.168.1.3 key MySecretKey1

Router(config)# tacacs-server host 192.168.2.3 key MySecretKey2

This approach is sufficient for many deployments, but is problematic if you want to reference only a subset of the defined servers for a certain AAA function. For example, suppose you want to use one TACACS+ server for control plane authentication on the router itself, and the second server for authenticating PPP connections. In this case, you would assign the servers to named AAA server groups:

Router(config)# aaa group server tacacs+ LoginAuth

Router(config-sg-tacacs+)# server 192.168.1.3

Router(config)# aaa group server tacacs+ PPPAuth

Router(config-sg-tacacs+)# server 192.168.2.3

• Define the method lists for authentication

Router(config)# aaa authentication login default group tacacs+ local

The above method list handles only the authentication aspect of AAA. By itself, this list only allows us to authenticate as a user with privilege level 1 (user exec mode). To communicate a heightened privilege level (e.g. privilege level 15, or "enable mode") from the TACACS+ server, we also need to define an authorization method list for IOS shell creation.

Router(config)# aaa authorization exec default group tacacs+ local

• Apply the method lists per line/ per interface

Router(config)# line console 0

Router(config-line)# login authentication default

Router(config)# line vty 0 15

Router(config-line)# login authentication default

----

@NetwaxLab