Firewalls acting as AAA clients rely
on an authentication protocol to communicate with the AAA server and
determine User Identity. After
subjecting the user to centralized authentication, a NAS typically
receives a set of access control parameters, enforces them locally, and
optionally accounts for user activity. Now you face the challenge of
selecting RADIUS or TACACS+ to accomplish the task of creating
Identity-based security policies.
Traditional comparisons between RADIUS and
TACACS+ discuss topics such as transport layer protocol used (UDP or
TCP), what portions of the packets are encrypted (only password or the
complete payload), and decoupling of the authentication and
authorization processes. Deciding if any of the previous choices is the
best path to follow is subjective and controversial. For example, RFC
2865 has a section dedicated to justify “Why UDP ?”,
whereas many customers select TACACS+ because it is carried over TCP, a
protocol that was designed with reliable delivery and retransmission as
The decision process is based on the suitability of
the protocol to deliver the two main categories of Identity-based
Considering that authorization data is embedded in the authentication
response sent by the RADIUS server, this protocol is more appropriate
for delivering attributes that remain valid for the duration of the
user session rather than authorizing each activity individually. RADIUS
is ideal for controlling access to network-based services requested by regular users who connect via dial-up, VPN, or Dot1X (for both wired and wireless environments).
TACACS+: Has proved effective to control administrative access to network devices because EXEC sessions (requests for execution of commands) are interactive in nature. On a typical TACACS+ session, each attempt of an admin user to issue commands on a NAS device is authorized individually.
RADIUS and TACACS+ client functions are
simultaneously available on Cisco firewall products, therefore
reinforcing the approach of selecting each protocol for the category of
task to which it is more suited.
You can confirm after
analyzing several examples that while TACACS+ is optimized for
authorization and accounting of commands, RADIUS is flexible about the
attributes it can send back to the NAS to control a noninteractive
It deserves special mention the fact that RADIUS is
standardized by the IETF and supports Vendor Specific Attributes (VSA),
allowing an always expanding universe of network services that can be
The study of
RADIUS and TACACS+ is contextualized in the following way:
RADIUS: Employed to control access through the firewall using mechanisms such as Cut-through Proxy in the ASA family or the correspondent Auth-Proxy
on the IOS Firewall. After authenticating the user with one of these
features, authorization ACLs can be downloaded via RADIUS to the NAS,
therefore specifying traffic allowed to flow through the firewall.
TACACS+: Used to authenticate potential admin users who request access to
the firewall devices, individually authorizing the command execution
attempts. This can be achieved in a scalable manner by creating
authorization profiles known as Shell Command Authorization Sets
on Cisco Secure ACS. A natural follow-on to command authorization is
the accounting of allowed commands and registering the unauthorized
attempts of issuing commands. This is valuable for configuration change
control and contributes to minimize the operational risk in the network.
Cisco Secure ACS implements simultaneously
the RADIUS and TACACS+ server functions, therefore enabling the
security administrator to use this product to define access control
policies for both regular and admin users.