AUTHENTICATION, AUTHORIZATION, AND ACCOUNTING

The framework for user-based security is called authentication, authorization, and accounting (AAA), pronounced triple-a. The AAA framework is designed to be consistent and modular in order to give network teams flexibility in implementing the enterprise's network security policy.

Note 

Network security systems, like CiscoSecure Access Control Server (ACS), control access to LAN segments, lines, and network applications such as HTTP and FTP. Network access devices-usually access servers and access routers-control access to these network-based services, but an additional layer of security is sometimes configured into the server platform once it is reached. For example, an IBM mainframe will enforce security policies using its own mechanisms. Security for computer platforms and major application software packages is still performed using self-contained security systems resident in the application server, in addition to the network access device security measures covered in this chapter.

Overview of the AAA Model

AAA's purpose is to control who is allowed access to network devices and what services they are allowed to use once they have access. Here is a brief description of the AAA model's three functional areas:

• Authentication Validates the user's identity as authentic before granting the login

• Authorization Grants the user the privilege to access networks and commands

• Accounting Collects data to track usage patterns by individual user, service, host, time of day, day of week, and so on

Thankfully, the acronym makers put the three functions in sequential order, making the AAA concept easier to pick up: first, you're allowed to log in (your identity is authenticated); then you have certain privileges to use once you're in (you have predetermined authorizations); and, finally, a running history is kept on what you do while logged in (the network team keeps an account of what you do).

The philosophy is to let network teams enforce security policy on a granular basis. Most AAA parameters can be put into effect per LAN segment, per line (user), and per protocol-usually IP.

AAA is a clearly defined security implementation framework that everybody can understand. The architecture is defined down to the command level. Indeed, the AAA concepts are actual IOS commands. Starting an AAA process on a Cisco device involves using the aaa prefix followed by one of the three root functions, such as aaa authentication. A whole AAA command line might read aaa authentication ppp RemoteWorkers TACACS+ local, for example. The purpose of AAA is to provide the client-side command structure on which CiscoSecure relies.

The following explains how to enable AAA on a Cisco router or access server.

1. Enable AAA by using the aaa new-model global configuration command.

2. If you decide to use a separate security server, configure security protocol parameters, such as RADIUS, TACACS+, or Kerberos.

3. Define the method lists for authentication by using an AAA authentication command.

4. Apply the method lists to a particular interface or line, if required.

5. Optionally, you can configure authorization using the aaa authorization command.

6. Optionally, you can configure accounting using the aaa accounting command.

AAA Modularity

A security policy is a set of principles and rules adopted by an enterprise to protect system resources, confidential records, and intellectual property. It's the network manager's responsibility to implement and enforce the policy, but in the real world, security policy can get dragged down into the mire of office politics, budget constraints, and impatience. An end-user manager can have a lot of clout as to how the policy will be con ducted on his or her turf. After all, the company, not the IT department, funds the network. Consequently, there can be a lot of variance among security policies-even within an enterprise's internetwork.

This means that security policies must be highly adaptable. CiscoSecure ACS tries to satisfy this need with modularity-the ability to separately apply security functions by secured entity, independent of how they are applied to other resources. The AAA architecture gives you the option to implement any of the three functions independent of the other two. This includes whether they're activated on a device, which security protocol is used, and what security server or user database is accessed.

Authentication Controls The aaa authentication command validates a user's identity at login. But once you're authenticated, exactly what can you access? That depends on the type of access being made:

• If you're a network administrator logging into a switch to tweak its config file, the authentication gets you into that switch's IOS command prompt.

• If you're an employee sitting inside the enterprise and you were authenticated by a router, you get into a protected host to run Windows-or browser-based internetwork client-server applications.

• If you're a telecommuter and an access server authenticated you, you're admitted to your enterprise's internetwork to run the same client-server applications.

• If you dialed into the Internet from home, as a member of the general public, you were authenticated by one of your ISP's many access servers, and you enter the World Wide Web.

Authentication must protect three destination environments: the Internet, the internetwork, and, most of all, the internal operating system of the devices over which internetworks run. Figure 6-3 illustrates access types and destination environments.

Figure 6-3: User authentication takes place in four scenarios that open into three worlds

The scenario of the network administrator logging into IOS devices is unique. In Cisco internetworks, that type of access is usually authenticated using TACACS. Network administrators access a device's IOS environment in order to perform device maintenance tasks.

Users also require different dial-in services. Although almost everybody uses PPP nowadays, there still can be different requirements. Depending on the local network from which the call is made, different PPP services may be required, such as IP, IPX, NetBEUI, or just a plain terminal connection.

Whatever the issues may be, different requirements often call for a variety of authentication methods to be used in the same internetwork. CiscoSecure ACS lets the network manager employ any of the major dial-in protocols and authentication techniques. In addition, it supports the ability to apply these different tools by network interface or line-even on the same device.

Authorization Controls AAA authorization limits services to the user. In other words, if authorization has been activated on a secured entity using the aaa authorization command, users must be explicitly granted access to it.

The person's user profile is usually stored in the security server and sometimes also in the device's local user database. When the administrator logs into the device and his or her user profile is checked, the device configures the authorizations to know what commands to allow the administrator to use during that session. Commands can be authorized by IOS command mode (the MyRouter: versus MyRouter# prompts) or by specific commands within a mode. Figure 6-4 lays out some of the various forms authorizations can take.

Figure 6-4: Authorizations can be enforced by network, command mode, and even by command

Authorization can be more complicated than authentication. After you've been authenticated, the security server must supply the access device configuration information specific to the user-for example, which networks the user may access, which application traffic may be run, which commands are okay to use, and so on. Without centralized maintenance of authorization information, it wouldn't be practical to assign authorizations by user. (It's hard enough just to keep user names and passwords up-to-date.)

Accounting Controls Accounting doesn't permit or deny anything, but instead keeps a running record of what users do. AAA accounting is a background process that tracks the person's logins and network use. Figure 6-5 shows how AAA security accounting tracks resource usage.

Figure 6-5: AAA accounting is a background process that tracks a user's network activity

AAA accounting reflects events as they take place in entering systems and using services. Thus, the accounting commands more or less mirror the others. For example, accounting tasks can be enabled by system, command mode, network device interface, protocol, and connection-just like authorization commands.

Note 

By default, AAA defines IOS as having two command modes: the user EXEC mode (sometimes also called Shell) and the privileged EXEC modes. The IOS level command can be used to further divide things up into 16 command levels (numbered 0–15), so access to commands can be authorized on a more fine-grained basis.

Trends Leading to Client-Server Security Systems

As with most network control systems, AAA uses the client-server model to manage security. In other words, there is a central security server holding the user profile information used by client access devices to enforce security. When a user makes a request to connect to a network, line, or service, the client device queries the server to check if it's okay. Centralization is necessary, because it's no longer feasible to administer security one access device at a time; there are simply too many of them to keep track of.

In the 1970s, a natural by-product of remote users dialing into central mainframes was that user security profiles (accounts, passwords, and authorizations) were stored right there on the same computer where all the services sat. This made it easy for the security system to check on user permissions. Then, in the 1980s, departmental minicomputers became popular, spreading computers out into the organization. Terminal servers were invented to provide the additional entry points the distributed topologies required, but user databases were now spread across many access devices-making it much tougher to maintain the security system. By the time IP-based networking took off, it became apparent that security information had to be centralized. Figure 6-6 depicts this trend.

Figure 6-6: Security systems have evolved along with the computing industry

The rise of internetworking demands that an enterprise offer dial-in access throughout the organization. Doing so presents problems for enforcing consistent security controls across so many access servers. The AAA architecture is Cisco's game plan for meeting these challenges. Additionally, TACACS+ and RADIUS servers are capable of integrating with such services as Microsoft's Active Directory, allowing for centralization of AAA information.

AAA's Two Security Protocols: TACACS+ and RADIUS

It's possible to use AAA security on a stand-alone basis, with no central security database. In the real world, few do this because it would require the extra effort of maintaining security parameters on a device-by-device basis-a labor-intensive and mistake-prone proposition. IOS supports stand-alone security because, in some cases, a security server is unavailable-for example, in a very small internetwork or during the period of time when a security server is being implemented but is still not operable.

AAA configures access devices as clients. Client devices include access servers, routers, switches, and firewalls. The clients query one or more security servers to check whether user connections are permitted. To do this, a protocol is needed to specify rules and conventions to govern the exchange of information. AAA security can use two protocols to handle client-server security configurations:

• RADIUS A security protocol used mainly for authentication. RADIUS stands for Remote Authentication Dial-in User Service. RADIUS is an industry standard under the auspices of the IETF (Internet Engineering Task Force).

• TACACS+ A proprietary Cisco protocol that is largely the equivalent of RADIUS, but with stronger integration of authorization and accounting with authentication. TACACS stands for Terminal Access Controller Access Control System. Cisco has submitted TACACS+ to the IETF for consideration as a security protocol standard.

Note 

There is a third security protocol called Kerberos. Developed at MIT, Kerberos is an open standard for secret-key authentication that uses the Data Encryption Standard (DES) cryptographic algorithm. Several years ago, Microsoft, for example, integrated Kerberos into Windows 2000. Although more difficult to implement and administer, Kerberos is gaining in popularity in internetworks more sensitive to security. Its key benefits are that it can function in a multivendor network like RADIUS, but it doesn't transmit passwords over the network (it passes so-called tickets instead). IOS includes Kerberos commands in its AAA framework.

How AAA Works

AAA is the security infrastructure of IOS devices. AAA commands are located in the IOS privileged EXEC mode. Each client device is configured for security using the AAA commands from global configuration mode. Properly configured, the device can then make use of the CiscoSecure server using the TACACS+ or RADIUS security protocols-or both.

In fact, AAA commands can be used stand-alone to secure a device. In other words, the device can use a local user database stored in NVRAM on the device itself, instead of one on a RADIUS or TACACS+ server. However, this is rarely done, because it entails maintaining and monitoring user security data in hundreds, or even thousands, of device config files instead of in a single database.

TACACS+ and RADIUS are client-server network protocols used to implement client-server security over the network. In that sense, they are the equivalent of what SNMP is to network management.

A user database changes every time users are added or deleted, passwords are changed, or authorizations are modified. Separating the user database from device config files reduces the number of places updates must be made. Most internetworks use a primary server and one or two alternate security servers, leaving only a few places in which user profile databases need to be updated.

Ensuring that the user databases contain identical data is called database synchronization. This can be done automatically by configuring Replication Partners in CiscoSecure ACS. In the scenario with three security servers, the three user databases would be configured as replication partners, and the CiscoSecure ACS would automatically synchronize user profile records between the three on a daily basis.

In addition to the user profiles, the server can synchronize any of the following:

• User and group database

• Group database only

• Network Configuration Device tables

• Distribution table

• Interface configuration

• Interface security settings

• Password validation settings

• EAP-FAST master keys and policies

• CNAC policies

The AAA Approval Process

AAA works by compiling attributes that specify a user's permissions. In the AAA context, an attribute is a pointer to an entity (or object) to which the person may have access. For example, an authentication attribute might be a specific LAN segment to which the person is permitted access. An authorization attribute might be the limit on concurrent connections the person may have open at one time.

When a user attempts to connect to a secured service, the access device checks to see if the user has clearance per the security policy. It does so by sending a query to the server database to look for a match. The secured access device knows what to query for based on its config file parameter settings, and the query is used to verify that the user has permission to do whatever is being attempted.

Attribute-Value Pairs The query contains the attributes that are mandatory for the requested service, as defined in the access device's config file. The server processes the query by searching for the same attributes in the user's profile in the user database. The search is for so-called attribute-values. An attribute, called an attribute-value pair (or AV pair) in TACACS+ terminology, is a fancy term to describe the representation of a network entity that is secured.

For example, in someone's user profile, the password is an attribute, and the person's actual password, imreallyme, is the value paired with it. When the user enters the password, the access device handling the login first knows to check for a password, because to do so is set as a parameter in the device's config file. By checking the person's user profile, it looks for a match between the value entered into the password prompt and what's on file in the user database for the user name the person entered. Figure 6-7 shows the AAA procedure for handling a user's request for a connection.

Figure 6-7: User access requests are granted if attribute-values are matched in the user profilev

How AAA Handles Authentication Transactions When the connection is established, the access device contacts the security server and displays a user prompt. The user enters the information (usually just a user name and password), and the protocol (RADIUS or TACACS+) encrypts the packet and sends it to the server. The server decrypts the information, checks the user's profile, forms and encrypts the response, and returns the response to the access device.

The rules of AAA approval are fairly simple: If an ACCEPT is returned, the requested connection is made. If a REJECT is returned, the user's request-for-connection session is terminated. But if an ERROR is returned and the access device is configured for multiple security servers, the query is then forwarded to an alternate server. If that server also fails to return a response, the process continues until the query runs out of servers. At that point, if the access device has been configured with a second method, it will iterate through the process again, first trying for approval with a query to the primary security server, and so on. If the access device exhausts authentication methods, it terminates the user's request-for-connection session.

The CONTINUE response is another optional configuration parameter that prompts the user for additional information. The prompts can be anything the network administrator arbitrarily defines. For example, prompting users for their mother's maiden name is a common challenge.

Note 

A daemon (pronounced either with long e or long a) is a process that runs on a server to perform a predefined task, usually in response to some event. The term comes from Greek mythology, in which daemons were guardian spirits. Daemons are called system agents in Windows parlance. A TACACS+ daemon sits on the security server and fields authentication or authorization queries from client access devices. It does so by searching the user database for required AV pairs and returning the results to the client in TACACS+ packets.

Authorization Transactions If the user is authenticated, the daemon is contacted to check for authorization attributes on a case-by-case basis. Figure 6-8 depicts how authentication and authorization work together.

Figure 6-8: Once authenticated, a user's authorizations are cleared as needed

Authorization attributes can be issued for such services as connection type (login, PPP, and so on), IOS command modes (User EXEC or Privileged EXEC), and various connection parameters, including host IP addresses, user timeouts, access lists, and so on. Authorization is, by nature, more sophisticated than authentication. More information than just user name and password is involved, and the attributes have a state. For example, the Maximum-Time attribute requires the server to keep tabs on how long the user has been connected and to terminate the session when the value (number of seconds) for the user has been exceeded.

Authentication Protocols

CiscoSecure ACS supports a number of authentication mechanisms. Also called password configurations or password protocols, authentication protocols make sure you are who you say you are when logging into a system. Here are four major authentication mechanisms supported by AAA:

• ASCII American Standard Code for Information Interchange is the oldest authentication protocol. ASCII is a machine-independent technique for representing English characters, and has many other uses besides authentication. ASCII authentication requires the user to type a user name and password to be sent in clear text (that is, unencrypted) and matched with those in the user database stored in ASCII format.

• PAP Password Authentication Protocol is used to authenticate PPP connections. PAP passes passwords and other user information in clear text. You know PAP as a protocol that lets you store your user name and password in the dialog box so you don't have to type it during each login.

• CHAP Challenge Handshake Authentication Protocol provides the same functionality of PAP, but it is much more secure, since it avoids sending the password and other user information over the network to the security server. Figure 6-9 depicts how challenge-response works.

  
  Figure 6-9: CHAP authentication doesn't send the password over the network

• Token-Card This authentication technique uses one-time passwords. A token-card is an electronic device that's a bit larger than a credit card. The card is used to generate an encrypted password that must match one filed for the user in the token-card database residing on the security server. The encrypted password is good for only one use; thus the name token. Token-card authentication systems provide the best access security.

AAA also supports NASI (NetWare Asynchronous Services Interface), an authentication protocol built into Novell LANs. Another vendor-specific password protocol is ARAP (AppleTalk Remote Access Protocol), with a double challenge-response authentication mechanism that goes CHAP one better by making the security server authenticate itself to the client as well. In addition, there are subtle variations in how the PAP protocol works with Windows NT/2000/2003.

Security comes at a cost-mostly in the form of increased inconvenience to users, but there's also additional expense to deploy and administer security measures. For example, CHAP requires some extra hardware and expertise, and token-cards are cumbersome to deploy. Can you imagine the giant Internet service provider AOL mailing token-cards to every new user and administering a token database of one-time passwords? The added expense and logistical complexity of advanced authentication protocols have discouraged their adoption.

There are certainly reasons why PAP is no longer favored over EAP, CHAP, and MS-CHAP. Corporate internetworks are more likely to use CHAP, while token-cards are mainly used to protect high-security networks in the military, R&D, banking, or other security-conscious environments.

Methods and Types

Certain pieces must be put in place before security can be enforced. As you just saw, the access device must be configured to query one or more security servers for authentication and authorization, and the user database must have profiles containing attributes that define what the user is permitted to do on the network. But what exactly happens when the query hits the TACACS+ or RADIUS database? What steps are taken to verify the user's identity and figure out what services that person is permitted?

AAA command statements in an access device's config file tell the device what to do when a user tries to log in. The root AAA commands authentication, authorization, and accounting are used in conjunction with various keywords to code config file instructions on how connection attempts are to be handled. As mentioned earlier, these instruction parameters are modular in that they can be applied per user and per service. The instructions are implemented in the access device's config file using methods and types:

• A method is a prepackaged computer program that performs a specific function. For example, radius is a method to query a RADIUS server.

• A type is the entity to which the method applies. For example, a radius method is applied to a ppp type so that when a user attempts to make a connection using the PPP protocol, the access device queries its RADIUS server to authenticate the person's identity.

Because there are almost always multiple security parameters set for a device, AAA configurations are referred to as named method lists. They're called named methods because they are named by the administrator in the device config file and applied to one or more specific secured entity types. Figure 6-10 shows how named method lists and types work together to enforce security.

Figure 6-10: Named method lists enforce security policies in access device interfaces

Note 

There are unnamed methods in the form of the default method list. If an interface or line has no named method list configured, a default method list is automatically put into force for it. To have no AAA security, it must be explicitly configured this way by using the none method. The command would look like: aaa accounting none. Cisco makes it hard to have no security in force.

Named method lists are entered into the config file of the access device being secured-usually an access server or a router. IOS applies methods in the sequence in which they appear in the configuration, initially trying the first method and then turning to the following ones until an ACCEPT or REJECT is returned. Figure 6-11 explains a typical named method list.

Figure 6-11: The basic parts of a device security configuration model contain a number of settings

The last part of the AAA configuration in Figure 6-11 specifies lines because authentication deals with individual users. Traffic-based security can be applied on the interface level because the firewall or router monitors information in the header of each packet-a process that is done either to all or none of the packets passing through an interface. By contrast, user-based security controls individuals as they make a remote network connection through an access server or log into IOS inside a router or switch within the network. Each of these two scenarios involves using a line.

AAA Authentication Methods and Types AAA has several methods to authenticate user identity. Only one method may be used per user line (except when the Local method is configured as backup to one of the three client-server methods). Table 6-1 lists Cisco's authentication methods.

Table 6-1: Authentication Methods in IOS

IOS Command Keyword	AAA Authentication Method
Group RADIUS	Authenticates using the RADIUS protocol and user database.
Group TACACS+	Authenticates using the TACACS+ protocol and user database.
Group group name	Authenticates using a subset of RADIUS or TACACS+ servers for authentication as defined by the aaa group server radius or aaa group server tacacs+ command.
Krb5	Authenticates using the Kerberos 5 protocol and user database. (Note: Kerberos can only be used with the PAP password protocol.)
Krb5-telnet	Uses Kerberos 5 telnet authentication protocol when connecting using Telnet.
Local	Authenticates using a user database stored in memory in the access device, or for backup if the security server does not respond.
Line	Authenticates using the Line password for authentication.
Local-case	Authenticates using case-sensitive local user name authentication.
Cache group name	Authenticates using a cache server group.
Enable	Authenticates using Enable Secret passwords in the access device's config file.
None	Uses no authentication.

The list of AAA methods in Table 6-1 varies slightly according to the password mechanism being used. Remember that AAA is an architectural model that must be adapted to differences in the way other vendors design their products. For example, AAA supports Guest and Auth-Guest methods for the password protocol in Apple's ARAP.

It's possible to configure different authentication methods on different lines within the same access device. For example, you might want to configure PPP connections to query the user database on a RADIUS server, but to check the local user database for login connections made from the console or AUX ports.

Connection Types Because authentication is applied to user lines, named authentication methods are applied to connection types. A connection type is the communications protocol used to make a connection. To explain, remote connections to ISPs and internetworks nowadays are usually PPP connections. But when a network administrator logs into IOS in order to work on a device, that connection is through a Telnet session (if over the network) or through a terminal emulator (if over the console or AUX port). Table 6-2 explains the authentication types.

Table 6-2: Entity Types Secured by AAA Authentication Methods

IOS Command Keyword	AAA Authentication Type
Login	Line connections made to Ethernet or Token Ring network interfaces using Telnet, or to console or AUX ports using virtual terminal (VTY)
PPP	Dial-in line connections made to serial network interfaces using Point-toPoint Protocol
SLIP	Dial-in line connections made to serial network interfaces using Serial Line Internet Protocol
ARAP	Dial-in line connections made to serial network interfaces using AppleTalk Remote Access Protocol

The following example statement illustrates a serial interface on an access server being configured to use TACACS+ to authenticate persons making PPP network connections:

 MyAccessServer(config)# aaa new-model MyAccessServer(config)# aaa authentication ppp MyList tacacs+ local MyAccessServer(config)# interface serial0 MyAccessServer(config-if)# ppp authentication pap MyList MyAccessServer(config)# tacacs-server host 10.1.13.10 MyAccessServer(config)# tacacs-server key DoNotTell 

The aaa new-model command activates (enables) the AAA inside the device's IOS software. Then the statement specifies that a TACACS+ security protocol be used and that the local user database should be used if the TACACS+ server fails to respond. The interface serial0 command points the configuration to all lines on the access server's serial network interface named serial0. The ppp authentication pap MyList TACACS+ local command specifies that the PAP password protocol be used for PPP connections and applies the named method list MyList to be used as the test.

The next statement specifies that the TACACS+ server resides on the host computer at IP address 10.1.13.10. The next line specifies that the encryption key DoNotTell be used for all communications between the security server and the client access device being configured here. The shared encryption key also must be configured on the security server(s) with which the client access device will communicate.

Note 

Three types of protocols play a major role in AAA: dial-in protocols such as PPP, security protocols such as RADIUS, and password protocols such as CHAP. Dial-in protocols are network protocols that handle signals over phone lines, keeping the IP packets together between the access server and the remote user. Security protocols provide the client-server messaging system to the centralized user database. Password protocols are relatively simple mechanisms to deal with the person logging in. Some dial-in protocols incorporate their own password protocol-ARAP, for example.

AAA Authorization Methods and Types AAA has seven methods for authorization. There are actually eight, but the none method is a request not to do any authorization procedure. Table 6-3 explains the AAA authorization methods. Each method is a keyword for use as an argument with the root aaa authorization command. These, in turn, are applied to secured entity types.

Table 6-3: AAA's Eight Named Methods for User Authentication

IOS Command Keyword	AAA Authorization Method
Group TACACS+	Sends a message requesting authorization information from the TACACS+ server.
Group RADIUS	Sends a message requesting authorization information from the RADIUS server.
If-authenticated	Allows access to the requested function if the user has already been authenticated. ( If here is the word if, as in "depending on," not the mnemonic IOS uses for network interface in the config prompt.)
Local	Uses the local user database to execute the authorization program.
Krb5-instance	Uses an instance defined in the Kerberos instance map.
Cache group name	Authorizes using a cache server group.
Group group name	Authorizes using a subset of RADIUS or TACACS+ servers for accounting as defined by the server group groupname command.
None	Does not execute any authorization methods on this access device.

As mentioned, RADIUS and TACACS+ can coexist on the same access device. Depending on the connection being attempted and how the device is configured, the client will query either the RADIUS or the TACACS+ servers, which are separate user databases.

The if-authenticated command waives authorization if the user has already been authenticated elsewhere. This is important, because during a single session a user may make dozens of connections to entities secured by AAA authorization (such as IOS command modes), and it would be unwieldy for the client device to query the TACACS+ or RADIUS server each time.

Generally, a device's local user database contains only user names and passwords. Remember that network devices don't have hard disks, and they must store permanent information in NVRAM memory, already burdened with storing a boot image of IOS and even daily AAA accounting logs. For this reason, local user databases generally do not hold authorizations for users. Therefore, if a security server were unavailable when a user logged in, that person would likely be unable to access any services configured to require authorization. Figure 6-12 shows how a local user database coexists with the server database(s).

Figure 6-12: A user database can be stored in the access device's NVRAM for local use

If no authorization is to be executed on a secured entity, this should be explicitly configured by using the none command. Otherwise, the IOS software will automatically put the default authorization methods into force. The five types of secured objects to which AAA authorization methods can be applied are explained in Table 6-4.

Table 6-4: IOS's Five Authorization Types

Type	AAA Authorization Type
Network	Applies method to network-related service requests, including direct login connections (via console or AUX), Telnet connections (via IP or IPX), or dial-in connections (via PPP, SLIP, or ARAP).
Reverse Telnet	Applies method to Telnet sessions in which the user attempts to connect from the secured access device to another host-a common maneuver by a hacker who has broken into a network device.
EXEC	Applies method to sessions in the User EXEC command mode and can be applied by user, date, and start and stop times.
Commands	Applies method to restrict access to specific commands. Command methods must be applied to an IOS command-level group. There are two default groups: numbers 0 and 15 (user EXEC and privileged EXEC modes, respectively). The Command method can be applied by user, date, and start and stop times.
Configuration	Downloads the configuration from the AAA server.

The five authorization entity types can be broken down into two pairs:

• The EXEC and Command methods each deal with access to IOS commands.

• The Network and Reverse Access methods both deal with connections, but those which go in different directions.

On Cisco access devices, the aaa authorization config-commands command is enabled by default. That way, the device has security right out of the box, in case the administrator installs it without configuring security. The following example statement illustrates a router being configured to require authorization for any type of network connection. This would apply, for example, whether the connection was being made through a console TTY login, a Telnet VTY login, or a PPP dial-in login:

 MyRouter(config)# aaa new-model MyRouter(config)# aaa authorization network NetTeam group tacacs+ local 

The preceding command specifies that the TACACS+ security protocol be used to check users against the NetTeam named method list and to use the local user database for backup. By default, this authorization is applied to all network interfaces on the device (as opposed to authentication methods, which must be applied to specific lines).

But, as mentioned earlier, sometimes having authorizations stored on the device itself isn't practical. To accommodate this, the restriction could be loosened using the none command to allow a network connection if the TACACS+ server fails to respond:

 MyRouter(config)# aaa authorization network NetTeam group TACACS+ none 

In the preceding command, the user's identity must have already been authenticated with a password to get this far into the AAA configuration. The none command goes into effect only when the TACACS+ server fails to respond. The following code statement configures a somewhat more sophisticated authorization:

 MyRouter(config)# aaa authorization commands 15 SeniorTechs group TACACS+ MyRouter(config)# line vty 0 5 MyRouter(config-line)# authorization commands 15 SeniorTechs 

The preceding statement shows an example of configuration by line, as opposed to network interface. Here, the six virtual terminal (VTY) lines are secured. In this example, the named method list SeniorTechs is declared as necessary for an administrator to use IOS command level 15 in this device. We mentioned earlier that the IOS level command can be employed to authorize the use of a group of commands. By default, all Privileged EXEC mode commands are grouped into level 15, and all User EXEC mode commands are grouped into level 0. Therefore, the preceding code snippet specifies that only administrators with user profiles configured with the SeniorTechs attributes will be permitted to use the Privileged EXEC commands.

Accounting Methods and Types AAA accounting methods configure user activities to be tracked within a secured access device. Accounting methods gather data from TACACS+ and RADIUS packets and log it. Table 6-5 explains how the two work.

Table 6-5: How AAA Accounting Methods Work per Security Protocol

Command Keyword	AAA Accounting Method
TACACS+	Logs accounting information on TACACS+ in the CiscoSecure ACS database
RADIUS	Logs accounting information on RADIUS in the CiscoSecure ACS database

Notice that the only accounting methods are the security protocols themselves. This is because accounting data is, by default, collected for the entire device. The reason for the two methods is that the accounting data must travel either in TACACS+ or RADIUS packets to the server (AAA accounting isn't done without servers).

AAA has six secured accounting entity types, slightly different from those for authorization. Table 6-6 explains them.

Table 6-6: AAA Accounting Types That Track Asset Usage for Five Security Entity Types

Command Keyword	AAA Accounting Type
Network	Applies method to network connections, usually a PPP connection, but methods can also be named for logins, SLIP, or ARAP connections.
Auth-proxy	Provides information about all authenticated-proxy user events.
EXEC	Provides information on all User EXEC mode terminal sessions within the access device's IOS environment. EXEC accounting information can be collected by user, date, and start and stop times.
Commands	Provides information on any commands issued by users who are members of an IOS Privileged EXEC mode. Command accounting information can be collected by user, date, and start and stop times.
Connection	Provides information on all outbound connections attempted from the secured access device in sessions made using the Telnet, rlogin, TN270, PAD, and LAT terminal protocols.
System	Provides information about system-level events, such as reboots.

The system accounting keyword only collects a default set of variables. It cannot be configured to collect only certain events. The reason for this is that a system event simply happens-a user does not request permission to cause it. An example system event would be a network interface going down at 11:32:28 Tuesday, January 9, 2007. AAA accounting does not automatically associate the system event with a security transaction, but comparing accounting and authorization logs for that date and time would make it easy for a system administrator to figure out who the culprit was.

Like authorization, AAA accounting named method lists must be applied to all network interfaces they are meant to secure and then applied to an indicated accounting type. For example, the MyRouter(config)# aaa accounting network group group name TACACS+ command configures IOS to keep track of all SLIP and PPP connections made over a network interface that are authorized using TACACS+.

Accounting is a little more complicated in how it tracks requests, though. AAA accounting relies on so-called accounting notices to gather data. An accounting notice is a special packet notifying the accounting method of an event. This information is recorded in the accounting log file for upload to the appropriate security server. One of three AAA accounting keywords must be used to specify exactly when during the service request process the notices are to be sent. The terminology can get a bit confusing, but Figure 6-13 will help you visualize how the three work:

• Stop-only For minimal accounting. Have RADIUS or TACACS+ send a stop recording accounting data notice at the end of the requested service. Stop-only accounting is good only for tracking who went where. This is important information for security purposes.

• Start-stop For more accounting. Have RADIUS or TACACS+ send a start accounting notice at the beginning of the requested service and a stop accounting notice at the end of the service. Start-stop accounting yields the elapsed time of a connection.

• Wait-start For maximum accounting. Have RADIUS or TACACS+ wait until the start notice is received by AAA accounting before the user's request process begins. Most regard wait-start as overkill and an inconvenience to users, so its use is limited to highly sensitive services. This is used in older versions of IOS.

Figure 6-13: AAA accounting can use any of the three methods to track user activity

To select a method, include any one of the three keywords as arguments to the root aaa accounting command in the configuration statement. The three options give differing levels of accounting control. For example, if an administrator requests entry into a secured device's User EXEC mode, the stop-only process records only the end of the administrator's session within User EXEC mode. The start-stop process records the beginning and the end of the session. The wait-start process ensures that no connection is made prior to the accounting notice having been received and acknowledged.

• none No accounting

• start-stop Record start and stop without waiting

• stop-only Record stop when service terminates

The following example shows an AAA accounting configuration. Lines 2, 3, and 4 show all three AAA functions being configured together, the normal practice in the real world.

 MyAccessServer(config)# aaa new-model MyAccessServer(config)# aaa authentication login NetTeam local MyAccessServer(config)# aaa authentication ppp RemoteWorkers group TACACS+ local MyAccessServer(config)# aaa authorization network NetTeam group TACACS+ local MyAccessServer(config)# aaa accounting network WeWillBillYou none MyAccessServer(config)# MyAccessServer(config)# tacacs-server host BigUnixBox MyAccessServer(config)# tacacs-server key JustBetweenUs MyAccessServer(config)# MyAccessServer(config)# interface group-async 1 MyAccessServer(config-if)# group-range 1 16 MyAccessServer(config-if)# encapsulation ppp MyAccessServer(config-if)# ppp authentication chap RemoteWorkers MyAccessServer(config-if)# ppp authorization NetTeam MyAccessServer(config-if)# ppp accounting WeWillBillYou 

The accounting commands are woven in with the others to give you an idea of how statements really look. As configured here, full start-stop accounting records will be logged for all network connections made by the network team through any of the 16 asynchronous ports on the device, MyAccessServer.

Exactly what gets logged depends on how the named method list WeWillBillYou is configured. Most network managers, at a minimum, would use the network command to account for connection times. Generally speaking, the command-oriented parameters exec and commands are useful only for security audits.

RADIUS and TACACS+ Attributes

A security protocol is largely defined by the attributes it supports. After all, security tools define the raw material used to operate the user-based security system. RADIUS and TACACS+ are separate protocols packaged into the AAA command structure within IOS. The major differences between the two come into play inside the user database, where each user has a security profile containing attributes that define what that person may do. As separate technologies, RADIUS and TACACS+ have their own attributes.

RADIUS is an open standard under the auspices of the IETF and defines nearly 60 attributes. We won't list them all here, but Table 6-7 shows several to help you see what's involved in user-based security.

Table 6-7: RADIUS Attributes Used to Enforce User-Based Security

RADIUS Attribute	Description
User-Name	The name of a person's user profile account. For example, Anne Marie's user name might be "amarie."
User-Password	The secret passcode created by the person.
CHAP-Password	The encrypted value returned during the challenge-handshake exchange. This is the user name mixed with a random number called a challenge.
NAS-IP Address	The IP address of the access server requesting authentication. (Recall that NAS stands for network access server, the same thing as an access server.)
NAS-Port	The physical port number on the access server. This includes the various types of interfaces possible, such as asynchronous terminal lines, synchronous network lines, ISDN channels, and other types of interfaces.
Service-Type	The service requested or granted-for example, an administrator might request the enable command in IOS in order to enter the Privileged EXEC command mode.
Login-Port	The TCP port with which the user is to be connected-for example, port 80 for HTTP Web browsing.
Acct-Session-Id	A unique accounting identifier used to match start and stop notices in an accounting log file.
Acct-Session-Time	The number of seconds the user remained connected.
Acct-Authentic	The way the user was authenticated, whether by RADIUS, the local user database, TACACS+, or Kerberos.

Seventeen RADIUS attributes are so-called vendor-proprietary attributes. These are items that vendors can customize to extend functionality within their products. Table 6-8 shows a few Cisco extensions to give you an idea of what vendors like to customize.

Table 6-8: Cisco Extensions to the RADIUS Standard

Cisco-Specific RADIUS Attribute	Description
Password-Expiration	Specifies a time interval or event that forces the user to create a new password.
IP-Direct	The Cisco device will bypass all routing tables and send packets directly to a specified IP address. For example, IP-Direct might be used to make sure a user's WAN connection goes through a firewall.
Idle-Limit	Specifies the maximum number of seconds any session may be idle.

TACACS+ has over 50 attributes (attribute-value pairs). While TACACS+ and RADIUS both support the three AAA functions, TACACS+ is more sophisticated. For example, it has attributes such as Tunnel-ID to help secure VPN connections. This is why internetworks that use RADIUS for authenticating dial-in users will frequently use TACACS+ for authorization and accounting. Table 6-9 shows example TACACS+ attributes to give you a feel for the protocol.

Table 6-9: TACACS+ Authentication and Authorization AV Pairs

TACACS+ AV Pair	Description
service5 x	Specifies the connection service to be authorized or accounted. For example, aaa authorization service5ppp would be used to authorize a person to make a remote PPP connection to a device. Another example would be service5shell to let an administrator get into a device's Privileged EXEC command mode.
protocol5 x	A protocol is a subset of a service. For example, a PPP connection might use TN3270, VINES, Telnet, or other protocols. A key protocol nowadays is VPDN (Virtual Private Dialup Network). The AV pair protocol5vpdn would let a remote dial-in user establish an encrypted connection to the enterprise's VPN network.
routing5 x	Specifies whether routing updates may be propagated through the interface used for the connection.
priv-lvl5 x	Specifies the IOS command mode the person may use. For this to work, commands must first be grouped using the level command.
acl5 x	Restricts connection access lists on a device. Connection access lists are also called reflexive access lists, and are used to track sessions.
inacl5 x, inacl#5 x, outacl5 x, outacl#5 x	Four AV pairs restricting access to per-user inbound and outbound access lists placed on an interface.
tunnel-id	Specifies a user name for establishing remote VPN connections.
gw-password5 x	Specifies the password placed on the home gateway into the VPN. Must be used where service5ppp and protocol5vpdn.

The sampling of AV pairs in Table 6-9 shows two areas in which TACACS+ is stronger than RADIUS. First, TACACS+ offers stricter internal security than RADIUS by locking down commands and access lists. The first thing a hacker would do upon breaking into an IOS device would be to make new entries into its access lists, which makes file transfers possible. These AV pairs not only help to stop hackers, they also let the network manager specify which devices, IOS commands, or access lists individual administrators may work with. Locking out certain team members helps avoid configuration errors.

The second area in which TACACS+ is stronger is protocol support. For example, TACACS+ has AV pairs to enhance security of VPNs, which are exploding in popularity. As would be expected, TACACS+ also has accounting attributes to go along with the areas where it expands beyond RADIUS. For example, the cmd5 x AV pair lets you keep track of which IOS commands an administrator uses while working on a device. This can be useful information for diagnosing how a configuration error was made.