-
Cisco AAA Implementation Case Study
-
Preface
-
Cisco AAA Case Study Overview
-
Implementing the Local AAA Subsystem
-
Implementing Cisco AAA Servers
-
Implementing the Server-Based AAA Subsystem
-
Implementing Server-Based AAA Accounting
-
Diagnosing and Troubleshooting AAA Operations
-
Appendix A: AAA Device Configuration Listings
-
Appendix B: AAA Impact on Maintenance Tasks
-
Appendix C: Server-based AAA Verification Debug Output
-
Index
-
Feedback
Table Of Contents
1.4 Comparison of TACACS+ and RADIUS
1.4.3 Authentication and Authorization
1.4.7 Attribute-Value Pairs (AVPs)
1.5 Differences in Implementing Local and Server AAA
1.8 Network Service Definitions
1.9 Security Implementation Policy Considerations
1.10 Network Equipment Selection
Cisco AAA Case Study Overview
This chapter summarizes the technology behind AAA security solutions, outlines typical network definitions and network assumptions adopted for this case study, and lists tasks associated with implementing, verifying, and troubleshooting the AAA environment presented. Specific sections provided here are:
•
1.4 Comparison of TACACS+ and RADIUS
•
•
•
•
1.1 AAA Technology Summary
Dial access presents a challenge to network managers entrusted with network security. This case study illustrates essential steps in planning and implementing authentication, authorization, and accounting (AAA) technologies based on Cisco product capabilities.
For the purposes of this case study, the following generic definitions apply:
•
•
•
Figure 1-1 illustrates a generalized view of a Cisco-based AAA environment, featuring a network access server (NAS) and AAA server. This basic arrangement forms the foundation for this case study.
Figure 1-1 AAA-Based, Secure Network Access Scenario
In the context of the Cisco-based AAA environment addressed here, the key operational elements are network access servers (NASs), routers, and CiscoSecure Access Control Server for UNIX servers (referred to in this document as AAA servers). Depending on the conventions and requirements of your particular design, you can select a security environment which utilizes Terminal Access Controller Access Control System Plus (TACACS+) or Remote Authentication Dial-in User Service (RADIUS). This case study addresses implementation of both environments.
1.1.1 AAA RFC References
Requests for Comments (RFCs) play a crucial role in defining the behavior of devices in complex networking environments. The following RFCs are useful references for TACACS+ and RADIUS:
•
•
•
•
1.2 TACACS+ Overview
Key TACACS+ features:
•
•
•
•
•
The most common services supported by TACACS+ are PPP for IP and router EXEC shell access using console or VTY ports. EXEC shell allows users to connect to router shells and select services, such as PPP, Telnet, TN3270, or manage the router itself.
Many TACACS+ servers are available on the market today; however, the AAA server is designed specifically to be scalable and compatible with Cisco's broad line of routers, access servers, and switches. Hence, this case utilizes the Cisco AAA server as the TACACS+ server of choice.
When configured correctly, the AAA server validates AAA and responds to requests from routers and access servers with a pass or fail signal. The AAA server contains an internal database sized to 5000 users; therefore, an external Oracle database is used in our case study for user account attributes and billing information.
The AAA server acts as a proxy server by using TACACS+ to authenticate, authorize, and account for access to Cisco routers and network access servers.
1.3 RADIUS Overview
The RADIUS protocol was developed by Livingston Enterprises, Inc., as an access server authentication and accounting protocol. The RADIUS specification (RFC 2138) is a proposed standard protocol and RADIUS accounting standard (RFC 2139) is informational.
Although TACACS+ is considered to be more versatile, RADIUS is the AAA protocol of choice for enterprise ISPs because it uses fewer CPU cycles and is less memory intensive.
Communication between a network access server (NAS) and a RADIUS server is based on the User Datagram Protocol (UDP). Generally, the RADIUS protocol is considered a connectionless service. Issues related to server availability, retransmission, and timeouts are handled by the RADIUS-enabled devices rather than the transmission protocol.
RADIUS is a client/server protocol. The RADIUS client is typically a NAS and the RADIUS server is usually a daemon process running on a UNIX or Windows NT machine. The client passes user information to designated RADIUS servers and acts on the response that is returned. RADIUS servers receive user connection requests, authenticate the user, and then return the configuration information necessary for the client to deliver services to the user. A RADIUS server can act as a proxy client to other RADIUS servers or other kinds of authentication servers.
1.4 Comparison of TACACS+ and RADIUS
Table 1-1 summarizes the differences between RADIUS and TACACS+.
1.4.1 UDP and TCP
RADIUS uses UDP while TACACS+ uses TCP. TCP offers several advantages over UDP. TCP offers a connection-oriented transport, while UDP offers best effort delivery. RADIUS requires additional programmable variables, such as retransmit attempts and time-outs to compensate for best-effort transport, and it lacks the level of built-in support that reliable transport offers:
•
•
•
•
1.4.2 Packet Encryption
RADIUS encrypts only the password in the access-request packet from the client to the server. The remainder of the packet is in the clear. Other information, such as username, authorized services, and accounting, can be captured by a third party.
RADIUS can use encrypted passwords by using the UNIX /etc/password file; however, this process is slow because in involves a linear search of the file.
TACACS+ encrypts the entire body of the packet but leaves a standard TACACS+ header. Within the header is a field that indicates whether the body is encrypted or not. For debugging purposes, it is useful to have the body of the packets in the clear. However, normal operation fully encrypts the body of the packet for more secure communications.
1.4.3 Authentication and Authorization
RADIUS combines authentication and authorization. The access-accept packets sent by the RADIUS server to the client contain authorization information, making it difficult to decouple authentication and authorization.
TACACS+ uses the AAA architecture, which separates authentication, authorization, and accounting. This architecture allows separate authentication solutions that can still use TACACS+ for authorization and accounting. For example, with TACACS+, it is possible to use Kerberos authentication and TACACS+ authorization and accounting. After a NAS passes authentication on a Kerberos server, it requests authorization information from a TACACS+ server without having to re-authenticate the NAS by using the TACACS+ authentication mechanism. The NAS informs the TACACS+ server that it has successfully passed authentication on a Kerberos server, and the server then provides authorization information.
During a session, if additional authorization checking is needed, the access server checks with a TACACS+ server to determine if the user is granted permission to use a particular command. This provides greater control, compared to RADIUS, over the commands that can be executed on the access server while decoupling the authorization process from the authentication mechanism.
1.4.4 Multiprotocol Support
RADIUS does not support the following protocols (which are supported by TACACS+):
•
•
•
•
1.4.5 Router Management
RADIUS does not allow users to control which commands can be executed on a router and which cannot; therefore, when compared with TACACS+, RADIUS is not as useful for router management and is not as flexible for terminal services.
TACACS+ provides two ways to control the authorization of router commands on a per-user or per-group basis. The first way is to assign privilege levels to commands and have the router verify with the TACACS+ server whether or not the user is authorized at the specified privilege level. The second way is to explicitly specify in the TACACS+ server, on a per-user or per-group basis, the commands that are allowed.
1.4.6 Interoperability
The RADIUS standard does not guarantee interoperability. Although several vendors implement RADIUS clients, this does not ensure they are interoperable. There are approximately 45 standard RADIUS ATTRIBUTES. Using standard ATTRIBUTES improves the likelihood of interoperability. Using proprietary extensions reduces interoperability.
1.4.7 Attribute-Value Pairs (AVPs)
Throughout this case study, implementation tasks and diagnostic procedures refer to attribute-value pairs (AVPs). Each AVP consists of a type identifier associated with one or more assignable values. AVPs specified in user and group profiles define the authentication and authorization characteristics for their respective users and groups. TACACS+ and RADIUS implement an array of AVPs, each with separate type definitions and characteristics. Table 1-2 and Table 1-3 illustrate several typical AVPs.
Table 1-2 Examples of RADIUS AVPs
User-Name
String
Password
String
CHAP-Password
String
Client-Id
IP address
Login-Host
IP address
Login-Service
Integer
Login-TCP-Port
Integer
Table 1-3 Examples of TACACS+ AVPs
Inacl
Integer
Addr-pool
String
Addr
IP address
Idletime
Integer
protocol
Keyword
timeout
Integer
Outacl
Integer
1.5 Differences in Implementing Local and Server AAA
AAA requirements differ between local-based and server-based environments. Throughout this case study, procedures and examples refer to scenarios based on this important distinction.
In local-based AAA access, users are permitted or denied access based on local AAA IOS account configuration. For the purposes of this case study, local-based AAA access features these attributes:
•
•
•
•
Figure 1-2 illustrates three local-based connectivity situations to consider:
•
•
•
Figure 1-2 Local-Based Access Options
In server-based AAA access, users and groups are permitted or denied access based on AAA negotiations between s router or NAS and the AAA server. See the following attributes of server-based AAA access features:
•
•
•
Figure 1-3 illustrates the three server-based connectivity situations:
•
•
•
Figure 1-3 Server-Based Access Options
Each connectivity scenario illustrated in Figure 1-2 and Figure 1-3 involves situation-specific requirements. As a result, each scenario also contains situation-specific implementation and troubleshooting considerations. The diagnostic chapters that follow present a series of implementation steps (configuring, verifying, and testing) symptoms, problems, and suggested diagnostic processes that reflect both these differences and similarities.
1.6 Scenario Description
The baseline network environment for a hypothetical access network scenario is used as a foundation for assessing the application of various security and management features available from Cisco. Figure 1-1 (presented in "1.1 AAA Technology Summary") illustrates the underlying network environment and relationship between AAA components. The high-level AAA objectives:
•
•
•
•
1.7 Planning Your Network
A network design engineer meets with each company to complete the following tasks:
•
•
•
The following tables present two checklists that were completed for this case study. Table 1-4 focuses on general networking issues. Table 1-5 focuses on AAA implementation issues. Both checklists apply to a hypothetical network referred to in this case as Access Network.
1.8 Network Service Definitions
Based on the checklist information provided in Table 1-4 and Table 1-5, the following service definitions (stated as policies) can be asserted for this environment.
Dialup and router shell access AAA requirements are characterized in the following sections:
1.8.1 Authentication Policy
Separate the authentication policy into two distinct sections: router administration and dialup PPP.
Policies relating to router administration involve creating support for the following two authentication elements:
•
•
Policies relating to dialup PPP involve creating support for the following two authentication elements:
•
•
1.8.2 Authorization Policy
Separate the authorization policy into two distinct sections: router administration and dialup PPP.
Policies relating to router administration involve creating support for the following authorization elements:
•
•
•
Policies relating to dialup PPP involve creating support for the following authorization elements:
•
•
•
1.8.3 Accounting Policy
Accounting records are exported from an Oracle database using SQL queries. Separate the accounting policy into two distinct sections: router administration and dialup PPP.
Policies relating to router administration involve creating support for the following accounting elements:
•
•
•
•
•
Policies relating to dialup PPP involve creating support for the following accounting elements:
•
•
•
•
1.9 Security Implementation Policy Considerations
Table 1-6 present checklists summarizing the key security policy elements of this case.
In addition to these considerations, security-related attributes addressed in this case include:
•
•
1.10 Network Equipment Selection
Figure 1-1 (presented in "1.1 AAA Technology Summary") shows the specific devices used in the dialup access environment. Based on the requirements detailed in Table 1-4, Table 1-5, and Table 1-6, the following network entities were selected for this case study:
•
•
•
•
•
•
•
1.11 Task Check List
Table 1-7 summarizes AAA management implementation and operation activities for the hypothetical network in this case study. This case focuses on illustrating implementation of specific AAA-related security and management options over an Access Path implementation. Refer to Cisco AS5x00 Case Study for Basic IP Modem Service for specifics regarding commissioning Cisco access servers to support modem services at the following URL:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/as5xipmo/index.htm
