Overview of Authentication, Authorization, and Accounting (AAA)
AAA is an architectural framework, which provides three independent security functions to many Cisco devices such as Cisco routers, PIX firewalls, and switches:
Authentication Authentication provides a method to identify users before giving access to the requested services or network resources. When the user makes a connection request to the device or through the device, the user is challenged for the username and password, and either is then authenticated or denied.
Authorization Authorization controls access to network resources after the user is authenticated. Different users have different privileges, and different resources or information have different levels of confidentiality. Therefore, assigning resources based on the resource security and user privilege is an important aspect of access control. Authorization enables system administrators to accomplish this task. AAA authorization works by assembling a set of attributes that describe what the user is authorized to perform. Remote security servers, such as Remote Authentication Dial-In User Service (RADIUS) and Terminal Access Controller Access Control System (TACACS+), authorize users for specific rights by associating attribute-value (AV) pairs, which define those rights, with the appropriate user. Authorization can also be used to assign static IP addresses or to download the access control list (ACL), and so on. Note that authorization without authentication is meaningless.
Accounting Provides the method for collecting and sending security server information used for billing, auditing, and reporting. Examples of information collected by accounting include user identities, start and stop times, executed commands (such as Point-to-Point Protocol [PPP]), number of packets, and number of bytes. Accounting enables tracking of the services users are accessing and of the amount of network resources they are consuming.
AAA Architecture
There are three main components of the AAA framework, as shown in Figure 9-1.
Figure 9-1. Basic AAA Architecture
Client This is the user client PC or laptop from which users try to access resources.
Network Access Server (NAS) or AAA Client The client makes a connection to NAS either to configure it (for device management) or to access network resources through it (for example, Virtual Private Network setup for accessing the network resources of a local-area network [LAN] segment behind the NAS). The communication between the client and the NAS depends on the application. For instance, if the intention is to manage the NAS, then options available are Telnet, Secure Shell (SSH), and console. Examples of NAS or AAA clients include routers, switches, virtual private network (VPN) concentrators, and PIX firewalls.
Authentication Server The actual user profile resides at the authentication server when a built-in local user database is used. The Authentication Server can be integrated with various external user databases such as Microsoft Active Directory, Novell NDS (Netscape Directory Server), and so on. If the authentication server is integrated, the user profiles reside on the external user databases. When the client tries to access the network resources to log in to the NAS, NAS forwards that request to the Authentication Server. The NAS itself can act as the Authentication Server, but it is not very scalable. Examples of authentication servers include Cisco Secure Access Control Server (CSACS) on Windows (see Chapter 13, "Troubleshooting Cisco Secure ACS on Windows"), Cisco Secure Unix, and Cisco Access Registrar. The communication between the NAS and the AAA server requires special protocols, which leads to the next topic in the chapter.
AAA Communication Protocols
Several protocols are used in AAA communications between the NAS and Authentication Server including TACACS+, RADIUS, Kerberos, TACACS, and XTACACS. As TACACS+ and RADIUS are highly used protocols for AAA, we will discuss only these two protocols in the following section in greater details.
TACACS+
TACACS+ protocol was developed by Cisco Systems, Inc. as an extension of the original TACACS/XTACACS protocol specification (RFC 1492). TACACS+ comprises three components:
Protocol with a frame format that uses TCP/49
Authentication server
AAA Client (NAS)
There are several reasons why Transmission Control Protocol (TCP) is used for TACACS+ protocols. Here are some of them, as per TACACS+ specifications:
TCP offers a connection-oriented transport, whereas User Datagram Protocol (UDP) offers best effort delivery.
TCP provides a separate acknowledgment that a request has been received.
TCP provides an immediate indication of an unavailable server.
By using TCP keepalives, you can detect server crashes out-of-band with actual requests.
TCP is more scalable than UDP.
One of the unique and most important features of TACACS+ protocol is that it encrypts the entire packet communicated between the NAS and the AAA server. Hence, TACACS+ is a protocol of choice for device management. On the other hand, RADIUS encrypts only the password, but RADIUS protocol is the RFC standard. In addition, UDP has become highly reliable in today's network because of the upper-layer retries. Hence, RADIUS is the protocol of choice for Network Access Control-related implementations such as X-Auth for a VPN connection and PPP authentication for dial-in users.
TACACS+ Operation for Authentication
TACACS+ uses three different packet exchanges between the NAS and Authentication server for completing authentication.
START First packet sent by NAS to TACACS+ service
REPLY Sent by TACACS+ service to NAS
CONTINUE Sent by NAS to carry follow-up information
The following steps take place between the user, NAS, and the Authentication server as shown in Figure 9-2.
Figure 9-2. TACACS+ AAA Packet Flows
[View full size image]
Step 1. When the connection is initiated by the client to the NAS, NAS initiates the START packet to the TACACS+ service to obtain a username prompt.
Step 2. TACACS+ service sends a REPLY packet in return to NAS asking for a username, which is then displayed to the user.
Step 3. The user enters a username, and the network access server sends a CONTINUE packet to TACACS+ service with the user name information that it just received from the client.
Step 4. TACACS+ service sends a second REPLY asking for a user password, which is then forwarded by the NAS to the user.
Step 5. The user enters a password, and the password is then sent to the TACACS+ service with a CONTINUE packet.
Step 6. TACACS+ service makes the decision whether to allow or deny the request and sends one of the responses shown in Table 9-1 in REPLY packet.
Table 9-1. The Response and Meaning of the Response for Authentication from the TACACS+ Server Response
Description
ACCEPT
The user is authenticated and service may begin at this stage. If, however, NAS is configured to require authorization, authorization starts at this time.
REJECT
The user has failed to authenticate, either because of a wrong username or password.
ERROR
An error occurred some time during authentication phase. Error condition may occur due to shared secret key mismatch, no existent AAA client on the TACACS+ daemon, or because of some other protocol violation. If an ERROR response is received, the network access server typically tries an alternative method for authentication if configured.
Note
START and CONTINUE packets are always sent by the NAS, and REPLY is the only packet sent by the TACACS+ service to exchange the authentication information and the decision about users' authentication.
TACACS+ Operation for Authorization
If configured, authorization starts immediately after the authentication succeeds. Because TACACS+ supports the independent AAA architecture, Authentication and Authorization responses are handled in separate packets. This makes TACACS+ more desirable than RADIUS for device management when command authorization is required. This is because RADIUS handles both Authentication and Authorization replies in the same packet. Without successful user authentication, authorization will not be triggered. TACACS+ completes authorization with the following two packets as shown in Figure 9-2:
REQUEST packet Always sent by NAS
RESPONSE packet Always sent by the TACACS+ service
The following sequence of events takes place for authorization:
1. Following authentication, the authorization process starts with NAS sending an authorization REQUEST packet to the TACACS+ server. This packet may contain information about the privileges (0-15) or the service (EXEC or PPP) needed for the client to access the network resources or the device.
2. The TACACS+ server then responds with one of the messages shown in Table 9-2.
Table 9-2. The Response and Meaning of the Response for Authorization from the TACACS+ Server Response
Description
FAIL
Services or Privileges requested by the NAS for the client are not authorized.
PASS_ADD
This is a successful authorization message, which tells the NAS to authorize the arguments it sent via REQUEST packet and also authorize additional arguments that the TACACS+ Server added to the RESPONSE packet (in addition to what's requested).
PASS_REPL
This is a successful authorization message just like PASS_ADD. Here, however, the TACACS+ server is asking the NAS to replace the arguments that it sent with the REQUEST packet with the argument that the Server authorizes in the RESPONSE packet.
ERROR
Error condition during authorization phase. For details refer to Table 9-1.
FOLLOW
With this message, the TACACS+ server recommends to NAS that it contact another TACACS+ server. It is up to NAS, however, to entertain the suggestion. The suggestion for the alternate TACACS+ server comes in the REPLY packet.
TACACS+ Operation for Accounting
TACACS+ accounting works very much like authorization in TACACS+ protocol. Just as with authorization, TACACS+ uses REQUEST and RESPONSE packets to exchange the information that needs to be logged for billing and auditing. Accounting in TACACS+ starts with NAS sending a REQUEST packet that contains one of the accounting records shown in Table 9-3.
Table 9-3. Accounting Records Go into the REQUEST Packet for Accounting Accounting Records
Description
START Record
This indicates to the TACACS+ server that the service is about to begin.
STOP Record
This indicates to the TACACS+ server that the service is about to stop.
CONTINUE Record
This provides the TACACS+ server updated information. This is sent while the service is in progress. A record being both Start and Continue is an indication that the Update record is a duplicate of the original Start record.
Upon receiving the REQUEST packet, the TACACS+ server sends a REPLY packet to the NAS with one of the status messages shown in Table 9-4.
Table 9-4. Status in the REPLY Packet from TACACS+ Server to NAS Status
Description
SUCCESS
TACACS+ has received the ACCOUNTING packet successfully.
ERROR
AAA failed to write the information to the database.
FOLLOW
TACACS+ Server suggests that the NAS send the accounting record to another TACACS+ server. Details on the alternate server information are in the REPLY packet; however, it is up to NAS to adhere to the request.
RADIUS
RADIUS was developed by Livingston Enterprises, Inc. RADIUS Authentication and Authorization is defined by RFC 2865, and RADIUS accounting is defined by RFC 2866. The maximum packet length is 4096 bytes, and each value can have a maximum length of 253 bytes. As with TACACS+, RADIUS comprises three components:
Protocol with a frame format that uses UDP/1812 (authentication and authorization) and UDP/1813 (for accounting). UDP/1645 is also used for authentication and authorization, and UDP/1646 for accounting.
Authentication Server
AAA Client (NAS)
Though TCP is a reliable protocol and works very well for TACACS+, UDP is effective and very useful for RADIUS protocol. The following are some of the advantages of using UDP for RADIUS protocol:
If the request to a primary authentication server fails, a secondary server must be queried.
The timing requirements of this particular protocol are significantly different than TCP provides.
The stateless nature of this protocol simplifies the use of UDP.
UDP simplifies the server implementation.
The following are some of the weaknesses of the RADIUS protocol:
Unlike TACACS+, RADIUS does not encrypt the whole body with an MD5 hashing algorithm. It encrypts only the end user password in the RADIUS packet.
RADIUS does not support the independent AAA architecture as Authentication and Authorization responses are included in a single packet. This makes it less than desirable for device management when command authorization is required.
RADIUS Operation for Authentication and Authorization
RADIUS uses four packets to complete authentication and authorization between the NAS and the AAA Server. When the user wants to connect to the network using NAS, NAS collects and forwards the following information in an ACCESS-REQUEST packet as shown in Figures 9-3 through 9-5:
Username
User password in encrypted format
NAS IP address and the port
Type of service user wants
Figure 9-3. RADIUS Authentication and Authorization Packet Flows
[View full size image]
Note
Note that this is different than TACACS+, because in the case of TACACS+ this username and password challenge comes from the AAA server. In RADIUS, this information is collected by the NAS, before making the Access-Request to the AAA Server.
Figure 9-4. RADIUS Authentication and Authorization Packet Flows (Continued)
[View full size image]
Figure 9-5. RADIUS Authentication and Authorization Packet Flows (Continued)
[View full size image]
The RADIUS Server responds to NAS with one of the messages shown in Table 9-5.
Table 9-5. AAA Server Responses from the AAA Server Response
Description
Access-Accept
If the user is successfully authenticated by the AAA server, this message is sent to the NAS, which also contains Attribute Value (AV) pairs for the user to be applied on the NAS, such as downloadable access control list (ACL), static IP address, DNS server IP, and Windows Internet Name Service (WINS) Server IP.
Access-Reject
If the user authentication fails on the AAA server, the AAA Server sends this message to NAS. AAA server may send text messages in the Access-Reject message to present to the user.
Access-Challenge
If the AAA server needs additional information, such as the user's password for Challenge Handshake Authentication Protocol (CHAP), it uses the Access-Challenge message to inform the NAS, which then is forwarded to the client. On receiving the information, the NAS forwards the information (in this case user's password) to the AAA server in the ACCESS-REQUEST packet. This message continues until the ACCESS-ACCEPT or ACCESS-REJECT is sent from the AAA server to the NAS.
RADIUS Operation for Accounting
Accounting in RADIUS works with ACCOUNTING-REQUEST and ACCOUNTING-RESPONSE packets. The NAS sends an ACCOUNTING-REQUEST packet at the beginning or end of a user session. The Start message in the ACCOUNTING-REQUEST packet contains information about a user's identity and the service being offered to users. When the user session is over, the NAS sends another ACCESS-REQUEST packet to the AAA Server with a Stop message informing the server of the type of service that was delivered to the user. There may be additional information being sent from the NAS, such as the amount of time the user is connected and the number of bytes transferred. This information is sent from NAS to the AAA server with AV pairs. Figure 9-6 shows the exchange of RADIUS ACCOUNTING packets between the NAS and the AAA server.
Figure 9-6. RADIUS ACCOUNTING Packet Flows (Continued)
[View full size image]
Difference between RADIUS and TACACS+
To decide which protocol to use for which features, it is important to note the difference between the TACACS+ and RADIUS protocols. Table 9-6 summarizes the differences between these two very important protocols for AAA implementation.
Table 9-6. RADIUS versus TACACS+ RADIUS
TACACS+
RADIUS uses UDP.
TACACS+ uses TCP.
RADIUS encrypts only the password in the ACCESS-REQUEST packet. Less secure.
TACACS+ encrypts the entire body of the packet. More secure.
RADIUS combines authentication and authorization.
TACACS+ uses the AAA architecture, which separates authentication, authorization, and accounting.
Industry standard (created by Livingston).
Cisco proprietary.
RADIUS does not support ARA access, Net BIOS Frame Protocol Control protocol, NASI, and X.25 PAD connections.
TACACS+ offers multi-protocol support.
RADIUS does not allow user control of which commands can be executed on a router.
TACACS+ provides two ways to control the authorization of router commands: per user or per group.
AAA can complement many security features provided by the router. The following is a list of all the features in which AAA complements the router with additional security. These features are discussed in detail in the section entitled "Analysis of Problem Areas."
Router management.
Point-to-Point Protocol (PPP) authentication for async dial-in, ISDN, and so on.
AAA and pre-shared keys for Secure Internet Protocol (IPsec).
Extended authentication (X-Auth) for IPsec.
AAA and auth-proxy.
AAA and lock and key.
AAA for Virtual Private Dial-up Network (VPDN).
Network Admission Control (NAC).