Re: The state of TACACS+

[Jonathan Lassoff <jof () thejof com>]

I don't understand why vendors and operators keep turning to TACACS. It
seems like they're often looking to Cisco as some paragon of best security
practices. It's a vulnerable protocol, but some times the only thing to
choose from.

One approach to secure devices that can support only TACACS or RADIUS:
Deploy a small embedded *nix machine (Soekris, Raspberry Pi, etc.) that
runs a RADSEC (for RADIUS) or stunnel (for TACACS) proxy. Attach it to a
short copper with 802.1q, take weak xor'ed requests in on one tag, wrap the
requests with TLS, and forward out another tag towards your central AAA box.

Kerberos or more certificate-based SSH on routers would be super.
SSH with certificates is nice in that it allows authenticators out in the
field to verify clients "offline", without needing a central AAA server.
However, the tradeoff is that you must then make sure all the clocks are
correct and in-sync, and root certificates are verified.




On Mon, Dec 30, 2013 at 2:06 AM, Robert Drake <rdrake () direcpath com> wrote:

> 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 () 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.