The state of TACACS+
mysidia at gmail.com
Mon Dec 30 23:42:33 UTC 2013
On Mon, Dec 30, 2013 at 8:11 AM, Javier Henderson <javier at kjsl.org> wrote:
Given the problem of remote auth; the restriction of choice of protocols
is dictated by what protocols the relying party device supports.
This is the problem: You are at the mercy of your router vendor, to
support the authentication protocol functionality. Things are
workable, but in a sad state.
Obviously, providing highly robust, highly secure remote authentication, is
not a high priority among the router vendors. They pay lip service to
the whole thing.
In many cases you might be better off with local auth.
How do you feel about having to wait 30 seconds between every command you
enter to troubleshoot, to fail to the second server, if the TACACS or
RADIUS system is nonresponsive, because the dumb router can't remember
which TACACS servers are up and which ones are down, and always tries the
first one in the list first? At least RADIUS has the concept of a
"dead timer" :)
By all rights; routers should be implementing authorization using LDAP
over TLS, with a locally cached persistent copy of the directory and
credentials (so users can still log in, and their command exec rights
cached, in case of network outages)..
and authentication with either user SSH public key published in LDAP,
Kerberos/GSSAPI with Smartcard and other 2factor auth/OTP support, or
LDAP BIND using SASL.
RADIUS and TACACS+ are what you get, because they've been there forever,
and frequently enough deemed "good enough".
Some routers have limited Kerberos support; although, usually, not
support for Kerberos ticket forwarding SPNEGO / Negotiate authentication
using GSSAPI over SSH.
(Over encrypted Telnet, Yes)
RADIUS and TACACS+, without IPSEC or TLS encapsulation of all the traffic
are both highly insecure by today's standards, and in theory should not
Unfortunately; on many network devices, these are your only native
central authentication options!
The network should be designed so such connections are not allowed to cross
an untrusted Layer 2 domain.
If an attacker can sniff auth traffic --- TACACS+ is particularly
susceptible to decryption of the entire session including user credentials,
whereas RADIUS is particularly susceptible to the possibility of
Depending on the router vendor; the available functionality with each
Cisco is most noted for providing rich functionality over TACACS+ for shell
authorization and accounting,
and providing very limited RADIUS support.
It is not that RADIUS is limited --- its that your device vendor's RADIUS
featureset is limited -- which, for all intents and purposes, means,
the features available to you are more limited, if you use such gear.
> On Dec 30, 2013, at 9:01 AM, Christian Kratzer <ck-lists at cksoft.de> wrote:
> > Hi,
> > it is with radius afaik ...
> RADIUS does not support command authorization or accounting.
RADIUS protocol supports accounting; and there is no reason RADIUS
start-stop accounting events cannot be sent for every shell command ---
this is not a protocol limitation, this is a device implementation
Some devices can provide per-command authorization by embedding the command
being run in an Access-Request.
RADIUS protocol response messages can encapsulate any attribute-value pair
that can be sent in a TACACS response.
using Vendor-specific attributes.
There is a restriction on IOS devices, that arbitrarily forbids certain
vendor-specific Attribute-value pairs
from being encapsulated in the RADIUS reply message; per-command
authorization is among prevented
software capabilities of the router, not a limitation of the RADIUS
' cisco-avpair = "shell:cmd=show"
would do the trick to authorize the "show" command. except that there is a
tiny note for the commands "cmd" and "cmd-arg"
saying that they cannot be used for encapsulation in the Vendor-Specific
These two are the ONLY ones.'
More information about the NANOG