ASIA 

About 
SECURE NETWORK ACCESS This blog explains difficult concepts in the
By Aaron Woland, Contributor, Network World Network Access Control world and discusses
27 OCTOBER 2014 9:08 SGT all things related to security and identity,
with emphasis on Cisco’s Identity Services
Engine (ISE)

OPINION

RADIUS versus TACACS+

An explanation and comparison of RADIUS and TACACS+ for
Authentication, Authorization and Accounting (AAA).

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+

RADIUS TACACS+

UDP: 1812 & 1813

Protocol and Port(s) Used TCP: 49
-or- UDP: 1645 & 1646

Encryption Encrypts only the Password Field Encrypts the entire payload
Authentication & Combines Authentication and Separates Authentication &
Authorization Authorization Authorization

Primary Use Network Access Device Administration

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

Next read this:

9 career-boosting Wi-Fi certifications

What is MPLS, and why isn't it dead yet?

11 ways to list and sort files on Linux

5 free network-vulnerability scanners

How-to measure enterprise Wi-Fi speeds

Aaron Woland, CCIE No. 20113, is a Principal Engineer at Cisco Systems. His primary job
responsibilities include Secure Access and Identity deployments with ISE, solution enhancements,
standards development, and futures.
The opinions expressed in this blog are those of Aaron Woland and do not necessarily represent those of
Cisco Systems.

Follow 👤 ✉  