TACACS+ vs. RADIUS: Similarities and Differences

Overview

When building or operating a network (or any system) in an organization, it's important to have close control over who has access. On small networks, very few people (maybe only one person) should have the passwords to access the devices on the network; generally this information is easy to track because the number of users with access is so low. In larger organizations, however, tracking who has access to what devices at what level can quickly become complex. This is where authentication, authorization, and accounting (AAA) solutions come to the rescue. These solutions provide a mechanism to control access to a device and track people who use this access.

In modern networks, the two principal AAA solutions are the Remote Authentication Dial-In User Service (RADIUS) and Cisco's Terminal Access Controller Access-Control System Plus (TACACS+) protocols. This article discusses the services these protocols provide and compares them to each other, to help you decide which solution would be best to use on a particular network.

AAA Basics

Before we get into the specifics of RADIUS and TACACS+, let's define the different parts of AAA solutions. To make this discussion a little clearer, we'll use an access door system as an example. Let's start by examining authentication.

Authentication is the action of ensuring that the person attempting to access the door is who he or she claims to be. A simple authentication mechanism would be a fingerprint scanner; because only one person has that fingerprint, this device verifies that the subject is that specific person. (Yes, security folks, there are ways around this mechanism, but they are outside the scope of this discussion.) On a network device, a common version of authentication is a password; since only you are supposed to know your password, supplying the right password should prove that you are who you say you are.

Authorization is the next step in this process. Relying on successful authentication. authorization involves checking whether you are supposed to have access to that door. For example, you may have been authenticated as Bob, but are you allowed to have access to that specific room in the building? On a network device, are there specific commands that you should be allowed to use and others that you shouldn't? A common example in networks is the difference between a tier 1 and tier 2 engineer in a Network Operations Center (NOC): A tier 1 engineer may need to access the device and have the ability to perform a number of informative show commands, but shouldn't be able to shut down the device or change any specific configuration.

Accounting is a separate step, used to log who attempts to access the door and was or wasn't successful. A network device can log every user who authenticates a device as well as every command the user runs (or attempts to run). This step is important, as it can be used to determine potential security threats and to help find security breaches.

RADIUS Basics

RADIUS has been around for a long time (since the early 1990s) and was originally designed to perform AAA for dial-in modem users. This solution typically took effect when a user would dial into an access server; that server would verify the user and then based on that authentication would send out authorization policy information (addresses to use, duration allowed, and so on). The accounting piece of RADIUS monitored this exchange of information with each connected user. Since the authentication and authorization were so closely tied together, they were delivered with the same packet types (more on this later); whereas accounting was left as a separate process.

Modern RADIUS uses User Datagram Protocol (UDP) ports 1812 (authentication) and 1813 (accounting) for communications, while some older implementations may use ports 1645 (authentication) and 1646 (accounting). UDP is fast, but it has a number of drawbacks that must be considered when implementing it versus other alternatives. For example, when RADIUS was developed, security wasn't as important a consideration as it is today, and therefore RADIUS encrypted only the authentication information (passwords) along the traffic path.

The largest advantage of RADIUS today is that it's vendor-agnostic and supported on almost all modern platforms.

TACACS+ Basics

TACACS+ was Cisco's response to RADIUS (circa 1996), handling what Cisco determined were some shortcomings in the RADIUS assumptions and design. Overall, the purpose of both RADIUS and TACACS+ is the same—performing AAA for a system—but the two solutions deliver this protection a bit differently. TACACS+ uses the Transmission Control Protocol (TCP) rather than UDP, mainly due to the built-in reliability of TCP. Using TCP also makes TACACS+ clients aware of potential server crashes earlier, thanks to the server TCP-RST (Reset) packet.

How RADIUS and TACACS+ Address Security

The principal difference between RADIUS and TACACS+ mostly revolves around the way that TACACS+ both packages and implements AAA. TACACS+ encrypts the entire contents of the packet body, leaving only a simple TACACS+ header. This design prevents potential attackers that might be listening from determining the types of messages being exchanged between devices. TACACS+ also implements authentication, authorization, and accounting separately, which makes it possible for each functionality to be delegated to a different server, and/or even a different type of server (non-TACACS+).

TACACS+ also offers closer integration with Cisco devices, offering granular management of router commands (authorization). With a TACACS+ server, it's possible to implement command control using either access levels (which are further configured on the devices) or using command-by-command authorization based on server users and groups. RADIUS also offers this capability to some extent, but it's not as granular on Cisco devices; on some other vendors, this restriction is less limited.

TACACS+ also supports multiple protocols (other than IP), but this typically isn't a deciding factor in modern networks because the support for AppleTalk, NetBIOS, NetWare Asynchronous Service Interface (NASI), and X.25 that TACACS+ provides is irrelevant in most modern network implementations.

The biggest traditional downside to TACACS+ was that Cisco developed the protocol, and therefore it has only been widely supported on Cisco equipment. This situation is changing as time goes on, however, as certain vendors now fully support TACACS+.

Summary

Deciding which AAA solution to implement in any organization is highly dependent on both the skills of the implementers and the network equipment. Since these solutions can be used across a number of different platforms (networking and otherwise), considering them is part of your due diligence as you attempt to determine interoperability between all existing and proposed solutions.