This chapter is from the book
This chapter is from the book
This chapter is from the book
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:
){kind=link}
The remote user establishes a PPP connection with the network access server.
The network access server prompts the user for a username and password.
The network access server authenticates the username and password in its local database.
The network access server authorizes the user to access network services and the destination based on authentication values in its local database.
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:
){kind=link}
User establishes a PPP connection with the network access server.
The network access server prompts the user for the username and password, and the user responds.
The network access server passes the username and password to the security server.
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.
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.
){kind=link}
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.
TACACS Versions
There are three versions of TACACS security server applications:
TACACS—An industry-standard protocol specification, described in RFC 1492, that forwards username and password information to a centralized server. The centralized server can either be a TACACS database or a database such as the UNIX password file with TACACS protocol support. For example, the UNIX server with TACACS passes requests to the UNIX database and sends the accept or reject message back to the access server.
XTACACS—Defines the extensions that Cisco added to the TACACS protocol to support new and advanced features. XTACACS is multiprotocol and can authorize connections with SLIP, enable, PPP (IP or IPX), ARA, EXEC, and Telnet. XTACACS supports multiple TACACS servers and syslog for sending accounting information to a UNIX host, connects where the user is authenticated into the access server "shell," and can Telnet or initiate slip, PPP, or ARA after initial authentication. XTACACS has been superseded by TACACS+.
TACACS+ —An enhanced and continually improved version of TACACS that allows a TACACS+ server to provide the services of AAA independently. AAA support is modularized such that each feature is essentially a separate server. Each service can be tied into its own database or can use the other services available on that server or on the network. TACACS+ was introduced in Cisco IOS Release 10.3. This protocol is a completely new version of the TACACS protocol, referenced by RFC 1492 and developed by Cisco. It is incompatible with XTACACS. TACACS+ has been submitted to the IETF as a draft proposal.
The TACACS and XTACACS protocols in Cisco IOS software are officially considered end-of-maintenance and are no longer maintained by Cisco for bug fixes or enhancements. In addition, the TACACS and XTACACS freeware server code provided by Cisco is also classified as end-of-maintenance. No further engineering development or bug fixes will be provided by Cisco for these products. However, an active independent user community has been adding enhancements to the protocols.
TACACS+ Features
TACACS+ supports the following security server features:
TCP packets for reliable data transport—Uses TCP as the communication protocol for TACACS+ communications between the network access server and the security server. TCP port 49 is reserved for TACACS+.
The AAA architecture—Each service is separate and has its own database, yet they work together as one security server.
Link encryption—The data payload of TCP packets containing TACACS+ protocol values is encrypted for security between the network access server and the security server.
Each TACACS+ packet has a 12-byte header sent in cleartext and a variable-length body containing TACACS+ parameters—The body of each packet is encrypted by an algorithm that uses a pseudo-random pad (that is, fill characters) obtained with MD5. TACACS+ packets are transmitted over a network and are stored in the TACACS+ server in encrypted form. The packet is decrypted by reversing the encryption algorithm when needed by the network access server or the TACACS+ application.
PAP and CHAP authentication—Provides complete control of authentication through PAP and CHAP challenge/response, as well as through the login and password dialog box, and interactive login message support.
LAN and WAN security—Provides AAA support for remote dialup and LAN access for network access servers, routers, and other network equipment that supports TACACS+. Enables centralized management of network equipment.
Encapsulation protocols for dialup access—Supports SLIP, PPP, and ARAP as well as TN3270 and X.121 addresses used with X.25.
Auto-command—Is automatically executed for a user if it is configured in the TACACS+ database and is supported by the network access server.
Callback—Reverses phone charges by commanding the network access server to call back the user. Can offer extra security for telecommuters.
Per-user access lists—The TACACS+ database can instruct the network access server to assign a previously configured access list for controlling user access to network services and destinations during the authorization phase.
The TACACS+ Authentication Process
The TACACS+ packet header has a type field that identifies whether each packet is part of a AAA process. TACACS+ authentication has three packet types: START, CONTINUE, and REPLY. Consider the TACACS+ authentication process, in which the network access server exchanges user authentication packets with the TACACS+ server (see Figure 4-14) using the following steps:
){kind=link}
The network access server sends a START authentication packet to the TACACS+ security server to initiate the authentication process.
The authentication process on the TACACS+ security server typically sends a GETUSER packet containing a username prompt to the network access server.
The network access server displays a username prompt to the user and sends the username entered by the user inside a CONTINUE packet to the TACACS+ security server.
The TACACS+ security server typically sends a GETPASS packet to the network access server, containing a prompt for a password. The network access server displays the password prompt.
The network access server sends a CONTINUE packet containing the password entered by the user to the TACACS+ security server.
The TACACS+ security server checks the password against the information stored in the TACACS+ configuration file to decide whether the user passes or fails the authentication. The server process then sends a PASS or FAIL packet back to the network access server as its final status.
Figure 4-14 The TACACS+ Authentication Process
The TACACS+ Authorization Process
The TACACS+ authorization process uses two packet types: REQUEST and RESPONSE. User authorization is controlled by exchanging AV pairs from the TACACS+ security server with the network access server. Consider the TACACS+ authorization process between the network access server and the TACACS+ server, which is as follows (see Figure 4-15):
){kind=link}
The access server sends an authorization REQUEST packet to the TACACS+ security server. The packet contains a fixed set of fields that describe the authenticity of the user or process, and a variable set of arguments that describe the services and options for which authorization is requested.
The TACACS+ security server process sends a RESPONSE packet containing a variable set of response arguments (AV pairs) back to the network access server. The AV pairs are based on the permissions previously configured for that user stored in the TACACS+ configuration file. Here are some examples of AV pairs:
- service = ppp—The primary service allowed
- protocol = ip—The protocol allowed for this service
- addr = 172.16.10.1—An authorized network address
- timeout = 12—An absolute timer for the connection in minutes
The network access server uses the AV pairs to deny, permit, or modify the commands and services requested by the user.
Figure 4-15 The TACACS+ Authorization Process
The TACACS+ Accounting Process
The TACACS+ accounting process uses two packet types—REQUEST and RESPONSE—and operates much like the authorization process. Accounting provides an audit record of user activity on specified network services. The accounting service can compile records of all activity on the network equipment and can store the record in a standard format (such as a .csv [comma-separated value] file) on the security server for later analysis.
Consider the TACACS+ accounting process between the network access server and the TACACS+ server, which is as follows (see Figure 4-16):
){kind=link}
The network access server sends an accounting REQUEST packet to the TACACS+ security server containing a fixed set of fields that describe the authenticity of the user or process. The packet includes an accounting record consisting of a variable set of arguments (AV pairs) that describe the services and options for which accounting is 1 being compiled based on the selected event and accounting method. The accounting AV pairs include those used for authorization plus additional pairs specifying start, stop, and the elapsed time of the accounting record.
The TACACS+ security server sends a RESPONSE packet to the access server and acknowledges receipt of the accounting record. The response packet indicates that the accounting function on the TACACS+ security server has completed and that the record has been recorded and stored.
Figure 4-16 The TACACS+ Accounting Process
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.
RADIUS Versions
Many versions of RADIUS are available. Some major versions of RADIUS are summarized in this section:
IETF implementation—Developed and proposed to the IETF by Livingston Enterprises, now a division of Lucent Technologies, the IETF implementation of the RADIUS protocol is specified in RFC 2865 and RADIUS accounting in RFC 2866. It supports approximately 63 attributes.
Cisco implementation—Starting in Cisco IOS release 11.2, an increasing number of attributes and functionality are included in each release of Cisco IOS Software and CiscoSecure ACS. It supports approximately 58 attributes.
Ascend implementation—Ascend is constantly changing and adding vendor-specific attributes such as token caching and password changing. An application programming interface (API) allows the rapid development of new extensions, making competing vendors work hard to keep up. Although RADIUS was originally developed by Livingston Enterprises, it was championed by Ascend. It supports more than 254 attributes.
Other vendors—Other versions of RADIUS are available as follows:
Merit, a UNIX- and LINUX-based version.
Internet Authentication Service for Microsoft Windows 2000 supports RADIUS. See http://www.microsoft.com/windows2000/library/howitworks/communications/remoteaccess/ias.asp for more information.
Funk Steel-Belted RADIUS by Funk Software. See http://www.funk.com for more information.
RADIUS Features
RADIUS supports the following security server features:
UDP packets—Uses UDP as the communication protocol for RADIUS communications between the network access server and the security server over UDP port 1812, the officially assigned port number. Some deployments of RADIUS use UDP port 1645. UDP simplifies RADIUS client and server implementations.
Combined authentication and authorization, and separate accounting—The RADIUS server receives user requests, authenticates users, and provides configuration information to the client. The RADIUS accounting server performs accounting.
Encrypted user passwords—Only user passwords in RADIUS packets are encrypted, using MD5 hashing for security.
PAP and CHAP authentication—Provides control of authentication through PAP and CHAP challenge/response and through login and password dialogs such as the UNIX login.
WAN security—Provides AAA support for remote dialup for network access servers developed by many vendors that support RADIUS clients. Enables centralized management of remote access.
SLIP, PPP, and ARAP framed protocols—Also supports Telnet, rlogin, and Local Area Transport (LAT).
Auto-command—A user can automatically execute a command if it is configured in the RADIUS database and is supported by the network access server.
Callback—Reverses phone charges by commanding the network access server to call back the user. Can give extra security for telecommuters.
Extensible—All transactions use variable-length AV pairs. New attributes can easily be added without disturbing existing implementations of the protocol. The protocol allows vendors to develop their own attributes with the vendor-specific attribute. Vendor-specific AV pairs allow the addition of new AV pairs.
Ensures network security—Transactions between the client and RADIUS security server are authenticated through the use of a shared secret.
The RADIUS Authentication and Authorization Process
The RADIUS client and RADIUS security server communicate using Access-Request, Access-Accept, Access-Reject, and Access-Challenge packets. As shown in Figure 4-17, when a user attempts to log in and authenticate to a network access server configured as a RADIUS client, the following steps occur:
){kind=link}
Figure 4-17 The RADIUS Authentication and Authorization Process
The user initiates a PPP authentication request to the network access server.
The user is prompted for and enters a username and password.
The network access server sends an Access-Request packet containing the username and encrypted password and other attributes over the network to the RADIUS security server.
The RADIUS security server validates the sending client, authenticates the user, looks up the user authorization parameters, and sends one of the following responses:
Access-Accept—The user is authenticated.
Access-Reject—The user is not authenticated and is prompted to reenter the username and password by the network access server, or access is denied.
Access-Challenge—A challenge is optionally issued by the RADIUS security server. The network access server collects additional data from the user and sends it to the RADIUS security server.
The network access server acts on the authentication parameters, permitting selected services.
The Access-Accept or Access-Reject response is bundled with additional data (AV pairs) that is used for EXEC sessions or network authorization. The RADIUS authentication process must be completed before the RADIUS authorization process. Some additional data that can be included in the Accept or Reject packets consists of the following in AV pairs:
Services that the user can access, including Telnet, rlogin, or LAT connections, and PPP
SLIP or EXEC services
Connection parameters including the host or client IP address, access list, and user timeouts
The RADIUS security server can periodically send an Access-Challenge packet to the network access server to prompt the user to reenter his username and password, send the state of the network access server, or to perform other actions determined by the RADIUS server vendor. The RADIUS client cannot send an Access-Challenge packet.
The RADIUS Accounting Process
The RADIUS protocol has been enhanced to include delivery of accounting information from a RADIUS client to a RADIUS accounting server using UDP port 1813. The RADIUS client is responsible for sending user accounting information to a designated RADIUS accounting server using an Accounting-Request packet with accounting AV values.
The RADIUS accounting server is responsible for receiving the accounting request and returning a response that it has successfully received the request. It uses an Accounting-Response packet to do so.
As shown in Figure 4-18, when a user attempts to log in and authenticate to a network access server configured as a RADIUS client, the following steps occur:
){kind=link}
After initial authentication, the network access server sends an Accounting-Request start packet to the RADIUS security server.
The RADIUS security server acknowledges receipt of the start packet with an Accounting-Response packet.
At the end of service delivery, the network access server sends an Accounting-Request stop packet describing the type of service delivered and optional statistics.
The RADIUS security server acknowledges receipt of the stop packet with an Accounting-Response packet.
Figure 4-18 The RADIUS Accounting Process
RADIUS Attributes
RADIUS attributes carry the specific authentication, authorization, information, and configuration details for the request and reply. Attributes are appended to the end of a RADIUS packet. One or more attributes can be appended. The overall length of the RADIUS packet indicates the end of the list of attributes.
Figure 4-19 summarizes the attribute format. The fields are transmitted from left to right.
){kind=link}
Figure 4-19 The RADIUS Attribute Format, Showing Type, Length, and Value Fields
RADIUS attributes consist of a type/length/value triplet. The purpose of each field is as follows:
Type—One octet in length. Indicates the overall type of the RADIUS attribute. One example of the many Type fields is 1, User-Name, which indicates that the Value field contains a username. Type 26, Vendor-Specific, indicates the RADIUS vendor or user and specifies the Length and Value fields.
Length—One octet in length, this indicates the length of the attribute, including the Type, Length, and Value fields.
Value—Zero or more octets in length. Contains information specific to the attribute. The Type and Length fields determine the format and length of the Value field.
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.
Kerberos Features
Here is a summary of the Kerberos features:
Secret-key authentication protocol
Authentication of users and their network services
40- or 56-bit DES for encryption and authentication
Trusted third-party key distribution (key distribution center)
Single login
Labor-intensive administration
Kerberos Components
Kerberos consists of many software components. Figure 4-20 illustrates the main Kerberos components in a network using Cisco routers and network access servers. They are summarized as follows:
){kind=link}
The KDC contains the user database.
The Kerberos server software supports the server side of Kerberos.
The Kerberos client and utilities software enable remote client features.
Kerberized Cisco products contain client, server, and utilities.
Figure 4-20 The Main Kerberos Components in a Cisco Environment
Kerberos Terminology
Kerberos uses terminology with specific meanings. The following list defines the Kerberos terminology that is used in the following section:
Credential—A general term that refers to authentication tickets such as ticket granting tickets (TGTs) and service credentials.
KDC—Key distribution center. A Kerberos server and database program running on a network host.
Kerberized—Applications and services that have been modified to support the Kerberos credential infrastructure.
Kerberos realm—A domain consisting of users, hosts, and network services that are registered to a Kerberos server.
KINIT—Kerberos client software that authenticates the user to the KDC.
Service credential—A credential authorizing a network service. When issued from the KDC, this credential is encrypted with the password shared by the network service and the KDC and with the user's TGT.
TGT—Ticket Granting Ticket. A credential that the KDC issues to authenticated users. It lets them authenticate to network services within the Kerberos realm represented by the KDC.
Kerberos Operation
This section summarizes the complex Kerberos authentication and administration process. To help understand how Kerberos works, we will consider the operation of Kerberos components with no Cisco product involved. Kerberos can be used to authenticate PPP sessions, with the KDC operating as a remote security database, so we will consider using Kerberos for PPP authentication to a network access server. Kerberos can also be used to authenticate logins to a Cisco router or network access server, with the KDC operating as a remote security database, so we will consider using Kerberos for login authentication to a network access server. Finally, we will consider the login-type applications that Cisco has Kerberized in Cisco IOS Software. Refer to Figure 4-20 for each of the following examples.
Generic Kerberos Authentication
To help understand how Kerberos authentication works, we will consider basic transactions that occur in the Kerberos protocol without using Cisco networking products. In the this example, User C wants to Telnet into Host B. User C, Host B, and the KDC are set up to perform Kerberos authentication. The following steps describe the authentication process:
User C logs on and authenticates to the KDC. User C uses the KINIT program as a Kerberos client.
The KDC provides an encrypted TGT to User C's system. User C's system authenticates the received TGT.
User C attempts to Telnet to Host B. User C's system presents the TGT to the KDC and requests a service credential authorizing access to Host B.
The KDC provides a service credential authorizing Telnet access to Host B.
User C's system provides the service credential to Host B and gets Telnet access.
User C's system presents the service credential for subsequent access to other systems or services, enabling single logon.
Using Kerberos for PPP Authentication
Cisco IOS Software supports using Kerberos as a method to authenticate PPP access to a network access server, much as TACACS+ or RADIUS is used. The remote user does not need to run the KINIT program because the network access server acts as a Kerberos client to the KDC, proxying the authentication for the remote user. In this example, User A uses Microsoft Windows 95 dialup networking to dial into the network access server and connect to the campus network. The following steps sum up the authentication process:
The User A establishes a PPP session with the network access server via a dialup PPP session.
The network access server prompts the user for a username and password, and the user enters these. The network access server is configured to authenticate PPP sessions using Kerberos.
The network access server proxies the request, acts as a Kerberos client, and requests a TGT from the KDC to authenticate the access request.
The KDC sends an encrypted TGT to the network access server that includes the user's identity.
The network access server attempts to decrypt the TGT using the password the user entered. If the decryption is successful, the remote user is authenticated to the network access server. The network access server is now assured that the KDC itself is valid, and the remote user's computer is now part of the network. The remote user must still authenticate directly to the KDC to gain access to network services.
NOTE
Dialup via asynchronous or ISDN access bypasses the Cisco IOS command-line interface. Instead, a network protocol (such as PPP) starts as soon as the connection is established.
Use the aaa authentication ppp command with the krb5 keyword to specify Kerberos as the method of user authentication for PPP.
Kerberos login authentication works only with PPP PAP authentication.
Using Kerberos for Login Authentication
Cisco IOS Software supports using Kerberos as a method to authenticate login access to a network access server, much as TACACS+ or RADIUS is used. Just as in authenticating PPP, the remote user does not need to run the KINIT program because the network access server acts as a Kerberos client to the KDC, proxying the authentication for the remote user. In this example, User B wants to log into Router A. The following steps sum up the login authentication process:
User B attempts to Telnet into Router A.
Router A is configured to authenticate login sessions using Kerberos, so Router A prompts the user for a username, and the user enters it.
Router A proxies the request, acts as a Kerberos client, and requests a TGT from the KDC to authenticate the access request.
The KDC sends an encrypted TGT to Router A that includes the user's identity. Router A prompts User B for a password, and the user enters it.
Router A attempts to decrypt the TGT using the password that the user entered. If the decryption is successful, Router A is assured that the KDC is valid.
Router A sends the TGT and requests a service credential for the Telnet access.
The KDC presents a service credential for the Telnet access to Router A, and Router A stores the TGT and service credential. User B is logged into Router A and obtains a router prompt. User B can now request other services on other Kerberized hosts without having to reauthenticate.
NOTE
A remote user does not need to run the KINIT program to get a TGT to authenticate to a Cisco router configured for Kerberos because KINIT has been integrated into the login procedure in the Cisco IOS implementation of Kerberos.
Use the aaa authentication login command with the krb5 method keyword to specify Kerberos as the login authentication method. For example, to specify Kerberos as the method of user authentication at login when no other method list has been defined, enter aaa authentication login default krb5.
The credentials forwarding feature allows forwarding of users' TGTs so that they can authenticate to multiple Kerberized hosts without having to reenter their username and password, enabling single logon.
Cisco IOS Software Kerberized Applications
Cisco IOS Release 12.0 includes Kerberos 5 support, which allows organizations that are already deploying Kerberos 5 to use existing KDCs with their routers and network access servers. The following network services are Kerberized in Cisco IOS Software:
Telnet—The Telnet client (from a router to another host) and Telnet server (from another host to a router) are Kerberized.
rlogin—Logs a user into a remote UNIX host for an interactive session similar to Telnet.
rsh—Logs a user into a remote UNIX host and allows execution of one UNIX command.
rcp—Logs a user into a remote UNIX host and allows copying of files from the host.
NOTE
You can use the connect EXEC command with the /telnet or /rlogin keywords to log into a host that supports Telnet or rlogin. You can use the /encrypt kerberos keyword to NOTE establish an encrypted Telnet session from a router to a remote Kerberos host. Or you can use the telnet EXEC command with the /encrypt kerberos keyword to establish an encrypted Telnet session.
You can use the rlogin and rsh EXEC commands to initiate rlogin and rsh sessions.
You can use the copy rcp EXEC or configuration command to enable obtaining configuration or image files from an RCP server.
Cisco IOS Kerberos support is described in more detail in the documents mentioned in the "References" section at the end of this chapter.
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:
){kind=link}
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
CiscoSecure ACS for Windows NT
CiscoSecure ACS for Windows NT is a powerful remote security database for enterprises and workgroups that need to scale a security policy across a Windows NT infrastructure. CiscoSecure ACS for Windows NT includes the following features:
It is a powerful remote security database for Windows NT Server.
It supports TACACS+ and RADIUS protocols simultaneously.
It enables AAA support for multiple network access servers, firewalls, routers, and Ethernet switches.
It supports authentication with leading token-card servers.
It authenticates using the Windows NT user database using MS-CHAP or a CiscoSecure ACS database.
Its support for the Windows NT user database enables a single login to leverage and consolidate the Windows NT username and password.
Its Web browser-based interface simplifies the configuration of user profiles, group profiles, and CiscoSecure ACS for Windows NT itself.
It stores accounting and audit information in comma-separated value format, which makes the import process for billing applications convenient.
It supports the Windows NT Performance Monitor for real-time statistics viewing.
CiscoSecure ACS for Windows NT can meet the needs of enterprises with large-scale Windows NT networks, workgroups, and smaller organizations whose secure access needs have grown beyond using a local security database. These organizations will find that CiscoSecure ACS for Windows NT is tailored to their needs. CiscoSecure ACS for Windows NT lends itself to many application solutions:
An advanced outsourcing solution that service providers can provide for the enterprise's premises
Centralized access control and accounting for multiple access servers running TACACS+ and RADIUS within service provider organizations
Centralized access control for the enterprises for the management of network access servers, firewalls, routers, and Ethernet switches
Medium-size businesses that need to support more than one network access server
CiscoSecure ACS for UNIX
CiscoSecure ACS for UNIX is a powerful access control server that meets the demanding needs of service providers and medium to large corporations. CiscoSecure ACS for UNIX includes features that extend service providers' ability to offer outsourcing services to the enterprise. It also provides the level of reliable, secure AAA that large corporate customers need to protect their networks and information assets. CiscoSecure ACS for UNIX includes the following features:
It is a powerful remote security database for Sun Solaris.
It supports TACACS+ and RADIUS protocols simultaneously.
It enables AAA support for multiple network access servers, firewalls, routers, and Ethernet switches.
It supports authentication with leading token-card servers.
It supports Oracle and Sybase external databases, scaled to large customer needs. SQL Anywhere is included with the product.
It includes a utility to easily import an existing RADIUS database.
Dial VPN support is available at both Layer 2 Forwarding (L2F) tunnel points of origin and termination.
Its Web browser-based interface simplifies the configuration of user profiles, group profiles, network access servers, and CiscoSecure ACS for UNIX itself.
The distributed architecture of CiscoSecure ACS for UNIX allows you to scale your performance, yet allows for distributed database replication.
Cisco developed CiscoSecure ACS for UNIX to address the very powerful configuration and functionality needs of service providers and medium to large corporations. CiscoSecure ACS for UNIX includes features that extend service providers' ability to offer outsourcing services to the enterprise. It also provides the level of reliable, secure AAA that large corporate customers need to protect their networks and information assets. CiscoSecure ACS for UNIX makes the following application solutions possible:
Enables an advanced outsourcing solution that service providers can offer to enterprise customers to manage the enterprise's premises access
Makes possible centralized access control and service provisioning for multiple access and network devices, TACACS+, and RADIUS within the service provider organizations
Supports enterprises using Oracle or Sybase as their strategic database application or those that need the scalable functionality of a relational database to store ACS data
CiscoSecure GRS
CiscoSecure GRS software acts as a proxy agent that translates and forwards packets between network access servers and multiple CiscoSecure ACS systems. Mobile dial VPN and Internet users can dial into a global roaming network made up of regional and Internet service providers using existing TACACS+ or RADIUS security servers and network access servers. Global roaming reduces the costs of long-distance mobile access to corporate networks and the Internet.
CiscoSecure GRS allows a regional service provider (RSP) to lease its points of presence (POPs) to customers such as ISPs. The ISP can lease the RSP's POPs to provide or expand coverage. Service providers can offer global roaming services with other service providers, extending their service offerings to include connectivity outside their local territory. Service providers can provide global roaming services to enterprises that need local connectivity available globally. Service providers can also extend their territory by leveraging the capabilities of other regional service providers without the purchase of additional equipment.