The state of TACACS+

Mon Dec 30 10:06:48 UTC 2013

Ever since first using it I've always liked tacacs+.  Having said that 
I've grown to dislike some things about it recently.  I guess, there 
have always been problems but I've been willing to leave them alone.

I don't have time to give the code a real deep inspection, so I'm 
interested in others thoughts about it.  I suspect people have just left 
it alone because it works.  Also I apologize if this is too verbose or 
technical, or not technical enough, or just hard to read.

History:

TACACS+ was proposed as a standard to the IETF.  They never adopted it 
and let the standards draft expire in 1998.  Since then there have been 
no official changes to the code.  Much has happened between now and 
then.  I specifically was interested in parsing tac_plus logs 
correctly.  After finding idiosyncrasies I decided to look at the source 
and the RFC to see what was really happening.

Logging, or why I got into this mess:

In the accounting log, fields are sometimes logged in different order.  
It appears the client is logging whatever it receives without parsing it 
or modifying it.  That means the remote system is sending them in 
different orders, so technically the fault lies with them.  However, it 
seems too trusting to take in data and log it without looking at it.  
This can also cause issues when you send a command like (Cisco) "dir 
/all nvram:" on a box with many files. The device expands the command to 
include everything on the nvram (important because you might want to 
deny access to that command based on something it expanded), but it gets 
truncated somewhere (not sure if it's the device buffer that is  full, 
tac_plus, or the logging part.  I might tcpdump for a while to see if I 
can figure out what it looks like on the wire) I'm not sure if there are 
security implications there.

Encryption:

The existing security consists of md5 XOR <content> with the md5 being 
composed of a running series of 16 byte hashes, taking the previous hash 
as part of the seed of the next hash.  A sequence number is used so 
simple replay shouldn't be a factor.  Depending on how vulnerable 
iterative md5 is to it, and how much time you had to sniff the traffic, 
I would think this would be highly vulnerable to chosen plaintext if you 
already have a user-level login, or at least partial known plaintext 
(with the assumption they make backups, you can guess that at least some 
of the packets will have "show running-config" and other common 
commands).  They also don't pad the encrypted string so you can guess 
the command (or password) based on the length of the encrypted data.

For a better description of the encryption you can read the draft: 
http://tools.ietf.org/html/draft-grant-tacacs-02
I found an article from May, 2000 which shows that the encryption scheme 
chosen was insufficient even then.
http://www.openwall.com/articles/TACACS+-Protocol-Security

For new crypto I would advise multiple cipher support with negotiation 
so you know what each client and server is capable of. If the client and 
server supported multiple keys (with a keyid) it would be  easier to 
roll keys frequently, or if it isn't too much overhead they could use 
public key.

Clients:

As for clients, Wikipedia lists several that seem to be based on the 
original open-source tac_plus from Cisco.  shrubbery.net has the 
"official" version that debian and freebsd use.  I looked at some of the 
others and they all seemed to derive from Cisco's code directly or 
shrubbery.net code, but they retained the name and started doing their 
own versioning.  All the webpages look like they're from 1995.  In some 
cases I think it's intentional but in some ways it shows a lack of care 
for the code, like it's been dropped since 2000.

Documentation is old:

This only applies to shrubbery.net's version.  I didn't look at the 
other ones that closely.  While all of it appears valid, one Q&A in the 
FAQ was about IOS 10.3/11.0.   Performance questions use the sparc 2 as 
a target machine.  There isn't an INSTALL or README, just the 
FAQ/CHANGES/COPYING (and a tac_plus.conf manpage), so the learning curve 
for new users is probably pretty steep.  Also there isn't a clear 
maintainer.  The best email address I found was listed in the 
tacacs+.spec file, for packaging on rpm systems.

If you hit the website they give some hints with some outdated, though 
still functional links.  And they list the official email as 
tac_plus at shrubbery.net

Conclusion:

Did everyone already know this but me?  If so have you moved to 
Kerberos?  Can Kerberos do everything TACACS+ was doing for router 
authorization?  I've got gear that only supports radius and tacacsplus, 
so in some cases I have no choice but to use one of those, neither of 
which I would trust over an unencrypted wire.  If TACACS+ isn't a dead 
end then it needs a push to bring the protocol to a new version.  There 
are big name vendors involved in making supported clients and servers.  
There should be someone invested in keeping it secure and adding features.