RADIUS versus TACACS+

As a regular speaker at Cisco Live and other industry conventions, I have literally spoken to tens-of-thousands of industry professionals, and I have yet to experience a public speaking engagement where someone does not ask me "when will Cisco Identity Services Engine" have TACACS+ support?" 

I fully understand that there are millions of deployed instances of Cisco's Access Control Server (ACS) which is a AAA server that communicates with both RADIUS and TACACS+.  I fully understand that a large percentage of these deployments would like to replace their existing ACS deployment with an ISE deployment and gain all the newer functionality that has been added to ISE, and in order to do so they require ISE to have all the features that ACS has, including TACACS+ support. 

I am one of many who fully and wholeheartedly believe that TACACS+ has no business being in ISE, and would prefer it never be added.  It's not that I don't love TACACS+, because I certainly do.  It's because what TACACS+ and RADIUS are designed to do are two completely different things!  Let me explain:

In the world of security, we can only be as secure as our controls permit us to be. There are laws in the United States defining what a passenger of an airplane is permitted to bring onboard. If the TSA agents weren’t operating the metal detectors and x-ray machines (and all the other things that slow us down when trying to reach our planes), then how would the FAA ever really enforce those policies?

With technology, we are faced with the same challenges. We need to have controls in place to ensure that only the correct entities are using our technological “gadgets”. The same concepts can be applied to many use-cases, including: human interaction with a computer; a computer’s interaction with a network; even an application’s interaction with data.

This security principle is known as Authentication, Authorization and Accounting (AAA).

Before allowing and entity to perform certain actions, you must ensure you know who that entity actually is (Authentication) and if the entity is authorized to perform that action (Authorization). Additionally, you need to ensure that accurate records are maintained showing that the action has occurred, so you keep a security log of the events (Accounting).  

The concepts of AAA may be applied to many different aspects of a technology lifecycle. However, this blog is focused on Secure Network Access, and therefore this blog post will focus on the aspects of AAA related to networking.  There are two main AAA types for networking:

1. Device Administration. Controlling access to who can login to a network device console, telnet session, secure shell (SSH) session, or other method is the other form of AAA that you should be aware of. This is AAA for device administration, and while it can often seem similar to network access AAA, it is a completely different purpose and requires different policy constructs.
2. Network Access. Securing network access can provide the identity of the device or user before permitting the entity to communicate with the network. This is AAA for secure network access.

With that in mind, let's discuss the two main AAA protocols commonly used in enterprise networks today:  TACACS+ and RADIUS.  Note: there is a third common AAA protocol known as DIAMETER, but that is typically only used in service-provider environments.

TACACS+

Terminal Access Controller Access-Control System (TACACS) is a protocol set created and intended for controlling access to UNIX terminals. Cisco created a new protocol called TACACS+, which was released as an open standard in the early 1990’s. TACACS+ may be derived from TACACS, but it is a completely separate and non-backward-compatible protocol designed for AAA. While TACACS+ is mainly used for Device Administration AAA, it is possible to use it for some types of network access AAA.

TACACS+ uses Transmission Control Protocol (TCP) port 49 to communicate between the TACACS+ client and the TACACS+ server. An example is a Cisco switch authenticating and authorizing administrative access to the switch’s IOS CLI. The switch is the TACACS+ client, and Cisco Secure ACS is the server.

One of the key differentiators of TACACS+ is its ability to separate authentication, authorization and accounting as separate and independent functions. This is why TACACS+ is so commonly used for device administration, even though RADIUS is still certainly capable of providing device administration AAA.

Device administration can be very interactive in nature, with the need to authenticate once, but authorize many times during a single administrative session in the command-line of a device. A router or switch may need to authorize a user’s activity on a per-command basis. TACACS+ is designed to accommodate that type of authorization need.   As the name describes, TACACS+ was designed for device administration AAA, to authenticate and authorize users into mainframe and Unix terminals, and other terminals or consoles.

TACACS+ communication between the client and server uses different message types depending on the function. In other words, different messages may be used for authentication than are used for authorization and accounting. Another very interesting point to know is that TACACS+ communication will encrypt the entire packet.

RADIUS

Remote Access Dial-In User Service (RADIUS) is an IETF standard for AAA. As with TACACS+, it follows a client / server model where the client initiates the requests to the server. RADIUS is the protocol of choice for network access AAA, and it’s time to get very familiar with RADIUS. If you connect to a secure wireless network regularly, RADIUS is most likely being used between the wireless device and the AAA server. Why? This is the case because RADIUS is the transport protocol for Extensible Authentication Protocol (EAP), along with many other authentication protocols.

Originally, RADIUS was used to extend the authentications from the layer-2 Point-to-Point Protocol (PPP) used between the end-user and the Network Access Server (NAS), and carry that authentication traffic from the NAS to the AAA server performing the authentication. This allowed a Layer-2 authentication protocol to be extended across layer-3 boundaries to a centralized authentication server.

RADIUS has evolved far beyond just the dial up networking use-cases it was originally created for. Today it is still used in the same way, carrying the authentication traffic from the network device to the authentication server. With IEEE 802.1X, RADIUS is used to extend the layer-2 Extensible Authentication Protocol (EAP) from the end-user to the authentication server.

There are many differences between RADIUS and TACACS+. One such difference is that authentication and authorization are not separated in a RADIUS transaction. When the authentication request is sent to a AAA server, the AAA client expects to have the authorization result sent back in reply.

RADIUS vs. TACACS+

Given all you have just read about RADIUS being designed for network access AAA and TACACS+ being designed for device administration I have a few more items to discuss with you.  Such as designing a solution like ACS that is going to handle both TACACS+ and RADIUS AAA.

I have personally been a user of Cisco's ACS product since it was called "Easy ACS", which was written by a brilliant colleague of mine, Chris Murray, who I look up to daily!  I love the product and I have personally configured it in critical environments to perform both Network Access and Device Administration AAA functions.  

Device Administration and Network Access policies are very different in nature.  With Device Admin, you are creating a policy that dictates privilege-level, and command-sets (i.e.: what commands is this admin user permitted to run on the device.).  With network access, you will assign VLANs, Security Group Tags, Access-Control-lists, etc.  The network access policy really cares about attributes of the endpoint such as its profile (does it look like an iPad, or a windows laptop) and posture assessments.  Therefore, the policies will always be administered separately, with different policy conditions and very different results. 

As a direct extension to the different policies, the reporting will be completely different as well.  Network Access reporting is all about who joined the network, how did they authenticate, how long were they on, did they on-board, what types of endpoints are on the network, etc.  Device Admin reports will be about who entered which command and when.  

Now, in my 20+ years in this industry (I am getting old), I have never designed an ACS solution where the same ACS servers were being used for both RADIUS and TACACS+ primarily.  A set of ACS servers would exist primarily for RADIUS and another set of servers for TACACS+. In the event of a failure, the TACACS+ boxes could of course handle the RADIUS authentications and vice-versa, but when the service is restored, it should switch back to being segmented as designed.

Why would we design this way?  Because we certainly don't want a network user, say John Chambers (CEO of Cisco Systems) trying to logon to his wireless network and the RADIUS server not answering before it times out - due to being so busy crunching data related to "is Aaron allowed to type show ?" and "is Aaron allowed to type show interface ?", etc..  You could theoretically cause a network denial of service (DoS) because of all the chattering & constant authentication requests coming from Device Admin AAA.

Is this a bit paranoid?  Probably.  But it's still a possibility.  

With all that in mind, do you still feel that your Network Access Control solution is the right place for Device Administration AAA?  

Well it doesn't seem to matter what I think, because Cisco has publicly stated that TACACS+ will come to ISE at some point.  But at least I have this blog to use as a soapbox to stand on & a bullhorn to shout into to express my personal feelings on the subject, and hopefully provide you with a bit of an education on the topic at the same time.

Until next time!  

-Aaron