AAA combines three independent security functions in a modular fashion that allows you to configure access control to your network devices, such as routers and switches. The three modules you will be concerned with in this article are as follows:

• Authentication Provides the methods you will use to identify your users before allowing them access to your network services. These methods include challenge and response, login and password dialog, encryption, and messaging support.

• Authorization Provides the methods you will use for remote access control, such as per-user account list and profile, support of IP and Telnet, one-time authorization or authorization for each service, and user group support.

• Accounting Provides the method you will use to collect and send security server information. You may use this information for auditing, billing, or reporting.

These modules are discussed further in the following sections.

Authentication

Authentication is the method used to identify your user before he or she is allowed access to your network and its services. A simple way of looking at configuring AAA authentication is defining a named list consisting of the authentication methods you want and then applying your defined list to your identified interface(s). You use the method list to define the types of authentication you want to be performed and the sequence in which you want them to be performed. With one exception, the method list named "default," you must apply the method list to a specific interface before any of your defined authentication methods are used. The default method list is automatically applied to any interface you have not applied a method list to. You must define all authentication methods, with the exception of local, line password, and enable authentication, through AAA. When you choose to implement authorization, your users must be authenticated before any authorization can take place.

Authorization

Authorization is designed to work by assembling a set of attributes you define to determine if a user is authorized to perform a certain task. Your defined attributes are compared to the information stored in the database for a given user. The result (the user's capabilities and restrictions) is returned to AAA. You can define the database locally on the network device or host it remotely on a RADIUS or TACACS+ security server, such as Cisco Secure Access Control Server (ACS). TACACS+ and RADIUS security servers authorize your users for their specific rights by using attribute-value (AV) pairs, which associate their rights with the appropriate user. All authorization methods must be defined through AAA. Just like authentication, you configure AAA authorization through the use of a named list of authorization methods and then apply your defined list to your specific interface(s).

Accounting

Accounting lets you track the services your users are accessing, as well as the amount of network resources they are consuming. AAA accounting accomplishes this by reporting your user's activity to the RADIUS or TACACS+ security server in the form of accounting records. These accounting records are comprised of accounting AV pairs. They are stored on the ACS for future analysis of network management, client billing, and/or auditing. You must define all the accounting methods through AAA. Much like the previous AAA modules, you configure AAA accounting through the use of named lists defining your accounting methods and then apply that list to your specified interface(s).

AAA Protocols

AAA uses two major security server protocolsTACACS+ and RADIUS. You can use either of these protocols to authenticate a large number of your users, because each creates a database of usernames and passwords. Both protocols share many features, because Cisco Systems modeled the TACACS+ architecture after the existing RADIUS standard. You can implement a TACACS+ or RADIUS server on a UNIX platform or Windows platform.

RADIUS is covered in the following RFCs:

• RFC 2138, Remote Authentication Dial In User Service (RADIUS)

• RFC 2139, RADIUS Accounting

• RFC 2865, Remote Authentication Dial In User Service (RADIUS)

• RFC 2866, RADIUS Accounting

• RFC 2867, RADIUS Accounting Modifications for Tunnel Protocol Support

• RFC 2868, RADIUS Attributes for Tunnel Protocol Support

• RFC 2869, RADIUS Extensions

TACACS+ is covered by the following Internet Draft and RFC:

• The TACACS+ Protocol Version 1.78 (draft-grant-tacacs-02.txt)

• RFC 1492, An Access Control Protocol, Sometimes Called TACACS

AAA Transport Protocols

Just like any packet that travels across your IP network, both TACACS+ and RADIUS use the TCP/IP stack. This is also one area in which they differ: RADIUS uses the UDP protocol for communications between the client and the security server, whereas TACACS+ uses the TCP protocol. TACACS+ operates over TCP port 49, and RADIUS operates over UDP port 1812 for authentication and UDP port 1813 for accounting. In some RADIUS implementations, you might see RADIUS operate over port 1645 for authentication and port 1646 for accounting.

Packet Encryption

One other area in which RADIUS and TACACS+ differ is their use of encryption. RADIUS encrypts only the user password in a client-to-server access request packet. Other items in the packet, such as username, authorized services, and accounting, are sent across the network in clear text.

TACACS+ encrypts the entire packet to the server with the exception of the unencrypted TACACS+ header. This unencrypted header contains a field specifying whether that packet's payload is encrypted.

AAA Method Lists

You create a method list by defining a sequential list of authentication methods that you want to use to authenticate a user. Method lists let you define a backup authentication system for authentication in case of a failure by configuring one or more security protocols to be used for authentication. Your network devices will use the first method you list to authenticate users; in the case of a failure, your network devices will use the next authentication method defined in the method list. This process continues until either your user is authenticated through the successful communication with a listed authentication method or the authentication method list is exhausted, in which case authentication fails. Authentication with the next defined authentication method is tried only if there is no response from the previous authentication method.