TACACS+ and RADIUS Comparison

Introduction

Two prominent security protocols used to control dial-up access into networks are Cisco's TACACS+ and Livingston Enterprise's RADIUS. Cisco is committed to supporting both protocols with the best of class offerings. It is not Cisco's intention to compete with RADIUS or influence our users to use TACACS+. We want you to choose the solution that will best meet your needs. This document is intended to educate users on the differences between TACACS+ and Radius, so that they can make an educated choice.

Cisco has supported the Radius protocol since the release of Cisco IOS 11.1 in February 1996. We continue to enhance our Radius Client with new features and capabilities, support RADIUS as a standard. Cisco Access Servers are the only ones that implement both RADIUS and TACACS+.

Cisco seriously evaluated RADIUS as a security protocol before developing TACACS+. Many features were included in the TACACS+ protocol to meet the needs of the growing dial-up access control and security market. The protocol was designed to scale as networks grow, and to adapt to new security technology as the market matures. The underlying architecture of TACACS+ protocol complements the independent AAA architecture.

Radius Background

RADIUS is an access server authentication, authorization, and accounting protocol developed by Livingston Enterprises, Inc. It is a system of distributed security that secures remote access to networks and network services against unauthorized access. RADIUS is comprised of three components:

a protocol with a frame format that utilizes UDP/IP
a server
a client

The server runs on a central computer typically at the customer's site, while the clients reside in the dial-up access servers and can be distributed throughout the network. Cisco has incorporated the RADIUS client into Cisco IOS 11.1.

Client/Server Model

A Network Access Server (NAS) operates as a client of RADIUS. The client is responsible for passing user information to designated RADIUS servers, and then acting on the response that is returned. RADIUS servers are responsible for receiving user connection requests, authenticating the user, and then returning all configuration information necessary for the client to deliver service to the user. The RADIUS servers can act as proxy clients to other kinds of authentication servers.

Network Security

Transactions between the client and RADIUS server are authenticated through the use of a shared secret, which is never sent over the network. In addition, any user passwords are sent encrypted between the client and RADIUS server, to eliminate the possibility that someone snooping on an unsecured network could determine a user's password.

Flexible Authentication Mechanisms

The RADIUS server supports a variety of methods to authenticate a user. When it is provided with the user name and original password given by the user, it can support PPP PAP or CHAP, UNIX login, and other authentication mechanisms.

Source Code Availability

Livingston and Merit (University of Michigan) are making the C source code for an example RADIUS server available without use restrictions.

You can obtain the Ascend distribution from:

ftp://ftp.ascend.com/pub/Software-Releases/Radius/

You can obtain the Livingston distribution from:

ftp://ftp.livingston.com/pub/livingston/radius/

Comparison

The following sections compare several features of TACACS+ and RADIUS.

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 re-transmit attempts and time-outs to compensate for best effort transport, but it lacks the level of built-in support that a TCP transport offers:

Using TCP provides a separate acknowledgment that a request has been received, within (approximately) a network RTT, regardless of how loaded and slow the backend authentication mechanism might b. (TCP ACK).
TCP provides immediate indication of a crashed (or not running) server (RST packets). You can determine when a server has crashed and come back up if you use long-lived TCP connections. UDP can't tell the difference between a down server, a slow server, and a non-existent server.
Using TCP keepalives, server crashes can be detected out-of-band with actual requests. Connections to multiple servers can be maintained simultaneously, and you only need to send messages to the ones that are known to be up and running.
TCP is more scalable and adapts to growing, as well as congested, networks.

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, could be captured by a third party. RADIUS can use encrypted passwords by using the UNIX /etc/password file; however, this process takes longer because of a slow, linear search of this 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 will fully encrypt the body of the packet for more secure communications.

Authentication and authorization

RADIUS combines authentication and authorization. The access-accept packets sent by the RADIUS server to the client contain authorization information. This makes it difficult to de-couple authentication and authorization.

TACACS+ uses the AAA architecture, which separates authentication, authorization, and accounting. This 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 authenticates on a Kerberos server, it requests authorization information from a TACACS+ server without having to re-authenticate. The NAS informs the TACACS+ server that it has successfully authenticated 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 over the commands that can be executed on the access server while decoupling from the authentication mechanism.

Multiprotocol Support

RADIUS does not support the following protocols:

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

TACACS+ offers multiprotocol support.

Router Management

RADIUS does not allow users to control which commands can be executed on a router and which cannot; therefore, it is not as useful for router management or 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.

Interoperability

RADIUS Standard does not guarantee interoperability. Even though several vendors implement Radius clients, this does not mean they are interoperable. There are approximately 45 standard Radius ATTRIBUTES. Cisco implements about 30 of them today and is consistently adding more. If customers use only the standard ATTRIBUTES in their servers, they can probably interoperate between several vendors, providing that these vendors implement the same ATTRIBUTES. However, many vendors implement extensions that are proprietary ATTRIBUTES. If a customer uses one of these vendor-specific extended ATTRIBUTES, interoperability is not possible..