Examining Cisco AAA Security Technology

This chapter examines Cisco AAA security technology, including authentication, authorization, and accounting methods, and AAA security servers.

Upon completing this chapter, you will be able to do the following:

• Describe the components of the AAA model

• Describe access password technologies

• Describe how authentication over PPP works

• Describe the interaction of PAP and CHAP authentication

• Compare the capabilities of each of the security server types

• Describe Cisco security servers

This chapter presents an overview of the authentication, authorization, and accounting (AAA) architecture and the security technologies associated with it. This chapter contains information required to implement the access security solutions using the Cisco products covered in Chapter 5, "Configuring the Network Access Server for AAA Security," and Chapter 6, "Configuring CiscoSecure ACS and TACACS+/RADIUS." This chapter generally avoids coverage of "generic" access security that isn't related to Cisco products.

Securing Network Access by Using AAA

Unauthorized access and repudiation in the campus, dialup, and Internet environments creates the potential for network intruders to gain access to sensitive network equipment and services. The AAA architecture gives legitimate users the ability to access networked assets while limiting unauthorized access and repudiation in the campus, dialup, and Internet environments.

The AAA Security Architecture

Network access security—whether it involves campus, dialup, or Internet access—is based on a modular architecture that has three components:

• Authentication—Requires users to prove that they really are who they say they are, utilizing a username and password, challenge/response, token cards, and other methods:

  "I am user student, and my password validateme proves it."

• Authorization—After authenticating the user, authorization services decide which resources the user is allowed to access and which operations the user is allowed to perform:

  "User student can access host NT_Server with Telnet."

• Accounting—Accounting records what the user actually did, what he accessed, and how long he accessed it, for accounting, billing, and auditing purposes. Accounting keeps track of how network resources are used. Auditing can be used to track network access and to detect network intrusions:

  "User student accessed host NT_Server with Telnet 15 times."

Table 4-1 summarizes access security problems and shows the AAA methods that can be used to solve them. It also shows some ways in which AAA methods are accomplished.

Table 4-1 Access Security Problems and Solutions

Security Problem	AAA Method	How It's Accomplished
Unauthorized access: Campus Dialup Internet	Authentication Authorization	Passwords Access security in network equipment Security servers
Repudiation	Accounting	Accounting features in network equipment Security servers

Note that the solutions to securing network access summarized in Table 4-1 all include at least one of the three AAA methods supported in Cisco products. The solutions may also include AAA security server (remote security database) standards supported by Cisco products, including Terminal Access Controller Access Control System Plus (TACACS+), Remote Access Dial-In User Service (RADIUS), and Kerberos. Each AAA method and remote security database standard is examined in more detail in this chapter.

AAA and Access Traffic

Remote access is an integral part of the corporate mission. Traveling salespeople, executives, remote office staff, telecommuters, and others need to communicate by connecting to the main office LAN.

A remote user will have the needed application software (for example, FTP or Telnet client software), a protocol stack (for example, Transmission Control Protocol/Internet Protocol [TCP/IP], Internetwork Packet Exchange [IPX], AppleTalk), and link-layer drivers installed on the remote client to make network connections.

The application software and protocol stacks encapsulate the higher-layer data and protocols in link-layer protocols such as Serial Line Interface Protocol (SLIP) and Point-to-Point Protocol (PPP). The encapsulated packets are transmitted across the dialup line in analog or digital form, depending on the type of telecommunication line used.

The dialup networking components typically consist of a remote client system (Windows 95/98/2000 PC or Macintosh), the telephone network connections (Public Switched Telephone Network [PSTN] or Integrated Services Digital Network [ISDN]), a network access server (such as a Cisco 5300 network access server), and a remote security database running security server software (CiscoSecure Access Control Sever [ACS] running TACACS+), as shown in Figure 4-1.

Figure 4-1 AAA Technologies Securing Character- and Packet-Mode Traffic

AAA technologies in the remote client system, the network access server, and the security server work together to secure dialup access. The network access server implements AAA protocols to handle the AAA services.

AAA and Character-Mode Traffic

AAA technologies are useful for protecting character-mode or line-mode access to network access servers and other network equipment. In Cisco routers, AAA secures character-mode traffic during login sessions via the line types described in Table 4-2.

Table 4-2 Line Types Generating Character-Mode Traffic Secured by AAA

Line Type	Description
Aux	Auxiliary EIA/TIA-232 DTE port on Cisco routers and Ethernet switches used for modem support and asynchronous access
Console	Console EIA/TIA-232 DCE port on Cisco routers and Ethernet switches used for asynchronous access to device configuration modes
tty	Standard EIA/TIA-232 DTE asynchronous line on a network access server
vty	Virtual terminal line and interface terminating incoming character streams that do not have a physical connection to the access server or router

AAA and Packet-Mode Traffic

AAA technologies can also protect dialup access in the packet or interface mode via async, group-async, Basic Rate Interface (BRI) ISDN lines, or Primary Rate Interface (PRI) ISDN interfaces on Cisco routers. Table 4-3 outlines the protocols generating packet-mode traffic secured by AAA on Cisco routers.

Table 4-3 Protocols Generating Packet-Mode Traffic Secured by AAA

Packet-Mode Type	Description
PPP	PPP on serial or ISDN interfaces
arap	AppleTalk Remote Access Protocol (ARAP) on serial interfaces
NASI	NetWare Access Server Interface (NASI) clients connecting through the access server on serial interfaces

Authentication Methods

The main authentication methods considered are username and password, S/Key, token card and server, Password Authentication Protocol (PAP), and Challenge Handshake Authentication Protocol (CHAP) authentication. Each is covered in the following sections.

Username and Password Authentication

The most common user authentication method is the use of usernames and passwords. Username/password combination methods range from weak to strong in authentication power. Simple authentication methods use a database of usernames and passwords, whereas more complex methods use one-time passwords. Consider each of the methods shown in Figure 4-2, from the weakest at the bottom of the figure to the strongest at the top. Stronger authentication methods are better able to resist attempts to gain unauthorized access. Weaker methods are often easier to use and administer, and stronger methods are often harder to use and administer. Simple authentication methods use a database of usernames and passwords, and more complex methods use one-time passwords.

Figure 4-2 Authentication Methods and Ease of Use

The authentication methods outlined in Figure 4-2 are as follows:

• No username or password—Some system administrators and users opt to not use the username/password capabilities of their network access systems. This is obviously the least-secure option. A network intruder only has to discover the access method to gain access to the networked system.

• Username/password (static)—Stays the same until changed by the system administrator or user. Susceptible to playback attacks and password-cracking programs.

• Username/password (aging)—Expires after a set time (usually 30 to 60 days) and must be reset, usually by the user, before network access is granted. Susceptible to playback attacks and password cracking but to a lesser degree than static username/password pairs.

• S/Key one-time passwords (OTP)—An OTP method generating multiple passwords typically used for terminal logins. In S/Key, a secret passphrase is used to generate the first password, and each successive password is generated from the previous one by encrypting it. A list of accessible passwords is generated by S/Key server software and is distributed to users.

• One-time passwords (OTP)—A stronger method, providing the most secure username/password method. Most OTP systems are based on a secret passphrase, which is used to generate a list of passwords. These passphrases are good for only one login and therefore are not useful to anyone who manages to eavesdrop and capture the passphrase. S/Key is an OTP method typically used for terminal logins.

• Token cards/soft tokens—Based on something you have (for example, a token card) and something you know (for example, a token card personal identification number [PIN]). Token cards are typically small electronic devices about the size and complexity of a credit card-size calculator. There are many token card vendors, and each has its own token card server. The PIN is entered into the card, which generates a secure password. A token server receives and validates the password. The password interplay usually consists of a remote client computer, a network access server, and a security server running token security software.

You should choose and implement an authentication method based on the guidelines established in your network security policy. The policy should specify the desired balance between strength of security and ease of use.

Figure 4-3 shows an example of dialup access using usernames and password authentication. On the client end, Windows NT Dialup Networking prompts the dialup user for a username and password (as shown in Figure 4-4), which is sent over communication lines using TCP/IP and PPP to a remote network access server or a security server for authentication. Windows 95, Windows 98, and Windows 2000 operating systems have a similar authentication window.

Figure 4-3 A Remote Client Sending a Username and Password to a Network Access Server for Authentication

Figure 4-4 The Windows NT Dialup Access Username and Password Authentication Dialog Box

The remote user enters a username and password in the User name and Password fields and clicks the OK button to initiate a dialup connection.

After the user enters the username and password and clicks the OK button, Windows NT Dialup Networking transmits the username and password, over communication lines using TCP/IP and PPP, to a remote network access server or a security server for authentication, as shown in Figure 4-3.

Authentication of usernames and passwords is commonly used with secure Internet applications. For example, some Cisco Connection Online (CCO) applications require a user to be registered and to possess a username and password assigned by CCO. When the user accesses a secure CCO application using a Web browser, the application causes the Web browser to display a window requesting a username and password similar to that shown in Figure 4-4. The username and password may be validated using a AAA security server.

S/Key Authentication

Remote logins are vulnerable to network intruders using eavesdropping techniques to obtain the usernames and passwords. Intruders can use captured information in a replay attack to gain unauthorized access to the target system. The S/Key one-time password system was designed by Bellcore and others as a way to create passwords that can be safely sent over remote connections, thereby countering eavesdropping and replay attacks. With S/Key, only the one-time password crosses the network. The one-time password is a hash of the user's secret password, so the secret password never crosses the network, and the hashed one-time password is never used again.

A strong advantage of S/Key is that it protects against eavesdroppers without modification of remote client software, and it imposes little inconvenience on the users. Because S/Key is easy to integrate, many security-sensitive networks use it as their password security system. The S/Key client and host do not store any secret information. If either element is compromised, a network intruder cannot obtain secret passwords.

The S/Key system consists of three main parts, as shown in Figure 4-5: the remote client system that the user is using to gain remote access, S/Key client software installed on the remote client system that generates one-time passwords for the remote user, and S/Key host software running on the remote security server.

Figure 4-5 S/Key Authentication System Components: Remote Client, S/Key Client Software, and S/Key Host

S/Key Client Software

The S/Key client software that is usually installed on the remote system (also known as a password generator) generates a one-time password. When a one-time password is needed, the user enters a secret password into the S/Key client user interface. The S/Key client runs a one-way hashing algorithm using the secret password entered by the user and a seed value sent by the S/Key host to create the one-time password. S/Key uses either MD4 or MD5, which are one-way hashing algorithms, to create the one-time passwords. Each one-time password generated by S/Key consists of six short words. S/Key clients can have a command-line interface or a graphical user interface. An example of an S/Key password generated via a command-line interface is BONE YANK ROW RING WHOA TRUE. Figure 4-6 shows an example of the user interface of an S/Key password generator, the keyapp.exe program for Windows 95 systems.

Figure 4-6 The S/Key Client keyapp.exe User Interface

keyapp.exe has a graphical user interface that allows the user to enter the secret password, compute a one-time password, copy the password to the clipboard, and then paste the password into an authentication screen (such as Windows Dialup Networking) for the remote login. The authentication software on the remote client sends the one-time password in cleartext over the network to the S/Key host, which validates the one-time password. After the one-time password has been used, it is no longer useful to an eavesdropper. Some S/Key password generators create a list of one-time passwords that can be printed and manually entered into the authentication screen when needed.

S/Key Hosts

The S/Key host receives an authentication request from the S/Key client and sends a challenge/response with S/Key parameters that include a sequence number and a seed value used by the client hash algorithm. The S/Key client then sends the one-time password to the S/Key host. The S/Key host receives the one-time password and validates it by running the hash algorithm against it and comparing the hashed output with the previously received one-time password. If the values match, the user request is approved, and the received one-time password is stored in a file. The S/Key client and server keep track of the number of one-time passwords generated by decrementing a sequence number so that the user must reinitialize the S/Key calculator with a new secret password when the sequence number reaches 0. The CiscoSecure ACS for UNIX security server supports S/Key authentication.

An S/Key User Example

Consider an example of how a user named Sally uses S/Key from a remote UNIX system (with a command-line interface), through a network access server, to CiscoSecure ACS:

1. Sally identifies herself to the network access server in response to a standard prompt for authentication:

   User Access Verification
   Username: sally
   s/key 98 agst2359
   Password:

2. CiscoSecure ACS issues a challenge that includes a sequence number of 98 for the one-time password expected and a seed value of agst2359. The values are displayed to Sally by the network access server.

3. Sally enters 98 and agst2359 into her S/Key calculator program, called key, at the UNIX prompt. The secret password is any string of at least 10 alphanumeric characters generated by Sally, for Sally, and known only by Sally, as follows:

   % key 98 agst2359
   Enter secret password: secret_password
   The S/Key calculator creates a one-time password, as follows:
   ANNE JEAN MILK SHAW LARK NEST

4. Sally now returns to her interaction with the network access server. She enters the S/Key password and is authenticated, as follows:

   Password: ANNE JEAN MILK SHAW LARK NEST

5. The next time Sally attempts network access, she will be prompted for the one-time password sequence number 97. The sequence number is one less than what was used for the previous authentication. When the sequence number reaches 0, Sally will not be able to log on without reinitializing the S/Key calculator with a new secret password.

Token Cards and Servers

Another one-time password authentication method that adds a new layer of security is accomplished with a token card and a token server. Each token card, about the size of a credit card, is programmed to a specific user, and each user has a unique PIN that can generate a password keyed strictly to the corresponding card. The password is then entered into the password field during a remote authentication.

The use of the token card requires the user to possess a token card or soft token software and to know a password to enable the token. This is called "something you have and something you know." This represents one of the highest commercially available security methods of authentication. One-time password authentication takes place between the specified token server with a token card database and the remote client's authentication software.

Token Card and Server Operation

Token card and server systems consist of a remote client PC, a token card, a network access server, and a token server. Token cards and servers generally work as follows:

1. The user generates a one-time password with the token card, using a security algorithm.

2. The user enters the one-time password into the authentication screen generated by the remote client (in this example, the Windows Dialup Networking screen).

3. The remote client sends the one-time password to the token server via the network and a remote access server.

4. The token server uses the same algorithm to verify that the password is correct and authenticates the remote user.

Token Card and Server Methods

Two token card and server methods are commonly used:

• Time-based—In this system, the token card contains a cryptographic key and generates a password (or token) through the use of a PIN entered by the user. The password is entered into the remote client, which sends it to the token server. The password is loosely synchronized in time to the token server. The server compares the token received to a token generated internally. If they match, the user is authenticated and allowed access.

• Challenge/response—In this system, the token card stores a cryptographic key. The token server generates a random string of digits and sends it to the remote client that is trying to access the network. The remote user enters the random string, and the token card computes a cryptographic function using the stored key and random string. The result is sent back to the token server, which has also computed the function. If the results match, the user is authenticated.

Token cards are now implemented in software for installation on the remote client. SofToken, which generates single-use passwords without the associated cost of a hardware token, is one example of software token cards.

Cisco Token Card and Server Support

Cisco supports authentication from the following four token-card servers within CiscoSecure ACS software:

• CRYPTOCard RB-1 from CRYPTOCard Corporation

• SecurID ACE/Server from RSA Security, Inc.

• SafeWord from Secure Computing Corporation, which uses the DES Gold Card token card and the SafeWord SofToken software token card

• Axent Technologies token server in CiscoSecure ACS 2.4 for Windows NT

See the "References" section of this chapter for more information about these servers.

PAP and CHAP Authentication

An important component of dialup access security is support for authentication accomplished with PAP and CHAP. The following sections look at the relative strengths of PAP and CHAP. We will examine how PAP and CHAP authentication operates. We will also consider Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), an extension to CHAP.

PPP is a standard encapsulation protocol for the transport of different network layer protocols (including, but not limited to, IP) across serial, point-to-point links such as the PSTN or ISDN. PPP enables authentication between remote clients and servers using either PAP or CHAP.

Cisco network access servers are configured to perform authentication using the aaa authentication commands, which are covered in Chapters 5 and 6.

PAP Authentication Over PPP

PAP authentication, which uses PPP, provides a simple way for the remote client to establish its identity: a two-way handshake (see Figure 4-7). The handshake is done only after initial PPP link establishment. After the link establishment phase is complete, a username/password pair is repeatedly sent by the peer to the authenticator until authentication is acknowledged or the connection is terminated. Here are the messages exchanged during PAP authentication:

1. The remote client establishes the dialup link.

2. The remote client tells the network access server that it is running PPP.

3. The network access server, configured to use PAP, notifies the remote client to use PAP in this session.

4. The remote client sends the username and password in PAP format.

5. The network access server compares the username and password to that stored in its database and accepts or rejects the username and password entered.

Figure 4-7 The Steps in PAP Authentication Over PPP

PAP is not a strong authentication method. The username and password are sent in cleartext across the link. A protocol analyzer could be used to easily capture the password in an eavesdropping attack. PAP offers no protection from playback or repeated trial-and-error attacks. The peer is in control of the frequency and timing of the attempts. PAP provides a level of security similar to the usual user login at the remote host.

Usually PAP is used if it is the only authentication method supported by the client, when a plaintext password must be available to simulate a login at a remote host, or where the communication links are secure. CHAP is the preferred authentication method. Most vendor equipment and software support PAP, enabling greater interoperability between them.

CHAP Authentication Over PPP

CHAP is a stronger authentication method than PAP because the user's actual password never crosses the communications channel. CHAP uses a three-way handshake to verify the identity of the peer. The handshake is done upon initial link establishment, and it may be repeated periodically thereafter to ensure the identity of the peer. The CHAP initiation sequence and three-way handshake occur as follows and as illustrated in Figure 4-8:

1. The PPP link is established after dialup. The network access server is configured to support PPP and CHAP.

2. The network access server tells the remote client to use CHAP.

3. The remote client responds with an OK.

4. The three-way handshake occurs as follows:

   1. The network access server sends a challenge message to the remote client.

   2. The remote client replies with a one-way hash value.

   3. The network access server processes the received hash value. If it matches the station's own calculation, authentication is acknowledged. Passwords are not sent over the link.

CHAP periodically verifies the identity of the remote client by using a three-way handshake. The network access server sends a challenge message to the remote node. The remote node responds with a value calculated using a one-way hash function (typically MD5). The network access server checks the response against its own calculation of the expected hash value. If the values match, the authentication is acknowledged. Otherwise, the connection is terminated immediately.

Figure 4-8 CHAP Authentication Steps Over PPP

CHAP provides protection against playback attack through the use of a variable challenge value that is unique and unpredictable. The use of repeated challenges is intended to limit the time of exposure to any single attack. The network access server (or a security server such as CiscoSecure TACACS+) is in control of the frequency and timing of the challenges. A major advantage of the constantly changing challenge string is that eavesdropping cannot be used to capture the challenge value and replay it back later in order to gain unauthorized access to the network because the value constantly changes. CHAP is preferable to PAP for authentication. One problem with CHAP has been that it was not supported in Windows NT authentication systems. Windows NT now supports the Microsoft version of CHAP, MS-CHAP.

CHAP authentication depends on a "secret" known only to the authenticator and the remote client. The secret is not sent over the link. Although the authentication is only one-way, by negotiating CHAP in both directions, the same secret set may easily be used for mutual authentication.

CHAP requires that the secret be available in plaintext form. Irreversibly encrypted password databases that are commonly available (such as the Windows NT SAM hive, the NT password database) cannot be used.

Most vendor efforts have been focused on enabling and improving authentication methods, particularly password access technologies. Improvements to authorization and accounting methods are being made more slowly.

Authorization Methods

AAA authorization lets you control the network services available to each user and helps restrict access to internal networks. Authorization also lets you specify which Cisco IOS commands a user can issue on specific network devices. It also lets mobile users connect to the closest local connection and still have the same access privileges they would have if they were directly connected to their local networks.

You can configure the network access server to control user access to the network so that users can perform only certain functions after successful authentication, such as controlling EXEC access. As with authentication, authorization can be used with either a local security database on the network access server or a remote security database, as shown in Figure 4-9. The figure also gives an example of authentication controlling network services, Cisco IOS command access, and access to specific networks. The remote security database can cause access lists configured in the network access server to be applied to the authenticated user.

Figure 4-9 Authorization Controls User Access to Networks and Network Services

Authorization works by assembling a set of attributes describing what a user is authorized to perform. The attributes are configured in either a local security database on the network access server or a remote security database. When the user wants to gain remote access to a system, the network access server determines and enforces the user's capabilities and restrictions by gathering authentication information from the database.

Authorization can be configured to run for all network-related service requests including IP, IPX, SLIP, PPP, Telnet, and ARAP. It can also be configured to determine whether the user is allowed to run an EXEC shell in a network access server and to specify permitted commands and EXEC privilege levels. Authorization can also be configured to control or restrict access to hosts on the network by using dynamically assigned access lists.

Cisco network access servers are configured to perform authorization by using the aaa authorization commands, which are covered in Chapters 5 and 6. CiscoSecure can also be configured to perform authorization tasks with network access servers. The group and per-user security policies determine how authorization is configured.

Accounting Methods

AAA accounting lets you track the amount of network resources 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). Accounting tracks this kind of information. You can also use accounting to track suspicious connection attempts into the network.

When AAA accounting is configured, the network access server creates accounting records that report user activity. The accounting records are stored on the network access server or can be sent to the remote security database, as shown in Figure 4-10. The accounting records, which are similar to syslog records, can then be imported into a spreadsheet or accounting program and analyzed for network management, billing, and auditing.

Figure 4-10 The Network Access Server, Router, and Remote Security Database Generating and Processing Accounting Information

The accounting record consists of attribute/value (AV) pairs that typically contain the username, user network address, attempted service, start and stop time and date, amount of data transferred, network access server accessed, and source of the network record. The RADIUS and TACACS+ remote security database protocols each have provisions for recording and transmitting accounting records.

Cisco network access servers can be configured to capture and display accounting data by using the aaa accounting commands including the following: EXEC commands; network services such as SLIP, PPP, and ARA; and system-level events not associated with users, which are covered in Chapters 5 and 6.

AAA Security Servers

Cisco products support AAA access control by using either a local server database in the network access server or a remote security database running a AAA security protocol. Each security database has pluses and minuses. This section examines AAA with a local security database, AAA with a remote security database, and the remote security database standards supported by Cisco AAA features.

AAA with a Local Security Database

If only a few remote users access your network through one or two network access servers, you might want to store username and password security information on the Cisco network access server, which is referred to as local authentication on a local security database. Here are some characteristics of AAA on a local security database:

• Local authentication on a local security database is best for small networks of just a few remote users and network access servers.

• Usernames, passwords, and authorization parameters are stored in the local security database of the Cisco network access server.

• Remote users authenticate and gain authorization against the local security database.

• Authorization and accounting have limited support in the local security database.

• Controlling access with a local security database saves the cost of installing and maintaining a remote security database.

Authentication with a local security database typically works as shown in Figure 4-11. You must first populate the local security database in each network access server by specifying username profiles for each user who might log in using AAA commands. The AAA process is as follows:

1. The remote user establishes a PPP connection with the network access server.

2. The network access server prompts the user for a username and password.

3. The network access server authenticates the username and password in its local database.

4. The network access server authorizes the user to access network services and the destination based on authentication values in its local database.

5. The network access server tracks user traffic and compiles accounting records as specified in the local database.

Figure 4-11 A Local Security Database Performing AAA

AAA with a Remote Security Database

As your network grows to more than just a few remote users and network access servers, you probably should use a remote security database that provides username and password information for each of the network access servers and routers on the network. The remote security database resides in a security server on your network.

A remote security database is convenient when you have a large number of network access servers controlling network access. A remote security database lets you centrally manage remote user profiles, preventing you from having to update each network access server with new or changed user profiles for each remote user. A remote security database helps establish and enforce consistent remote access policies throughout a corporation.

Here are some characteristics of AAA on a remote security database:

• Authentication against a remote security database is best for medium- to large-size networks with many remote users and network access servers, where the cost of a security server can be justified.

• Usernames, passwords, and authorization parameters are centrally stored in the remote security database in the security server.

• Remote users authenticate and gain authorization against the remote security database.

• Authorization and accounting are supported in the network access server and the remote security database.

• A remote security database can control access to or through a network access server. Some remote security database protocols also support access control to routers, Ethernet switches, and firewalls. The remote security database controls access to network equipment that supports standards-based remote access protocols.

• The central control enabled by a remote security database saves the cost of administering each network access server on the network. The database must be secured by ensuring that the host it runs on is as secure as possible. Chapter 1, "Evaluating Network Security Threats," contains some suggestions for improving host security.

Authentication with a remote security database typically works as shown in Figure 4-12. You must first populate the remote security database with user profiles for each remote user who might log in. You must also configure the network access server (or other network equipment) to interoperate with the remote security database for AAA services. The AAA process with a remote security database is as follows:

1. User establishes a PPP connection with the network access server.

2. The network access server prompts the user for the username and password, and the user responds.

3. The network access server passes the username and password to the security server.

4. The remote security database authenticates and authorizes the user to access the network. The database in effect configures the network access server with authentication parameters by downloading commands and activating access lists in the network access server.

5. The network access server compiles accounting records as specified in the remote security database and sends the records to the security server. The security server may also compile accounting records.

Figure 4-12 A Remote Security Database Centralizing AAA Control

The primary benefit of a remote security database is that it simplifies management and ensures consistent administration of policies for remote access, dialup access, and router management through centralized control.

Remote Security Database Standards Supported by Cisco

Several remote security database standards have been written to provide uniform access control for network equipment and users. A variety of applications have been developed as shareware and as commercial products to conform to the standards.

Cisco network equipment supports the three primary security server protocols: TACACS+, RADIUS, and Kerberos. TACACS+ and RADIUS are the predominant security server protocols used for AAA with network access servers, routers, and firewalls. These protocols are used to communicate access control information between the security server and the network equipment. Cisco has also developed the CiscoSecure ACS family of remote security databases to support the TACACS+ and RADIUS protocols.

The Cisco family of network access servers, routers, the Cisco IOS user interface, and the PIX Firewall support interaction with security servers running TACACS+ and RADIUS. The TACACS+ or RADIUS security server interacts with the network equipment as if they were all network access servers. In Figure 4-13, the network access server acts as a TACACS+ or RADIUS client to the TACACS+ or RADIUS security server. Communications for AAA events between the client and server use the TACACS+ or RADIUS protocol.

Figure 4-13 TACACS+ or RADIUS Supported on Network Access Server, Router, and Remote Security Database

The following sections describe TACACS+, RADIUS, Kerberos, and CiscoSecure ACS in more detail.

TACACS+

TACACS+ is a security server application and protocol that enables central control of users attempting to gain access to a network access server, router, or other network equipment that supports TACACS+. TACACS+ services and user information are maintained in a database typically running on a UNIX or Windows NT computer. TACACS+ allows a single application control server (the TACACS+ daemon) to support AAA services independently.

RADIUS

RADIUS is a distributed client/server protocol that secures networks against unauthorized access. Cisco supports RADIUS under its AAA security paradigm. RADIUS combines authentication and authorization rather than treating them separately, as it does with accounting. RADIUS can be used with other AAA security protocols such as TACACS+, Kerberos, and local security databases. RADIUS was initially developed by Livingston Enterprises (now a part of Lucent Technologies). The RADIUS protocol is specified in RFC 2865 and RADIUS accounting in RFC 2866.

RADIUS has been implemented in a variety of network environments that require high levels of security while maintaining network access for remote users. RADIUS is a fully open protocol, distributed in source code format that can be modified to work with any security system currently available. RADIUS is widely used in part because the protocol permits vendors to extend the AV pairs beyond those specified in RFC 2865. The RADIUS protocol specifies the vendor-specific attribute (attribute 26), allowing vendors to support their own extended attributes that aren't suitable for general use. A drawback of vendor-specific AV pairs is a lack of standardization and a fragmentation of RADIUS security server products. RADIUS security servers and clients must ignore vendor-specific AV pairs that they have not been programmed to accept.

Cisco supports RADIUS clients on a variety of network access servers, routers, Ethernet switches, PIX Firewalls, VPN 3000 Concentrators, and CiscoSecure ACS.

A Comparison of TACACS+ and RADIUS

Although TACACS+ and RADIUS are very similar in function, they have several key differences, as listed in Table 4-4.

Table 4-4 TACACS+ and RADIUS Comparison

Functionality	TACACS+	RADIUS
AAA support	Separates the three services of AAA	Combines authentication and authorization and separates accounting
Transport protocol	TCP	UDP
Challenge/response	Bidirectional	Unidirectional
Protocol support	Full support	No NetBEUI
Data integrity	The entire TACACS+ packet is encrypted	Only the user password is encrypted

• Functionality—TACACS+ separates AAA functions according to the AAA architecture, allowing modularity of the security server implementation. RADIUS combines authentication and authorization and treats accounting separately, thus allowing less flexibility in implementation.

• Transport protocol—TACACS+ uses TCP. RADIUS uses UDP, which was chosen for simplification of client and server implementation, yet it makes the RADIUS protocol less robust and requires the server to implement reliability measures such as packet retransmission and timeouts instead of relying on the Layer 4 protocol.

• Challenge/response—TACACS+ supports bidirectional challenge/response as used in CHAP between two network access servers. RADIUS supports unidirectional challenge/response from the RADIUS security server to the RADIUS client.

• Protocol support—TACACS+ provides more complete dialup and WAN protocol support.

• Data integrity—TACACS+ encrypts the entire packet body of every packet. RADIUS encrypts only the password attribute in the Access-Request packet, which makes TACACS+ more secure.

Here are some additional points of comparison between TACACS+ and RADIUS:

• Customizability—The flexibility provided in the TACACS+ protocol allows for many things to be customized on a per-user basis (for example, customizable username and password prompts). Because RADIUS lacks flexibility, many features that are possible with TACACS+ are not possible with RADIUS (for example, message catalogs). However, RADIUS supports flexible customization of AV pairs.

• Authorization process—With TACACS+, the server accepts or rejects the authentication request based on the contents of the user profile. The client (network access server) never knows the contents of the user profile. With RADIUS, all reply attributes in the user profile are sent to the network access server. The network access server accepts or rejects the authentication request based on the attributes received.

• Accounting—TACACS+ accounting includes a limited number of information fields. RADIUS accounting can contain more information than TACACS+ accounting records, which is RADIUS's key strength over TACACS+.

Kerberos

Kerberos is an authentication protocol designed to validate requests for network services or resources on an open, unprotected network. Kerberos was developed at MIT to honor requests for services from hosts in the university environment that were not under organizational control. It uses the DES encryption algorithm (discussed in more detail in Chapter 13, "Cisco Encryption Technology Overview") for encryption and authentication.

Kerberos relies on a trusted third-party application, called the key distribution center (KDC), to perform secure verification of users and services, much like a title company provides escrow services for real estate transactions. Kerberos keeps a database of its clients in the KDC.

The primary use of Kerberos is to ensure that users and the network services they access are really who and what they claim to be. To accomplish this verification, the Kerberos KDC issues tickets to users. These tickets, which have a limited life span, are stored in a user's credential cache and can be used in place of the standard username-and-password authentication mechanism.

Kerberos implements the single-logon concept. This process requires authenticating a user once and then allows secure authentication (without encrypting another password) wherever that user's credential is accepted for other network services.

Kerberos software components are freely available from MIT in C source code under a copyright permission notice. The latest generally released version of Kerberos from MIT is version 5. Kerberos is also available commercially from many different vendors such as CyberSafe Corporation and WRQ Incorporated. Microsoft Windows 2000 has a built-in Kerberos server.

Cisco IOS Software version 11.2 and later (versions 11.2(6) and later are recommended) supports the Kerberos version 5 protocol specified in RFC 1510, "The Kerberos Network Authentication Service (V5)." A Cisco network access server or router configured for Kerberos acts as Kerberos client, much as a UNIX workstation would, and as a Kerberos server for Cisco IOS remote shell and Telnet daemons. Cisco considers Kerberos a legacy application that is most beneficial in networks that are already using Kerberos. Cisco routers can integrate into a Kerberos system.

CiscoSecure ACS

Cisco has developed a scalable family of CiscoSecure ACS products to meet the remote security database needs of small to medium-size enterprise and service provider businesses. CiscoSecure ACS supports the industry-standard TACACS+ and RADIUS security server protocols.

Cisco offers CiscoSecure ACS versions that run on either the Sun Solaris or Windows NT Server operating systems. CiscoSecure uses a central database that stores user and group profiles with authentication and authorization information and to store accounting records. CiscoSecure ACS is easily managed remotely with standard Web browsers, enabling simple moves, additions, and changes to usernames, passwords, and network devices.

CiscoSecure ACS is a comprehensive and flexible platform for controlling network access. As shown in Figure 4-21, CiscoSecure controls network access for the following:

• Dialup via Cisco network access servers and routers

• Router and Ethernet switch console and vty port access for central management

• Access control through a PIX Firewall

CiscoSecure ACS closely interoperates with the network access server, router, and PIX Firewall to implement a comprehensive security policy via the AAA architecture. It interoperates with industry-leading token cards and servers. CiscoSecure ACS can also be used for access control of other vendors' equipment that supports the TACACS+ and RADIUS protocols. The CiscoSecure ACS product family includes the following:

• CiscoSecure ACS for Windows NT
• CiscoSecure ACS for UNIX
• CiscoSecure Global Roaming Server (GRS)

These products are discussed in the following sections.

Figure 4-21 The CiscoSecure ACS Remote Security Database Controls Network Equipment AAA

Summary

This section summarizes the main points of this chapter:

• Authentication methods range from the use of no username or password; to static usernames and passwords, aging usernames and passwords, and the S/Key one-time password system; to the strongest authentication, one-time passwords using token cards and server systems.

• CHAP authentication includes a periodic three-way handshake to verify the authenticity of the CHAP client.

• Authorization controls access to network services and destinations.

• Accounting tracks user data in the network access server or the security server.

• In AAA with a local security database, the network access server performs AAA services and contains a user database.

• In AAA with a remote security database, the security server performs AAA, enabling centralized management of multiple network access servers.

• TACACS+ separates authentication, authorization, and accounting services.

• RADIUS accounting is made more powerful with the use of extensible vendor-specific attribute-value pairs.

• Kerberos works with a key distribution center. Servers must be "Kerberized" to support Kerberos services.

• Cisco offers three remote security database products: CiscoSecure ACS for Windows NT, CiscoSecure ACS for UNIX, and CiscoSecure Global Roaming Server.

Review Questions

Answer the following review questions, which delve into some of the key facts and concepts covered in this chapter:

References

The topics considered in this chapter are complex and should be studied further to more fully understand them and put them to use. Use the following references to learn more about the topics in this chapter.

Token Card Servers

Axent Technologies token server in CiscoSecure ACS for Windows NT 2.4, located at http://www.axent.com.

CRYPTOCard token-card servers information, located at http://www.cryptocard.com.

SafeWord token-card and authentication servers information, located at http://www.securecomputing.com.

SecurID ACE/Server from RSA Security information, located at http://www.rsasecurity.com.

S/Key

RFC 1760, N. Haller, "The S/Key One-time Password System," February 1995.

RFC 2289, N. Haller, C. Metz, P. Nesser, and M. Straw, "A One-Time Password System," February 1998.

Refer to the following URL for more information on S/Key: medg.lcs.mit.edu/people/wwinston/skey-overview.html.

Refer to the CiscoSecure ACS for UNIX User's Guide, in the "S/Key Authentication" and "Working with S/Key Authentication" sections, for more information on S/Key.

PPP

RFC 1661, W. Simpson, editor, "The Point-to-Point Protocol (PPP)," July 1994.

CHAP

RFC 1994, W. Simpson, "PPP Challenge Handshake Authentication Protocol (CHAP)," August 1996.

MD5

RFC 1321, R. Rivest, "The MD5 Message-Digest Algorithm," April 1992.

TACACS+

draft-grant-tacacs-02.txt, D. Carrel and L. Grant, "The TACACS+ Protocol," January 1997. This Internet draft for TACACS+, proposed to IETF by Cisco Systems, Inc., can be found at search.ietf.org/internet-drafts/draft-grant-tacacs-02.txt.

RFC 1492, C. Finseth, "An Access Control Protocol, Sometimes Called TACACS," July 1993.

RADIUS

RFC 2138, C. Rigney, A. Rubens, W. Simpson, and S. Willens, "Remote Authentication Dial in User Service (RADIUS)," April 1997.

RFC 2139, C. Rigney, "RADIUS Accounting," April 1997.

Kerberos

"How to Kerberize Your Site," a Web page maintained by Jim Rome, a senior scientist. This Web page can be found at http://www.ornl.gov/~jar/HowToKerb.html.

"The Kerberos Network Authentication Service," a Web page maintained by USC/ISI's GOST Group. It contains lots of information and links about Kerberos. This Web page is located at gost.isi.edu/info/kerberos.

"Kerberos: The Network Authentication Protocol," a Web page supplied by MIT, located at http://web.mit.edu/kerberos/www/.

RFC 1510, C. Neuman, "The Kerberos Network Authentication Service (V5)," September 1993.

USC/ISI Technical Report number ISI/RS-94-399, B. Neuman and T. Ts'o, "Kerberos: An Authentication Service for Computer Networks," September 1994. This document can be found at nii.isi.edu/publications/kerberos-neuman-tso.html.

CiscoSecure ACS Security Server and Cisco IOS Software

Cisco IOS Software Security Configuration Guide, Cisco IOS Release 12.0, October 1998.