Many protocols require authentication verification before providing authorization and access rights to the user or device. Each of the protocols that will be discussed in detail in the following sections is an example of such protocols. TACACS+ and RADIUS are the two predominant protocols implemented with security servers and used by networking devices. A third protocol, Kerberos, is used in some enterprise environments to first verify that users and the network services they use are really who and what they claim to be before granting access privileges. These protocols forward information between the network device and the security server.
Terminal Access Controller Access Control Plus (TACACS+) is a security server protocol that enables central control of users attempting to gain access into networking devices. TACACS+ is the latest generation of the TACACS protocol, which was developed by the BBN for MILNET. At that time, TACACS was primarily a User Datagram Protocol (UDP) access−based protocol that orchestrated user access. There are three versions of TACACS:
TACACS—An industry−standard protocol that forwards usernames and passwords to a central security server. TACACS is specified in RFC 1492. The original version of TACACS combined authentication and authorization and was based on the UDP protocol.
XTACACS—An enhanced version of TACACS with extensions that Cisco added (thus, the “X” for “extension”) to support advanced features. The most notable advanced feature is the added functionality for multiprotocol support and authorization of multifunction connections with syslog exporting. XTACACS separated authentication, authorization, and accounting. It has been superseded by TACACS+.
TACACS+—Supported by the Cisco family of routers and access servers beginning in Cisco IOS release 10.3. TACACS+ is the third generation of Terminal Access Control, which is a Cisco proprietary client/server protocol. TACACS+ uses TCP as its transport protocol, and the server daemon usually listens on port 49. Its use originates from the need to manage and control terminal access. Its functions are based on the classic server/client relationship, using request and response to determine, in an algorithm format, whether or not users are authenticated, authorized, and accounted for. This protocol is a completely new version of the TACACS protocol referenced by RFC 1492.
TACACS+ surpasses TACACS and XTACACS, and furthermore, it’s not compatible with its predecessors, which are considered end of life (EOL) by Cisco and should probably not be considered for implementation.
TACACS+ uses TCP as the communication protocol to communicate between the network device and the security server on reserved port number 49. TCP, as opposed to UDP, was chosen in part because of its inherent capability to reliably retransmit data packets. Using MD5, TACACS+ also encrypts the data payload of the packet. However, the 12−byte header of a TACACS+ packet is sent in cleartext. Figure 2.3 shows the header of a TACACS+ packet.
Figure 2.3: TACACS+ packet header.
TACACS+ Authentication Process
The TACACS+ protocol forwards many types of username/password information. The information is encrypted over the network with the MD5 encryption algorithm. TACACS+ authentication also supports multiple challenge and response demands from the TACACS+ server.
A TACACS+ server can authenticate a user based on its own internal username and password database, or it can act as a client to authenticate the user based on various other authentication systems, such as a Windows NT domain controller. The TACACS+ authentication process typically begins with the network access server sending a START message to the TACACS+ server. The START packet is always sent only as the first packet in the authentication process or following a reset.
Upon receipt of the START packet from the network access server, the TACACS+ server sends a REPLY packet with the value set to GET USER. This will present the client with a username prompt. The access server gets the requested information and returns it to the TACACS+ server in a CONTINUE packet. If the username is found either in the local database on the TACACS+ server or in an external database, the server sends another REPLY packet with the value set to GET PASS. This will present the client with a password prompt. The access server again gets the requested information and returns it to the TACACS+ server in a CONTINUE packet. If the password is found either in the local database on the TACACS+ server or in an external database and it creates a match with the corresponding username, the server sends another REPLY message with the value set to ACCEPT or REJECT. The authentication process is detailed in Figure 2.4.
Figure 2.4: TACACS+ authentication.
Note One other TACACS+ packet can be returned to the network access server from the security server. The ERROR packet is sent in the event of an error due to a failed daemon or network congestion problem during the authentication phase. If the network access server receives an ERROR packet from the security server, it will attempt to authenticate the client using the next configured method in the method list.
TACACS+ Authorization Process
Unlike the authentication process, the TACACS+ authorization process defines only two types of messages, REQUEST and RESPONSE. The authorization process begins with the network access server sending to the TACACS+ server a REQUEST packet requesting authorization. The REQUEST packet contains certain values that it sends to the TACACS+ server to distinguish the user. These values include the following:
After receipt of the REQUEST packet from the network access server, the TACACS+ server
determines the permissions the user has and sends back a RESPONSE packet with bundled attributes to the network access server. The TACACS+ authorization process can be seen in Figure 2.5.
Figure 2.5: TACACS+ authorization.
TACACS+ Accounting Process
Accounting is usually the final phase of the AAA architecture. The TACACS+ accounting phase and authorization phase are similar. The accounting process begins with the network access server sending an accounting REQUEST packet to the TACACS+ server. The REQUEST packet contains many of the same values that the authorization packet contained. After receiving the REQUEST packet, the TACACS+ server acknowledges the request with a RESPONSE packet indicating that all accounting took place correctly.
RADIUS (Remote Access Dial In User Service) is an Internet security protocol originally developed by Livingston Enterprises. It is defined in RFC 2138 and RFC 2139. RADIUS uses UDP as its transport protocol and is generally considered to be a connectionless service. RADIUS clients run on routers and send authentication requests to a central RADIUS server, which contains all the user authentication credentials. The following list includes some key aspects of RADIUS that have led to its success:
Based on client/server architecture
Support for many authentication mechanisms
Encrypted transactions between client and server
Interoperability with other protocols
RADIUS is a fully open protocol, which means that the source code is freely available and can be modified to work with any security system on the market. This allows RADIUS to be tailored to suit the particular needs of a particular environment. RADIUS is based on a client/server model. The remote machine acts as the client, and the security RADIUS server at the other end handles authentication.
RADIUS supports the AAA model just as TACACS+ does; however, RADIUS combines authentication and authorization and separates only accounting. RADIUS is able to interact with other authentication protocols, such as TACACS, XTACACS, and TACACS+.