Using AAA to Scale Access Control

Using AAA to Scale Access Control

Foundation Topics AAA Components

AAA stands for authentication, authorization, and accounting. Each of these terms is explored in this section. Authentication answers the question, “Who are you?.” Authentication determines whether the user is whom they claim to be. The combination of a username and a password accomplishes authentication. For example, logging into a router with the username supervisor and the password let_me_in establishes the user’s identity. Authorization answers the question, “What is this user allowed to do?.” The user named supervisor might or might not be allowed to access certain hosts or network equipment. Additionally, authorization may assign IP addresses, such as when using a VPN, or assign a specific privilege level, such as when using an EXEC session. Accounting answers the question, “What have the users been doing on the network?” This can include information such as the length of time a VPN was used, how many times the VPN was used by a specific user, or how many users are actually using a given network resource. It is important to note that only after authentication is established can authorization and accounting be enabled. There is no requirement for using either authorization or accounting. Either one or both can be deployed, but authentication is required for the other two to work. This provides great flexibility in determining what resources to track and how to track them. Should you simply track which users have accessed the personnel files? Do you need to even track which users have accessed the personnel files? These are questions that only the system administrator can answer; however, AAA provides the flexibility to control the network resources as needed. AAA Access Modes AAA has two access modes: ■ Character mode—Used on the vty, TTY, AUX, and CON ports, which are generally used to configure a device. ■ Packet mode—Used on the ASYNC, BRI, PRI, and serial ports, as well as on dialer profiles and dialer rotaries, usually when the user is trying to communicate with a different device. 150x01x.book Page 495 Monday, June 18, 2007 8:52 AM 496 Chapter 20: Using AAA to Scale Access Control Table 20-2 illustrates the port and its associated mode.

Understanding the TACACS+ and RADIUS Protocols

The TACACS+ and RADIUS protocols perform similar functions, providing AAA services for networks. But, there are also many differences between them. RADIUS, described in RFC 2865, has been supported by Cisco equipment since Cisco IOS Software Release 11.1. Many enhancements and new features have been incorporated into Cisco IOS with each new release. While Cisco Systems refined its support of RADIUS, it also developed TACACS+ (RFC 1492) because there was a need for greater support to handle increasingly larger networks. The underlying architecture provided by TACACS+ more easily allows for separation of authentication, authorization, and accounting. The sections that follow explore how using RADIUS and TACACS+ differ on the issues of protocol used, encryption techniques, Authentication and Authorization, protocol support, and interoperability. UDP Versus TCP RADIUS relies on UDP, whereas TACACS+ relies on TCP. This has several implications because of the inherent differences between connection-oriented (TCP and TACACS+) and connectionless (UDP and RADIUS) protocols. TCP offers several advantages, some of which include the following: ■ TCP provides an indication that a server has crashed due to a TCP reset (RST) and the TCP keep-alive mechanism. To do this with UDP, extensive additional programming is required. ■ TCP is far more scalable than UDP on large networks, especially on congested networks. ■ TCP allows for multiple simultaneous connections to several servers, automatically sending to only currently active servers. Using UDP, this would require additional programming. Table 20-2 AAA Access Modes Interface Mode Description AUX Character Auxiliary DTE ports Console Character Console port TTY Character Async port vty Character Virtual terminal line PPP Packet PPP on serial or ISDN interface Arap Packet AppleTalk Remote Access (ARA) protocol on serial interfaces NASI Packet NetWare Access Server Interface on serial interfaces 150x01x.book Page 496 Monday, June 18, 2007 8:52 AM Understanding the TACACS+ and RADIUS Protocols 497 Packet Encryption TACACS+ allows for encryption of the entire body of the packet while maintaining the standard TACACS+ header. A field inside the header indicates whether encrypted is enabled. RADIUS encrypts only the password within the access-request packet, leaving the remainder of the packet unencrypted. Information such as the username and the service authorized remain unencrypted, posing a possible security risk. Authentication and Authorization TACACS+ completely separates authentication and authorization. For example, it is routine within TACACS+ to use a Kerberos server for authentication and a TACACS+ server for authorization. Additionally, when a new authorization is needed during a TACACS+ session, the access server, before granting or denying the request, first checks with the TACACS+ server to see if the user is allowed to issue the command. This allows great flexibility over which commands can be executed on an access server when it has been disconnected from the authentication server. RADIUS combines authentication and authorization into a single request. This makes designing a system where authentication and authorization are addressed by separate servers very difficult, and almost impossible if the administrator wishes to use different technologies for authorization and authentication. Multiprotocol Support TACACS+ is a multiprotocol tool that supports a wide array of protocols. RADIUS, however, is limited in its understanding and utilization of different protocols. Specifically, RADIUS does not support the following protocols: ■ AppleTalk Remote Access (ARA) protocol ■ NetBIOS Frames Protocol Control protocol ■ Novell Asynchronous Services Interface (NASI) ■ X.25 PAD connection Router Management RADIUS does not allow users to control which commands can and cannot be executed on a router. RADIUS either allows the user to access the router or does not. For RADIUS, there is no command-specific authorization for a router. 150x01x.book Page 497 Monday, June 18, 2007 8:52 AM 498 Chapter 20: Using AAA to Scale Access Control TACACS+ provides two methods to control the authorization of router commands: ■ Specify in the TACACS+ server the commands that are allowable by this user or group. ■ Relying on privilege levels, query the TACACS+ server to determine whether this user or group is authorized to issue a command at this privilege level. Interoperability Adherence to standards does not guarantee interoperability between systems. While still complying with the RFC for RADIUS, several vendors have added additional features that do not meld well with the Cisco implementation of RADIUS. If only the standard RADIUS features are used, Cisco equipment works very well. A manufacturer is able to implement features that are outside the scope of the RADIUS standards. In these cases, there may be serious deficiencies in the interoperability of that manufacturer’s equipment and Cisco equipment. Because TACACS+ was designed by Cisco, all TACACS+ features are fully implemented in Cisco equipment.