Chapter 1. Authentication, Authorization, Accounting (AAA)

This chapter covers the following topics:

It has always been interesting to me that different aspects of networking can relate so closely to the things that we do in real life. If you would have asked me to explain authentication, authorization, and accounting (AAA) seven years ago, you would have probably received a different answer. If I were to sum it all up in simple terms today, I would say that AAA is the process of verifying who you are (authentication), what you can do (authorization), and what you did while you were here (accounting). Of course that’s perhaps oversimplifying it, but you at least get the point. There are multiple actions involved in AAA because AAA is a framework that provides three independent functions.

The goal of this chapter is to put AAA into perspective so that when the time comes to configure and verify you will be well equipped to do so and should the need arise, understanding the differences of each process will strengthen your skills at troubleshooting. In the following sections you’ll learn what authentication, authorization, and accounting is, put in terms that relate to everyday life. Finally you’ll learn about two common protocols used in AAA: Remote Authentication Dial-In User Service (RADIUS) and Terminal Access Controller Access Control System Plus (TACACS+).

Authentication Overview

As was mentioned in the introduction paragraph, I now see things in a relationship with common activities in day-to-day life. I have come to compare common networking scenarios to scenarios that happen outside of networking and see many parallels. Take for instance a night at the movies. You buy a ticket to see a new release and are excited about seeing it. You walk through the entry of the theatre and are asked to show your ticket. You are being authenticated. Authentication can take place based on something you have. In this case, you have a ticket, so you are admitted.

In another scenario, you are invited to a secret society meeting—spies only! Upon arrival, you are asked for the “secret password.” You reply “JumpinJackFlash” and are admitted to the meeting. Again you were authenticated, only this time, it was not something you had that you used to authenticate; it was something you know.

For a third example, you were so wrapped up in that secret spy movie that you saw you have decided to join the ranks and become a spy (this is why you infiltrated the secret society). After your spy training, you are given the location to a secret spy hangout. When you arrive at the door, you see a retinal scanner and a fingerprint scanner. You present your eye and your index finger and the big metal door slides open allowing entrance. In this situation, you were again authenticated, only this time it wasn’t based on something you had (although having your index finger and eye is a good thing), and it wasn’t something you knew. This time it was something you are.

In short, authentication can be based on:

• Something you have

• Something you know

• Something you are

When you relate this to a Cisco environment, you will see that various scenarios would call for different types of authentication. For example, using IEEE 802.1X (discussed in Chapter 8, “IOS Switches”) you might choose to authenticate users on a wireless network using Extensible Authentication Protocol-Transport Layer Security (EAP-TLS). This would involve the use of a client certificate (something you have) to authenticate to the authentication server. In another scenario, you would like to use the Secure Shell (SSH) protocol to manage a router on your network. Upon connecting to your router, you are presented with a prompt to enter a username followed by a prompt to enter a password (something you know).

Just as many types of authentication processes take place in today’s world, many types of authentication methods can be performed on a Cisco device. An example of an authentication method might be a state-issued driver license or a boarding pass for a specific airline. When the airline attendants request identification for the use of their services, you are prepared with the proper identification. This is the most basic process of AAA.

Authentication provides a method for identifying users and includes login and password prompting, challenge and response functions, messaging support, and quite possibly encryption as well. Authentication usually takes place prior to a user being allowed access to any of the network resources.

When you configure a Cisco device for authentication, you need to complete three basic steps:

Step 1. Enable the AAA process. Although AAA is a common protocol that is seen in most enterprise networks, the protocol is not enabled by default.

Step 2. Define the location, protocol, and secret key for the server communication.

Step 3. Define a method list and protocols for authentication.

A method list defines the type of authentication to be performed and in which sequence to perform it. You must apply the method list to an interface before the authentication methods are used; however, one exception to this rule of application exists. A default list exists and believe it or not, it’s named “default.” This default method list is applied to any interface, line, or service, if a specific list is not configured or specified already. In a nutshell, the default method list does whatever you tell it to. You are responsible for defining the methods used by the default method list.

Auth-Proxy is a method by which users can be authenticated when accessing a network service. As users attempt to access a network service, they are presented with an authentication prompt. The users can then prove that they are who they say they are. In your network environment, this prompt can be presented in a Telnet application, File Transfer Protocol (FTP) application, or web application. You can also use virtual authentication methods such as virtual Hypertext Transfer Protocol (HTTP) and virtual Telnet. If users need access to other resources, one of the previously mentioned methods of access must be performed first or an alternative method such as virtual Telnet must be used because other protocols can’t be used to present the user with a prompt.

Authentication Example

In this example, your user “local-admin” is attempting to Telnet to a Cisco router. The Cisco router is configured to request authentication from anyone that attempts to access it via Telnet. As the user enters a password, it is sent as clear text to the router. The router then takes that username and password and if authenticating to an external server, places it in a packet that is sent to an AAA server, such as Access Control Server (ACS), or it could keep the credentials local and compare them to a locally configured username and password.

Here is a step-by-step look at the process as illustrated in Figure 1-1:

Figure 1-1. A Simple Authentication Example

Step 1. The client establishes connection with the router.

Step 2. The router prompts the user for her username and password.

Step 3. The router authenticates the username and password in the local database. The user is authorized to access the network based on information in the local database.

Of course, Telnet is not the recommended type of connectivity in which to perform authentication because anyone that has access to the network and the data path can see the username and password by using an application such as Wireshark. In fact, most protocols don’t encrypt the password and yes, although some claim encryption, it’s often a weak cipher and can be susceptible to brute force attacks. More secure methods might include protocols such as the Challenge Handshake Authentication Protocol (CHAP), or even the use of one-time passwords or the use of smart tokens such as RSA SecurID or CRYPTOCard. The point is that you should really understand the type of traffic you are allowing users to authenticate within.

Authorization Overview

To take AAA a step further, imagine that you are about to take a vacation. You are going to take a commercial airline to your vacation hotspot. The airplane has a couple of rows in the front that are very nice, leather, wide, and comfortable. You would prefer to sit here instead of the seats that are farther back because those are stiff, uncomfortable, and do not offer much leg room. Unfortunately, if you purchased a coach class ticket, you cannot sit in the first-class seat in the front of the plane. Similar to this process is the authorization function of AAA. If you have a coach-authorized ticket, you cannot access first-class resources. This information is all kept in the airline’s database and can easily be verified by looking up your identity (name) in the computer and referencing the seat assignment. That’s the basic process of authorization.

Authorization is a method of providing certain privileges or rights to remote users for services requested. It’s likely that you are going to see EXEC authorization, where one user is allowed access to an EXEC shell and another is allowed access to a privilege shell. This can be configured for a group that a user belongs to, or it can be configured on an individual user basis, depending on your goal. User authorization overrides group authorization. Authorization can be configured locally in some cases or kept on a remote AAA server. The remote server might be easier for administration depending on your network environment. Authorization is the second module of the AAA framework.

The following steps are needed for authorization to take place:

Step 1. AAA assembles a set of attributes based on the services that a user is requesting authorization to perform.

Step 2. These attributes are compared against a database that contains the user’s actual permissions.

Step 3. After a user’s authorization is verified or not verified, the result is returned to the AAA process.

Step 4. After the preceding step sequence, the AAA process is then able to impose the proper restrictions to the user data.

Step 5. If the user’s authorizations are located on a remote server, they are usually determined by comparing to Attribute-Value (AV) pairs, which are discussed in Chapter 13, “Authentication, Authorization, and Accounting of VPN on ASA.”

As seen in the “Authentication Overview” section of this chapter, a method list configures authentication. A method list is also used to define the method of authorization. One thing to keep in mind though is that you’ll need to authenticate a user before you can determine what that user is authorized to do. Therefore, authorization requires authentication.

Authorization Example

Figure 1-2 demonstrates a basic authorization process that can take place; that is, after the authentication process shown in the previous example. One difference you might note here is that with the previous authentication example, only a local authentication was discussed. In this authorization example, the AAA server is added to give you an idea of the process when an external server is used. This server can be used for authorizations, as seen in Figure 1-2, but it can, and usually is, also used to authenticate users.

Figure 1-2. Basic Authorization of FTP

In this situation, the following steps take place:

Step 1. After authentication has been completed, a session is established with an AAA server.

Step 2. The router requests authorization for the requested service from the AAA server.

Step 3. The AAA server returns a PASS/FAIL for authorization.

As already seen with authentication, a method list is also used here. This method list, however, does not define a method of authentication; rather, this method list defines what authorization is to be performed. The configuration of a method list for authorization is very similar to the method list configuration for authentication that was already discussed. It is nearly the same as a method list that would define accounting, although there will be slight differences.

Accounting Overview

The final portion of AAA is the accounting module. Accounting can also be explained using an example of the airline industry as seen in the “Authorization Overview” section. As you enter or board the plane, you hand a boarding pass to the agent, and it is scanned through a machine. This accounts for you boarding the plane. As far as the airline is concerned, you were there and you were on the airplane. AAA accounting is similar. When you access the network, AAA can begin to track any actions you take. After you authenticate, you were there, as far as the AAA process is concerned.

Accounting in a Cisco environment enables you to track the amount of network resources your users are accessing and the types of services they are using. For example, system administrators might need to bill departments or customers for connection time or resources used on the network (for example, total time connected). AAA accounting enables you to track this activity, as well as suspicious connection attempts into the network.

When using AAA accounting, the router can send messages either to the AAA server or to a remote SYSLOG server, depending on your configuration. You then have the ability to import the accounting records into a spreadsheet or accounting program for viewing. The Access Control Server (ACS) can be used to store these accounting messages, and you can also download these accounting statements in .CSV format or use Open Database Connectivity (ODBC) logging, which is supported in ACS. You can even install a Log agent and forward log information to a Cisco Secure-Monitoring Analysis and Response System (CS-MARS) for mitigation monitoring and correlation.

The accounting records sent by a Cisco device to the accounting server are sent in the form of an AV pair. An AV pair is an attribute and a value. Some of these attribute value (AV) pairs contain information such as username, address, the service being requested, or the Cisco device that this request is going through, also known as the access server or AAA client.

AAA supports multiple types of accounting including the following:

• Network accounting: Network accounting provides information for all Point-to-Point Protocol (PPP), Serial Line Internet Protocol (SLIP), or Apple Remote Access Protocol (ARAP) sessions, including packet and byte counts.

• Connection accounting: Connection accounting provides information about all outbound connections made from the AAA client, such as Telnet, local area transport (LAT), TN3270, packet assembler/disassembler (PAD), and rlogin.

• EXEC accounting: EXEC accounting provides information about user EXEC terminal sessions (user shells) on the network access server, including username, date, start and stop times, the access server IP address, and (for dial-in users) the telephone number the call originated from.

• System accounting: System accounting provides information about all system-level events (for example, when the system reboots or when accounting is turned on or off).

• Command accounting: Command accounting provides information about the EXEC shell commands for a specified privilege level that are being executed on a network access server. Each command accounting record includes a list of the commands executed for that privilege level, as well as the date and time each command was executed, and the user who executed it.

• Resource accounting: The Cisco implementation of AAA accounting provides start and stop record support for calls that have passed user authentication. The additional feature of generating stop records for calls that fail to authenticate as part of user authentication is also supported. Such records are necessary for users employing accounting records to manage and monitor their networks.

Accounting Example

Back once again to our sample network, you can now use AAA accounting to perform one of the previously mentioned types of accounting. In this example, you pick up after authentication and authorization have taken place. Here resource accounting performs start stop accounting for FTP on the network. See Figure 1-3.

Figure 1-3. Basic Accounting of Resources

In this example, the following process is performed. Note that once again authentication must take place.

Step 1. After a user has been authenticated, the AAA accounting process on the AAA client generates a start message to signify the beginning of the session.

Step 2. When the user finishes his session and disconnects, a stop message is sent by the AAA client to signify the end of the session.

Again, a method list determines what type of accounting is to be performed.

Now that you have the core knowledge of the AAA process, there is still another element of AAA that needs to be addressed. That element is the actual communication protocol between the AAA server and the AAA client. That communication can be done using either RADIUS or TACACS+. The remainder of this chapter explains these protocols and how they differ.

Overview of RADIUS

RADIUS is a protocol that supports each of the three modules of AAA. Cisco Systems introduced support for RADIUS in Cisco IOS Software Release 11.1 and it has gained more and more support over the years. The RADIUS authentication protocol is documented separately from the accounting protocol; however, the two can be used together.

RADIUS was developed by Livingston Enterprises, Inc. Even though Livingston is no longer around, after being subject to acquisition, RADIUS has lasted and is covered in RFC 2865 as an open standard, which differs from its alternative, the TACACS+ protocol that is implemented by Cisco. RADIUS is an IP-based protocol that uses UDP as its transport, an AAA client, and an AAA server.

Imagine a user attempting to access a resource that requires AAA authentication. The device that is configured to authenticate the user is the AAA client. This client then prompts the user for credentials, sends those credentials to the AAA server, and waits for a response, PASS/FAIL, from the AAA server. The AAA server returns a result to the AAA client based on the compared credentials in a local or external database. In addition, the AAA server might return other attributes to the AAA client, which might include access-control filters, locks to a group, and so on. This information that the AAA server returns to the client can be located on the AAA server or on an external device that the server communicates with directly, such as LDAP, Active Directory, Token Card Servers, and so on. When this is the case, the requesting user does not have any knowledge of the communication that is conveyed between the AAA client and the AAA server. While the client is using some network protocol such as TCP to access the resource that it is being authenticated for, the communication between the AAA client and the AAA server is sent via RADIUS.

Additionally, RADIUS performs authentication and authorization at the same time and accounting separately, unlike the alternative TACACS+, which separates each process.

RADIUS in Detail

RADIUS is an Internet Engineering Task Force (IETF) standard that is used for AAA. It is also a client/server model. This means the AAA client sends user information to the AAA server, in this case via the RADIUS protocol, and the RADIUS server responds with all the information that is needed for the AAA client to provide connectivity and service to the end user. The AAA client acts in response to the reply it receives from the RADIUS server.

For network authentication, a shared secret key authenticates and encrypts certain parts of the payload between the AAA/RADIUS server and the AAA client. The shared secret key is never actually sent across the wire, so the integrity of the key is maintained.

When RADIUS authenticates users, numerous authentication methods can be used. RADIUS supports authentication via Point-to-Point Protocol Challenge Handshake Authentication Protocol (PPP CHAP) and PPP Password Authentication Protocol (PAP), as well as others.

In addition to these features, RADIUS is an extensible protocol that provides vendors with the capability to add new attribute values without creating a problem for existing attribute values.

A major difference between TACACS+ and RADIUS is that RADIUS does not separate authentication and authorization. RADIUS also provides for better accounting. In this section, you see the operation and functionality of RADIUS.

RADIUS operates under the UDP protocol. RADIUS uses ports 1645 and 1812 for authentication and 1646 and 1813 for accounting. The ports 1812 and 1813 are seen in newer RADIUS implementations. The use of RADIUS port 1645 in early implementations conflicts with the datametrics service. Therefore, the officially assigned ports are 1812 and 1813.

Generally, the RADIUS protocol is considered a connectionless service. Issues related to server availability, retransmission, and timeouts are handled by the RADIUS-enabled devices rather than the transmission protocol.

RADIUS Operation

The following is the process used in a RADIUS-managed login:

Step 1. A user login generates a query (Access-Request) from the AAA client to the RADIUS server.

Step 2. A corresponding response (Access-Challenge, Access-Accept, or Access-Reject) is returned by the server.

The Access-Request packet contains the username, encrypted password, IP address of the AAA client, and port. The format of the request also provides information on the type of session that the user wants to initiate. Optionally, if the RADIUS server needs more information, it can send an Access-Challenge.

Figure 1-4 shows the format of the RADIUS packet.

Figure 1-4. RADIUS Packet Format

Each RADIUS packet contains the following information:

• Code: The code field is one octet; it identifies one of the following types of RADIUS packets:

• Access-Request (1)

• Access-Accept (2)

• Access-Reject (3)

• Accounting-Request (4)

• Accounting-Response (5)

• Access-Challenge (11)

• Status-Server (12)

• Status-Client (13)

• Reserved (255)

• Identifier: The identifier field is one octet; it helps the RADIUS server match requests and responses and detect duplicate requests.

• Length: The length field is two octets; it specifies the length of the entire packet.

• Request Authenticator: The authenticator field is 16 octets. The most significant octet is transmitted first; it authenticates the reply from the RADIUS server. Two types of authenticators are as follows:

• Request-Authenticator: Available in Access-Request and Accounting-Request packets.

• Response-Authenticator: Available in Access-Accept, Access-Reject, Access-Challenge and Accounting-Response packets.

The attributes that are seen in Figure 1-4 are RADIUS AV pairs.

RADIUS Encryption

Encryption in RADIUS differs from that of TACACS+ because RADIUS encrypts only the password and the rest is sent in clear text.

The process of encrypting the password in RADIUS is as follows:

Step 1. A RADIUS packet includes an Authenticator field, as seen in Figure 1-4. This is a field that contains a 16-octet random number called the Request Authenticator.

Step 2. The Request Authenticator is combined with the preshared key value and runs through an MD5 hash algorithm. This derives a 16-octet hash. For this example, this is called HASH_A. Therefore, HASH_A is equal to the MD5 request authentication plus the preshared key.

Step 3. The user-provided password is padded in the message with a null value so that it reaches a 16-octet value.

Step 4. HASH_A is then XORed with the padded password from step 3, and that generates the cipher text that is transmitted to the AAA server running RADIUS.

Step 5. The AAA server calculates HASH_A on its own and XORs it with the received cipher text to get the padded user-provided password back to clear text.

RADIUS Authentication and Authorization

When an AAA server running RADIUS receives the Access-Request from the AAA client, it searches its configured databases for the username listed. If the username does not exist in the database, either a default profile is loaded or the RADIUS server immediately sends an Access-Reject message. This Access-Reject message can be accompanied by an optional text message, which could indicate the reason for the refusal.

If the username is found and the password is correct, the RADIUS server returns an Access-Accept response, including a list of AV pairs that describe the parameters to be used for this session. Typical parameters include service type (shell or framed), protocol type, IP address to assign the user (static or dynamic), access list to apply, or a static route to install in the AAA client’s routing table. The configuration information in the RADIUS server defines what is installed on the AAA client.

Optionally, the AAA server can send an Access-Challenge request to the AAA client to request a new password.

Figure 1-5 demonstrates a RADIUS exchange between an AAA client and AAA server.

Figure 1-5. A RADIUS Exchange

Authorization within RADIUS is done in conjunction with authentication. As a server returns an Access-Accept message, it also includes the list of AV pairs that the user is authorized for.

RADIUS Accounting

RADIUS accounting is performed by sending messages at the start and the stop of a session. These messages include information about the session. Information that might be included includes time, packets, bytes, and so on. These messages are sent using UDP port 1813. The accounting process for RADIUS is seen in RFC 2866. The messages sent between the AAA server and the AAA client are Accounting-Request and Accounting-Response. Figure 1-6 illustrates the basic process of RADIUS accounting.

Figure 1-6. RADIUS Accounting

During this process, the accounting information is also sent via AV pairs. You can find a list of RADIUS AV pairs in the Cisco.com document, RADIUS Attributes Overview and RADIUS IETF Attributes at http://www.cisco.com/en/US/docs/ios/sec_user_services/configuration/guide/sec_rad_ov_ietf_attr_ps6441_TSD_Products_Configuration_Guide_Chapter.html.

Overview of TACACS+

TACACS+ is a relatively recent protocol providing detailed accounting information and flexible administrative control over authentication and authorization processes. TACACS+ is facilitated through AAA and can be enabled only through AAA commands. In a situation where TACACS+ is used, a server runs the TACACS+ daemon and uses this to communicate and build packets destined for AAA clients. Again, TACACS+ is a Cisco-proprietary implementation. It is however, described in Internet Draft versions 1.77 and 1.78. TACACS+ uses the TCP protocol to provide reliable delivery of AAA requests. A shared secret key is also used between the AAA client and the AAA server running the TACACS+ protocol. Each portion of AAA is performed separately with TACACS+. Each one of these services, authentication, authorization, or accounting, can be tied to its own database on the AAA server to take advantage of other services available on that server or on the network, depending on the capabilities of the daemon.

TACACS+ is the result of the evolution of TACACS and extended TACACS (XTACACS). Cisco IOS supports all three of these protocols. Note the following details:

TACACS is an older access protocol, incompatible with the newer TACACS+ protocol. It provides password checking and authentication, and notification of user actions for security and accounting purposes. TACACS uses User Datagram Protocol (UDP) as its communication protocol.

XTACACS is an extension to the older TACACS protocol, supplying additional functionality to TACACS. XTACACS provides information about protocol translator and router use. This information is used in UNIX auditing trails and accounting files. XTACACS is incompatible with TACACS+. XTACACS also uses UDP.

TACACS+ in Detail

This section provides information about the architecture of TACACS+. TACACS+ performs reliable communication between the AAA server and AAA client. This communication, as well as the TACACS+ format, is reviewed in the following sections. In addition to this reliable format, TACACS+ optionally performs encryption and authentication of the entire message between the AAA server and AAA client. Although it’s not recommended, you could have a blank secret in which the payload would not be encrypted. Finally, this section wraps up with the actual operation of the protocol.

TACACS+ Communication

TACACS+ communication between the network access server (NAS) and AAA client is based on TCP and provides a reliable delivery mechanism to AAA messaging. TACACS+ uses TCP port 49 and creates a session to facilitate the messaging in an AAA exchange. Many benefits exist in using TCP for session control in TACACS+. Among these benefits is the fact that TACACS+ uses TCP to provide an acknowledgment of requests made by a NAS or an AAA client.

In addition to the acknowledgments provided within TCP, TACACS+ also has the capability, through inherent functionality of TCP, to adapt to congestion and bandwidth. An example of this functionality is the utilization of TCP windowing.

TACACS+ Format and Header Values

The TACACS+ ID defines a 12-byte header that appears in all TACACS+ packets. This header is always sent in clear text format. The following defines the TACACS+ ID fields:

• Major_version: This is the major version number of TACACS+. The value appears in the header as TAC_PLUS_MAJOR_VER=0xc.

• Minor_version: This field provides the revision number for the TACACS+ protocol. It also provides for backward compatibility of the protocol. A default value, as well as a version one, is defined for some commands. These values appear in the TACACS+ header as TAC_PLUS_MINOR_VER_DEFAULT=0x0 and TAC_PLUS_MINOR_VER_ONE=0x1. Should an AAA server running the TACACS+ daemon receive a TACACS+ packet defining a minor version other than one of the ones just listed, it sends an error status back and sets the minor_version to the closest version supported.

• Type: This distinguishes the packet type. Only certain types are legal. The legal packet types are as follows:

TAC_PLUS_AUTHEN=0x01—This is the packet type that signifies authentication.

TAC_PLUS_AUTHOR-0x02—This is the packet type that signifies authorization.

TAC_PLUS_ACCT=0x03—This is the packet type that signifies accounting.

• Seq_no: This determines the sequence number for the current session. TACACS+ has the capability to perform multiple TACACS+ sessions or to use one TACACS+ session per AAA client. The beginning packet of a session is identified by the sequence number 1. All subsequent packets are an increment from that initial number. Because the AAA client sends the first packet to the AAA server running the TACACS+ daemon, it is always the number 1, and all subsequent packets from the AAA client are identified with odd sequence numbers. In addition to this sequencing scheme, the highest sequence number that can be reached is 28-1. After this value is reached, the session that is established between the AAA client and the AAA server is reset, and a new session is started. When the session restarts, it begins, once again, with a sequence number of 1.

• Flags: In this section, the field can contain various flags. These flags can be TAC_PLUS_UNENCRYPTED_FLAG and TAC_PLUS_SINGLE_CONNECT_FLAG. The TAC_PLUS_UNENCRYPTED_FLAG flag specifies whether encryption is being performed on the body of the TACACS+ packet. If this flag is set, meaning that the value is set to 1, encryption is not being performed and likewise, if the value of this flag is set to 0, the packet is, in fact, being encrypted. The ability to disable TACACS+ encryption should be used primarily for debugging purposes. This functionality is nice when you need to see all the information in the body of the packet. Keep in mind that the header is always sent clear text. The TAC_PLUS_SINGLE_CONNECT_FLAG determines whether multiplexing multiple TACACS+ sessions over one TCP session is supported. This is determined in the first two TACACS+ messages of a session. When determined, this does not change. It is important to note here that multiple versions of IOS don’t support that bit correctly; that is, they try to do single-connect and don’t set this bit when they should have. ACS works around this by basically following the TCP connection, not this bit, so if an AAA client keeps its TCP connection open and keeps sending new requests on it, that is single connect more, ACS will stay connected with it and work, even if the single connect bit is not set on the device.

• Session_id: This is a random value that designates the current session between the AAA client and the AAA server running the TACACS+ daemon. This value remains the same for the duration of a session.

• Length: This field states the total length of the TACACS+ packet, not to include the 12-byte header.

Encrypting TACACS+

One feature that provides more security under TACACS+, as opposed to its alternative RADIUS, is the encryption of the entire packet. This encryption is sent between the AAA client and the AAA server running the TACACS+ daemon. This is not to be confused with encryption of user data. This is not an encryption such as 3DES-IPsec or RSA encryption, but is rather a combination of a hashing algorithm and an XOR function. TACACS+ uses MD5 to hash using a secret key provided on both ends.

The process of TACACS+ encryption is as follows:

Step 1. Information is taken from the packet header, and the preshared key calculates a series of hashes. The first is a hash that is calculated on a concatenation of the session_id, the version, the seq_no, and the preshared key value. Each hash created has the previous hash in it as well. This is done a number of times that is dependent on the particular implementation of TACACS+.

Step 2. The calculated hash is concatenated and then truncated to the length of the data being encrypted. Each hash has the previous hash concatenated to its input values. The result is called the pseudo_pad.

Step 3. The cipher text is produced by doing a bytewise XOR on the pseudo_pad with the data that is being encrypted.

Step 4. The receiving device uses its preshared key to calculate the pseudo_pad, and then an XOR of the newly created pseudo_pad results in the original data in clear text.

TACACS+ Operation

Three possible activities can be performed during TACACS+ operation:

• The first operation performed is authentication. This is done to clearly identify the user.

• The second operation is authorization and is possible only after a user has been identified. Therefore, you must authenticate prior to authorizing.

• The third operation is accounting. The accounting process keeps track of actions performed.

• The three processes are each independent of the other. Figure 1-7 shows one possible instance of the messaging that is involved with TACACS+. This messaging process is discussed in the sections that follow.

Figure 1-7. TACACS+ Messaging

The section that follows covers the authentication portion of TACACS+.

TACACS+ and Authentication

When authentication is performed in TACACS+, three distinct packet exchanges take place. The three types of packets are as follows:

• START: This packet is used initially when the user attempts to connect.

• REPLY: Sent by the AAA server during the authentication process.

• CONTINUE: Used by the AAA client to return the username and password to the AAA server.

When a user initiates a connection which requires authentication, the following process occurs:

Step 1. The AAA client receives the connection request from the user.

Step 2. The first packet type, START, is sent to the AAA server that is running the TACACS+ daemon. This START message contains information about the type of authentication.

Step 3. The TACACS+ server then sends the REPLY packet back to the AAA client. At this point, the server requests the username.

Step 4. The AAA client sends a CONTINUE packet to the TACACS+ server with the username provided by the user.

Step 5. The TACACS+ server then sends the REPLY packet back to the AAA client to ask the client to get the password.

Step 6. The AAA client sends a CONTINUE packet to the TACACS+ server with the password provided by the user.

Step 7. The TACACS+ server then sends the REPLY packet back to the AAA client to indicate a pass/fail of authentication. The possible returned values can be these:

• ACCEPT: The user is authenticated and service can begin. If the NAS is configured to require authorization, authorization begins at this time.

• REJECT: The user has failed to authenticate. The user can be denied further access, placed in an “auth-fail” vlan, or possibly prompted to retry the login sequence, depending on the TACACS+ daemon.

• ERROR: An error occurred at some time during authentication. This can be either at the daemon or in the network connection between the daemon and the NAS. If an ERROR response is received, the NAS typically tries to use an alternative method for authenticating the user.

• CONTINUE: The user is prompted for additional authentication information.

TACACS+ and Authorization

In the previous section, you learned the authentication process of TACACS+. This section discusses the authorization process.

To facilitate authorization in TACACS+, two message types are used. The first message is an authorization REQUEST, and the second is the authorization RESPONSE. The REQUEST sources from the AAA client, and the RESPONSE sources from the AAA server.

Figure 1-8 shows a basic authorization attempt.

Figure 1-8. Simple TACACS+ Authorization

The RESPONSE message (in step 3 in Figure 1-8) contains one of the following replies:

A FAIL response from the server indicates that the services requested for authorization are not granted.

If the server responds with a PASS_ADD, the request is authorized and the information returned in the RESPONSE is used in addition to the requested information. If no additional arguments are returned by the AAA server in the RESPONSE, the request is authorized.

In some cases, a PASS_REPL might be returned to the AAA client. In this case, the server is choosing to ignore the REQUEST and is replacing it with the information returned in the RESPONSE.

If the status is set to FOLLOW, this indicates that the AAA server that is sending the RESPONSE wants to have the authorization take place on another server, and this server information is listed in the RESPONSE packet. The AAA client has the option of using this server or simply can treat it as a FAIL.

If the status returned is ERROR, this indicates an error on the AAA server. This is commonly a preshared key mismatch; however, it can be a number of issues and further troubleshooting needs to take place.

In authorization, Attribute-Values (AV) can determine authorized services. You can find more information about TACACS+ AV pairs in the Cisco.com document, TACACS+ Attribute-Value Pairs at http://www.cisco.com/en/US/docs/ios/sec_user_services/configuration/guide/sec_tacacs_attr_vp_ps6441_TSD_Products_Configuration_Guide_Chapter.html.

TACACS+ Accounting

The functionality of accounting in TACACS+ is similar to that of authorization. Accounting takes place by sending a record to the AAA server. Each of these records includes an AV pair for accounting. The three types of records that can be sent to the AAA server are as follows:

• The Start record indicates when a service begins and contains the information that was included in the authorization process, as well as information specific to the account.

• A Stop record indicates when a service is about to stop or is terminated and includes information that was included in the authorization process, as well as information specific to the account.

• A Continue record is also called a Watchdog or UPDATE record. This is sent when a service is still in progress and allows the AAA client to provide updated information to the AAA server. As seen in the previous records, this also includes information that was included in the authorization process, as well as information specific to the account.

Accounting also uses the two message types that authorization uses, a REQUEST and a RESPONSE. The AAA server has the capability to send the following in a RESPONSE:

• SUCCESS indicates that the server received the record that was sent by the AAA client.

• ERROR indicates that the server failed to commit the record to its database.

• FOLLOW is similar to that of a FOLLOW in authorization. This indicates that the server wants the AAA client to send the record to another AAA server, and the AAA server information is included in the RESPONSE.

Figure 1-9 shows a basic example of the accounting process between the AAA client and the AAA server.

Figure 1-9. Basic Accounting

Summary

AAA is a framework for authentication, authorization, and accounting in a Cisco environment. To perform these processes, a Cisco device uses a method list, along with other configuration tasks to designate the server and protocol. At this point, you should have a basic understanding of what the AAA framework is, what it provides in your network, and the most basic process of configuration.

The TACACS+ and RADIUS protocols are used to communicate between the AAA server and the AAA client.

Now that you have had an opportunity to explore the AAA framework and protocols involved it’s time to begin working with the devices that make this possible. In Chapter 2, “Cisco Secure ACS,” you will take a look at two versions of Cisco Secure ACS, version 4.2 and version 5.1. In this chapter you will get a great comparison of the version that possibly has the largest install base along with the version being offered by Cisco at the time this book was being written.