The Cisco AAA Model

Cisco’s AAA network security services provide the principal structure to manage who has access to the network, what services they’re permitted to use, and a record of what they did while logged on. The three components of AAA include the following:

Authentication	Identifies and verifies the remote user. This process can take the form of a simple password or user name/password combination verified locally by the NAS, or it could use one or more authentication servers and technologies, such as one-time passwords (OTPs) or tokens.
Authorization	Determines what devices, features, or services a specific remote user is authorized to access in the network, such as network resources or services. This concept is much like that of user permissions in the Windows server model.
Accounting	Allows the network administrator to define a process for tracking the services remote users are accessing. The data collected can be used for client billing, auditing, or network planning.

NAS Servers

NAS servers, sometimes simply called access servers, are routers with interfaces designed to service the remote users of the company. A simple example would be the older 2501s with two serial interfaces connected to two modems, or the 2503 with two serial and an ISDN interface to provide access service to a small number of dial-in users, such as employees dialing in from their motel rooms.

Other combinations include the 2509–2512 series that have one or two special 68-pin interfaces that can each support up to eight modem connections with an octal cable. As modem service is being replaced by DSL and cable connections, these units are dropping in price and are becoming popular today as terminal servers. As a terminal server, a single console connection to an access server can be used to provide up to 16 console connections to other devices.

Note?

While this isn’t a CCSP exam requirement, a lab (Terminal Server.pdf) on this book’s CD-ROM demonstrates configuring and using a terminal server to save time in the lab or production network.

Most of the common modular routers have, or have had, interfaces with multiple serial and/or multiple ISDN interfaces to provide modem and ISDN access service to larger organizations and early ISPs. Figure 3-1 shows a four-port serial interface for a 4000 series router that could connect to four modems or four ISDN devices. The 4000s also offered similar modules with four or eight ISDN interfaces.

Figure 3-1: Four-port serial module for a 4000 series router

Figure 3-2 shows an NM-16A module for a 2600 or 3600 series router with two of the?68-pin serial interfaces mentioned earlier. With octal cables, these two connectors support 16 connections. Four of the interfaces on the NM-32A allow 32 connections.

Figure 3-2: NM-16A module for 2600/3600 routers

At the top end, the AS5x00 series routers can support dozens to thousands of outside connections in a variety of combinations. The AS5400 and AS5800 routers provide the capability to terminate ISDN, 56K analog modem, fax, and VoIP calls on the same interface. The AS5400 can support over 600 connections, while the AS5800 can support 2,000.

For more information, go to http://www.cisco.com on the Web and choose the link for Products. Access Servers are listed under product categories. No CCO account is needed for much of the information.

Why Authenticate?

Not too long ago, PCs didn’t require a user to type in their user name and/or a password. The computer powered up, and whoever was sitting at the keyboard had full access to anything stored on the machine. Even many networked computers were configured without a login requirement because, after all, “everybody was just like family.” This would be the ultimate “open” system.

It didn’t take long to determine that possibly everyone in the family doesn’t need to see the checkbook program or read each other’s e-mails, but, to protect those resources, it was necessary to know who was sitting at the keyboard. Some applications experimented with using passwords, and people learned to use password protection on shared resources like folders or printers. Once a password was created, it had to be shared with anyone who needed access. If more than one shared resource existed, one of two problems arose. Either unique passwords were necessary for each resource, requiring some users to keep track of multiple passwords and the resource they were associated with, or the same password was used, which meant any user who had legitimate access to one protected resource now had the password for all protected resources.

If someone left under less-than-favorable circumstances, all passwords known to that person had to be changed, and then the other users had to be told about the changes. These early efforts showed right away that leaving security up to the individual users wasn’t reliable and wouldn’t scale well as the network group.

Many organizations have this same problem with the user names/and or passwords used to access their network devices, such as routers and switches, by storing the access user name and/or password locally on the device. The following output demonstrates access requiring only a password (line con 0 and line aux 0) and access using the local database (line vty 0 4).

!
username xyzdotcom password cisco
!
line con 0
 password cisco
 login
line aux 0
 password cisco
 login
line vty 0 4
 login local
end

The preceding techniques were covered in Chapter 2. While both methods work, they have the same shortfalls and security issues as the early networking administrators faced with user data and applications. The example could be made more secure by using techniques covered in Chapter 2, including the following:

Using a different password for each access point
Using complex passwords containing eight or more characters, incorporating uppercase and lowercase letters, plus numbers and symbols
Requiring routine password changes
Using the service password-encryption command to hide the passwords from wandering eyes that could see the configuration

The encryption also reduces the chances of someone being able to capture the passwords if the configuration is included in a Telnet session. Telnet transmits all communications in cleartext.

Centralized Authentication

The lack of scalability and reliability limitations associated with locally stored authentication can only be overcome by using some form(s) of centralized authentication server. Network operating systems (OSs) typically have this feature at their core. In addition to allowing access to the network, this system usually is linked to a mechanism for matching login IDs with permissions to use protected resources. While all authenticated users might have permission to use any of the network printers, only members of the “accounting” group might be granted “permission” to access to the Accounting Department servers. And maybe only those accounting group members who are also part of the “payroll” group might be granted access to the payroll software and data.

If a payroll accountant leaves the company under any circumstances, it’s only necessary to delete their user account, which also removes them from the accounting and payroll groups, maintaining security for those assets.

AAA is a technology that can work independently or with the network security system to provide centralized authentication, authorization, and accounting security for network devices and remote user access. Figure 3-3 demonstrates a simple example of AAA and a NAS server providing secure access to a company network. With only authentication features, the remote user could have access to both the server (web server possibly) and the company network. With authorization implemented, it would be possible to allow the modem user access to both, while limiting the ISDN user to one or the other.

Figure 3-3: AAA and NAS server providing secure remote access to a network

AAA Benefits

Cisco’s AAA technology centralized network access security provides many benefits to the organization and network administrator, including the following:

Increased flexibility
Increased security
Scalability
Standard authentication methods
Multiple backup systems

Increased Flexibility

AAA’s support of authorization, in addition to authentication, means access can be maintained on a “need to have” basis, without having to maintain multiple passwords. The accounting support means that user auditing and cost-allocation policies can be implemented, as well as providing a trail that might be useful in troubleshooting network problems.

Increased Security

Multiple devices with the same locally administered user name/password offer a low level of security. Everyone having access to everything, without regard for need, also unnecessarily increases risk. Multiple locally administered passwords would appear to increase security, but might lead to employees writing down passwords if too many exist to remember. This situation would be exacerbated if complex passwords were implemented.

AAA, with its centralized security database and authorization features, allows a single secure user name/password combination for each employee and yet allows restricting access to a “need to have” basis. At the same time, AAA allows for rapid resolution of compromised passwords or terminated employees.

Scalability

AAA is a template approach to security management that remains reliable and flexible as the network grows larger and more complex. By centralizing the security databases and supporting authorization, AAA avoids the nightmare of managing many user name/password combinations in a growing environment or the alternative “weak” security of using a small number of combinations. Locally stored authentication means any time there’s a potential of a compromised user name/password or termination of an employee, each device “should” be reconfigured. The more devices that exist, the greater the amount of effort. AAA avoids this in much the same way that server security is maintained under the same circumstances.

Standard Authentication Methods

AAA supports RADIUS, TACACS+, and Kerberos security protocols for securing dial-in sessions. These protocols provide secure authentication, including encrypted communications and interaction with network server security systems. The next section compares these three systems.

Multiple Backup Systems

AAA supports multiple security servers, such as TACACS+, on the same network to provide redundancy in case of device failure or link congestion. In addition, AAA allows for multiple authentication methods to be specified so, if the first one is unavailable, then a second or third option could be used. For example, if the specified TACACS+ server is offline, the locally stored user name/password database could possibly be used or maybe even the enable password. These alternatives must be defined in advance or access could be blocked until the specified service is restored.

TACACS+, RADIUS, and Kerberos Support

AAA supports all three of these security protocols to control dial-up access into networks. You look, in turn, at each, but note that Cisco supports Kerberos as a legacy security protocol for those networks already committed to it. Cisco Secure Access Control Server (ACS), covered in the next chapter, only implements TACACS+ and RADIUS databases.

At the most obvious level, each of these three protocols does the same thing. Each provides a secure authentication process that allows remote users to access an organization’s network resources. At the nuts and bolts level, these are quite different systems, requiring several chapters to detail. The good news is this: that detailed information exists in many places, including Cisco’s web site, which is where it’s going to stay. This chapter covers those features and differences that might be on the certification exams and would allow a person to choose among them for implementation, or at least to move ahead with intelligent research.

Kerberos is covered first, and then TACACS+ and RADIUS are compared to help determine which should be implemented as part of Cisco Secure ACS.

Note?

It’s important to make sure that TACACS+, RADIUS, or Kerberos server services are properly configured before adding the client features to the NAS. Otherwise, you could lock yourself out and require a password recovery.

Kerberos

Kerberos derives its name from the three-headed dog that guards the gates of Hades in Greek mythology. Kerberos, the security protocol, is an authentication system developed at the Massachusetts Institute of Technology (MIT), which uses the Data Encryption Standard (DES) cryptographic algorithm for encryption and authentication. Kerberos is based on the assumption that internal users are no more inherently trustworthy than external users and, therefore, applies security and encrypted communications for services like Telnet for all users.

Kerberos is designed to enable two parties to exchange private information across an otherwise open network like the Internet by assigning a unique key, called a ticket, to each user that logs on to the network. The ticket is then embedded in messages to identify the sender of the message. Kerberos is based on the concept of a trusted third party, called the key distribution center (KDC), a Kerberos authentication server (AS), performing secure verification of all users and services on the network. This verification involves exchanging encrypted authentication messages without transmitting the user password.

The “lite” explanation of using Kerberos to gain network access might help.

A remote user opens a PPP connection to an organization’s NAS router.
The router prompts the user for a user name and a password.
The router then uses only the user name to request a ticket or credential verifying the user identity (TGT) from the key distribution center (KDC).
Assuming the user name is known to the KDC, an encrypted TGT is sent back to the router, which includes (among other things) the user’s identity. The ticket has a limit life of eight hours to reduce the exposure to an unauthorized capture and replay attempt.
The router uses the password from Step 2 to decrypt the TGT. If the decryption is successful, the remote user is authenticated to the router and granted access to the network.

When a remote user successfully authenticates at a boundary router, the user and the user’s machine become part of the network. Another TGT from the KDC is necessary to access network services because the original TGT is stored on the router and isn’t used for additional authentication, unless the user physically logs on to that router.

Securing a network service involves a double encryption. When a user requests access to a network service, such as a printer or Telnet access to a host, the KDC creates a service credential. This service credential contains the client’s identity, the desired network service’s identity, and a time limit. The service credential is encrypted first using a password shared by the KDC and the service. The result is encrypted again using the user’s TGT as the key.

The target service uses the TGT supplied by the user to perform the first decryption. If the result can be successfully decrypted using the password shared by the KDC and the service, then the service is available.

Since Cisco IOS 11.2, organizations already using Kerberos 5 security can use their existing authentication servers to authenticate their routers and switches. The IOS software Kerberos authentication capabilities support the following network services:

Telnet
rlogin
rsh
rcp

The previous applications are said to be Kerberized, applications and services that have been modified to support the Kerberos credential infrastructure and encrypted communications.

Driver’s License Analogy

An analogy commonly used for Kerberos is a state driver’s license, wherein the state is the KDC that issues a TGT, the license. The license contains information that can authenticate the user: the picture and description items. In addition, the permissions, such as motorcycle endorsement, and restrictions, such as glasses required, associated with the license are also included. Like a TGT, the license also has an expiration time after which it’s no longer valid.

Some states include an authentication code made up of portions of the key supplied data, such as name and birth date. Any crude attempt to alter part of the key data makes the authentication code not match.

To complete the analogy, a third party accepts the TGT, license, and, after confirming the picture and description, trusts that the state did a reasonable job in confirming the identity before issuing the license, and thereby accepts it as proof of identity, age, or the right to drive.

For more information, go to http://www.cisco.com on the Web and perform a search for Kerberos. If you’ll be working in a Kerberos environment, add a search for Configuring Kerberos to get assistance on using the Kerberos commands. No CCO account is needed for much of the information.

RADIUS

Remote Authentication Dial-In User Service (RADIUS) is an access server authentication, authorization, and accounting protocol developed by Livingston Enterprises, Inc., now a division of Lucent Technologies. RADIUS is a system of distributed security that secures remote access to networks and network services against unauthorized access.

RADIUS is a fully open protocol, distributed in source code format that can be modified to work with any security system currently available on the market. Numerous implementations of RADIUS server code are commercially and freely available. Cisco’s servers include CiscoSecure ACS for Windows, CiscoSecure UNIX, and Cisco Access Registrar. Several IETF RFCs define the RADIUS protocol, but currently it’s still a proposed standard.

A RADIUS implementation is made of the three following components:

Protocol using UDP/IP communication.
RADIUS server—a service running on a central Windows or UNIX server, typically at the customer’s site.
RADIUS client—a service residing in the dial-up access servers that can be distributed throughout the network. Cisco added RADIUS client support beginning with IOS v11.1.

Client/Server Model

A NAS router running the RADIUS client service passes user information to defined RADIUS server(s), and then acts, based on the response received. The RADIUS server responds to all user connection requests, authenticating the user, and then forwarding all configuration information needed for the client to provide the service to the user. RADIUS servers can act as proxy clients for other types of authentication servers. The RADIUS server, after reviewing the credentials, replies to the client with one of the following responses:

Accept The user is authenticated.
Reject The user is not authenticated and access is denied. The user will be prompted to reenter the user name/password.
Challenge A request for more information from the user to confirm identity.
Change Password The user must change their password.

Network Security Technology

RADIUS clients and servers use a shared secret technology for all authentications transactions. The shared secret is never sent over the network. To eliminate the possibility of someone successfully snooping a user’s password on an unsecured network, any transmitted user passwords are sent encrypted between the client and RADIUS server.

Flexiblity

RADIUS server supports a variety of methods to authenticate a user, including PPP PAP or CHAP, MS-CHAP, UNIX login, and others.

Interoperability

The other side of any open standard is that it doesn’t always guarantee interoperability with other vendors’ implementations’. RADIUS’s implementations between different vendors can vary because the RADIUS standard specifically allows vendors to offer custom features or attributes in what are called AV pairs. If a vendor device doesn’t recognize the AV pair, it ignores it. To demonstrate the variations, the IETF implementation supports attributes, while Ascend supports 254. Cisco currently supports 58 attributes on Cisco Secure ACS, access servers, Ethernet switches, PIX firewalls, and VPN 3000 concentrators.

TACACS+

Terminal Access Controller Access Control System Plus (TACACS+) is an authentication protocol that allows an NAS to communicate with an authentication server to determine if a user has access to the network.

TACACS+, a new protocol developed by Cisco, replaces two earlier industry standards: TACACS and XTACACS (Extended Terminal Access Controller Access Control System). TACACS+ isn’t compatible with the two older protocols. Cisco has submitted TACACS+ protocol specification in a draft RFC to the IETF for development of a standard and for those customers interested in developing their own TACACS+ software.

TACACS+ server services are maintained in a database on a TACACS+ daemon running on a Windows 2000/NT or UNIX host. Cisco’s servers supporting TACACS+ include CiscoSecure ACS for Windows, CiscoSecure UNIX, and Cisco Access Registrar. Cisco Access Servers (Cisco Secure ACS) can implement both TACACS+ and RADIUS. The underlying architecture of TACACS+ protocol complements the AAA architecture.

TACACS+ and RADIUS Compared

This section compares several key features of TACACS+ and RADIUS to help understand the strengths and weaknesses of each. While counterpointing many of these comparisons is possible and the information is useful, remember, in the long run, it’s Cisco’s certification and their comparison.

Authentication and Authorization

RADIUS combines the authentication and authorization services. The access-accept packets sent by the RADIUS server in cleartext to the client contain authorization information. Accounting is a separate service on the RADIUS server.

TACACS+ fully supports the AAA architecture by separating the authentication, authorization, and accounting. This allows the flexibility of using another service, such as Kerberos, for authentication, while still using TACACS+ for authorization and/or accounting.

UDP vs. TCP

TACACS+ uses TCP for connection-oriented transport between clients and servers. TCP port 49 is reserved for TACACS+. RADIUS uses UDP for best-effort delivery, requiring additional variables to be defined, such as retransmit attempts and time-outs to compensate.

The acknowledgements (TCP ACK) provide indications that a request has been received within (approximately) a network round-trip time (RTT). This same TCP process uses RST (reset) packets to provide immediate indication of a failed (or offline) authentication server. UDP can’t tell the difference between a failed server, a slow server, and a nonexistent server.

TCP keepalive packets can be used to watch for failed servers and to facilitate rapid failover between multiple connected authentication servers.

TCP scales better and adapts better to growing and/or congested networks.

Challenge/Response

RADIUS supports only unidirectional challenge/response from the RADIUS server to the RADIUS client. TACACS+ supports bidirectional challenge/response like CHAP between the two NASs.

Multiprotocol Support

Both TACACS+ and RADIUS support SLIP and PPP encapsulation protocols, but RADIUS doesn’t support the following TACACS+ supported protocols:

Novell Asynchronous Services Interface (NASI)
X.25 PAD connection
Net BIOS Frame Protocol Control protocol
AppleTalk Remote Access protocol (ARAP)

Packet Encryption

RADIUS encrypts only the password in the access-request packet from the client to the server, using MD5 hashing for security. The remainder of the packet is in cleartext exposing information such as user name, authorized services, and accounting to be captured by snooping.

TACACS+ encrypts the entire data payload of the packet leaving only the standard TACACS+ header in cleartext. While leaving the body of the packets unencrypted is possible for debugging purposes, normal operation fully encrypts the body for more secure communications. A field in the header indicates whether the body is encrypted.

Router Management

RADIUS doesn’t support limiting the user access to specific router commands as a tool for router management or terminal services.

TACACS+ supports two methods for controlling the authorization of router commands on either a per-user or a per-group basis.

Assign commands to privilege levels and have the router use TACACS+ to verify that the user is authorized at the specified privilege level.
Explicitly define the commands allowed on a per-user or a per-group basis on the TACACS+ server.