|
|
As mentioned earlier, AAA services rely on the security server using authentication protocols to implement the security functions of AAA. RADIUS and TACACS+ are the predominant authentication protocols that are widely used to provide AAA security functions on Cisco devices. The sections that follow briefly discuss the features of these protocols.
RADIUS is a distributed client-server protocol that is widely used to secure networks against unauthorized access. The RADIUS protocol was initially developed by Livingston Enterprises as an access server authentication and accounting protocol. RADIUS protocol gained wide acceptance and is now implemented by several vendors including Cisco. RADIUS is gaining support among a wide customer base, and most importantly the Internet service providers (ISP).
One of the main objectives of the RADIUS protocol standard is to provide interoperability and flexibility between RADIUS-based products from different vendors. For this reason, RADIUS is a fully open standard protocol, distributed in C source code format, and can be used unrestrictedly by any vendor or customer. This allows for the flexibility of being able to modify RADIUS to work with any security system currently available on the market.
As mentioned earlier, RADIUS is implemented in a client-server model, where the client is any Network Access Server (NAS) device, such as a Cisco router or a firewall, which sends an authentication request to a central RADIUS server that contains user profiles with access information for the users.
Cisco network devices support RADIUS client implementation on a wide range of products such as routers, switches, firewalls, VPN3000 concentrators, and wireless access points. RADIUS implementation provides centralized user administration, which is important to its applications. ISPs have tens of thousands of users. Because user information changes constantly, managing user databases on a regular basis can be a challenge. Centralized administration of users in this environment is a basic operational requirement.
The RADIUS protocol authentication and the accounting services are documented separately in IETF RFC 2865 and RFC 2866, which replace RFC 2138 and RFC 2139, respectively.
Note
A new protocol called the Diameter protocol is currently underway and is being positioned as the designated successor of RADIUS protocol. RADIUS, however, is still common and widely used in present implementations. According to the IETF, the Diameter protocol will provide a new framework for the next-generation AAA services for applications such as IP mobility. Discussion of the Diameter protocol is beyond the scope of this book and is documented in IETF RFC 3588.
Figure 8-1 shows the header format of the RADIUS packet with descriptions of the fields in Table 8-1.
RADIUS uses UDP as transmission protocol to communicate between the client and the server using UDP port 1812 for authentication and authorization requests, and UDP port 1813 for accounting requests. Earlier deployments of RADIUS used UDP port 1645 for authentication and authorization requests, which conflicted with the registered "datametrics" service, and the deployments used UDP port 1646 for accounting, which conflicted with the "sa-msg-port" registered service.
As a connectionless protocol, UDP does not offer guaranteed delivery. Issues related to server availability, retransmission, and timeouts are handled by the RADIUS-enabled devices rather than the transmission protocol.
The RADIUS communication is triggered by a user login that consists of a query (packet type: Access-Request) that originates from the NAS and is sent to the RADIUS server. A corresponding response (packet type: Access-Accept or Access-Reject) is received back from the RADIUS server.
The Access-Request packet contains the username, encrypted password, NAS IP address, and NAS port number information. The packet also contains information on the type of session that the user wants to initiate. For example, if the query is presented in character mode (for example, when Telnet is being used), the packet will consist of a "Service-Type = Shell"; but if the request is presented in PPP mode, the packet will consist of "Service-Type = Framed-User" and "Framed-Type = PPP".
When the RADIUS server receives the Access-Request packet, the first thing it checks for is the shared secret key for the client that is sending the request. This ensures that only authorized clients are able to communicate with the server. If the server is not configured with the appropriate shared secret for the client or the shared secret is incorrect, the server drops the request silently without sending any response back. When the client-server communication is validated, the server continues to process the information in the Access-Request packet against the user database. Most RADIUS implementations (including the Cisco) support local database and external database systems, such as Windows Active Directory, Lightweight Directory Access Protocol (LDAP), Novell Directory Services (NDS), Open Database Connectivity (ODBC), and one-time password (OTP).
If the username is found in the database, and the password is validated, the server returns an Access-Accept response to the client. The Access-Accept carries a list of AV pairs that describe the parameters to be used for this session. As mentioned earlier, attributes include the service-type (Shell or Framed), protocol type, and IP address to be assigned to the user, as well as access list parameters, or static route information to be installed in the routing table of the NAS. In addition to the standard set of attributes, the RADIUS protocol specifies the vendor-specific attribute (Attribute 26), which allows vendors to support their own extended attributes that are specifically tailored to their application and are not for general use. (For details of various types of RADIUS attributes, refer to Cisco documentation.)
If the username is not found in the database, or if the password is incorrect, the RADIUS server returns an Access-Reject response back to the client. Access-reject is also sent when authorization fails.
Figure 8-2 shows RADIUS authentication and authorization communication between a RADIUS client (NAS device) and the RADIUS server. An important observation to make with this diagram is that RADIUS combines authentication and authorization information into one single Access-Request packet. For accounting, it sends information in a separate packet.
As discussed earlier, the RADIUS client generates an Access-Request packet, which contains information such as the username, password, NAS IP address, and NAS port number. The RADIUS packet lacks security, and its transmission is not completely protected. Only the password portion in the Access-Request packet is encrypted by a shared secret. The remainder of the packet is in the clear, making it vulnerable to various exploits and attack vectors. The following algorithm is used for password encryption:
The RADIUS client and server both have a common shared secret. The shared secret followed by the Request Authenticator is computed through an MD5 hash algorithm to produce a 16-octet value that is then XORed, with the password entered by the user producing the cipher text. The shared secret is used to sign RADIUS data packets to ensure that they are coming from a trusted source. The shared secret is used for message integrity, thereby ensuring that it is from a valid client and that the message has not been altered in transit.
TACACS+ is a security protocol that is commonly used in the AAA framework to provide centralized authentication of users who are attempting to gain access to network devices. TACACS+ is a Cisco proprietary version of the older TACACS access protocol and is not compatible with the preceding TACACS or XTACACS protocols, which are now obsolete and deprecated by Cisco.
TACACS+ provides a modular approach in provisioning the AAA services. Separation of these services is a fundamental aspect of the AAA security model architecture. TACACS+ allows the NAS to provide each service (authentication, authorization, and accounting) independently, as shown in Figures 8-3 and 8-4.
Cisco network devices support TACACS+ implementation on a wide range of products, such as routers, switches, firewalls, VPN3000 concentrators, and the TACACS+ server implementation on Cisco Secure Access Control Server (ACS) application software.
The former TACACS protocol is documented in Internet Engineering Task Force (IETF) RFC 1492. The TACACS+ protocol (developed by Cisco Systems) is a completely new version of the former TACACS protocol. Cisco makes the TACACS+ protocol specification available as a draft RFC for those customers interested in developing their own TACACS+ software.
Note
The draft is available at the Cisco Systems website at the following URL: www.cisco.com/warp/public/459/tac-rfc.1.76.txt.
Figure 8-5 shows the header format of the TACACS+ packet with illustrations in Table 8-2.
TACACS+ uses TCP as the transmission protocol to communicate between the client and the server using TCP port 49.
TACACS+ authentication is normally triggered when a user attempts an ASCII login by authenticating to a TACACS+ server application. The process described in the paragraph that follows typically occurs.
After the TCP connection is established, the network device (NAS) contacts the TACACS+ server to obtain a username prompt, which is then displayed to the user. The user provides the username, which is forwarded to the server, followed by another prompt for a password. The user then provides the password, and the password is sent to the TACACS+ server. The server will validate the credentials using the local database or external database (as configured), and a corresponding response (ACCEPT or REJECT) is received from the TACACS+ server. Several other responses can be received, as follows:
ACCEPT: This response states that the user was successfully authenticated and service may begin. The authorization process will begin if the NAS is configured for authorization.
REJECT: This response states that the authentication process failed. Authentication failure could be because of incorrect credentials, and the user may be denied further access at this point.
ERROR: This response is usually received when a communication problem occurs between the NAS and the server. This can be either at the server-side or in the client-side network connection. Several reasons can lead to an error—an incorrect secret key, a misconfigured NAS IP address, or a latency issue. When an ERROR response is received, the NAS typically attempts to use an alternative method (if configured) to continue the authentication process; this is known as a fallback process.
CONTINUE: This response states that the server is expecting additional information, and the user is prompted for further input variables.
Look back at Figures 8-3 and 8-4 to see how TACACS+ authentication and authorization communication works respectively between a TACACS+ client (NAS device) and the TACACS+ server. Unlike RADIUS, the authentication and authorization communications are separated into different packets. Similarly, accounting sends information in a separate packet.
As shown in Figure 8-4, following the authentication, the user proceeds to the authorization process (if authorization has been enabled on the NAS). As the AAA dependency regulates, authorization is not valid without authentication. Authorization will follow only upon successful completion of authentication. The TACACS+ server returns an ACCEPT or REJECT authorization response. The ACCEPT response contains data in the form of attribute-values (known as AV pairs) that are used to enforce various services and functions and to determine the user access for the network resources.
TACACS+ authentication and authorization can also be triggered when a user attempts a PPP login, which is similar to an ASCII login described earlier, except that the username and password arrives at the server in a Password Authentication Protocol (PAP) packet instead of being typed in by the user, so the user is not prompted. PPP Challenge Handshake Authentication Protocol (CHAP) logins are similar in principle.
TACACS+ protocol provides strong confidentiality by encrypting the communication between the NAS and the server. TACACS+ encrypts the entire body of the packet. The Flag field in the header of the TACACS+ packet (as shown in Figure 8-5 and Table 8-2) indicates whether the packet was encrypted.
Encryption relies on a "shared secret" key that is common on both sides—the NAS and the TACACS+ server. The "shared secret" is used to encrypt and decrypt TACACS+ packets between the two devices. The following algorithm is used for the encryption:
The TACACS+ packets are encrypted by XOR'ing with a series of MD5 hashes, each 16 bytes long. For more information on how MD5 hashing works, refer to RFC 1321.
Table 8-3 shows a quick summary and comparison of the two protocols.
|
|