The state of TACACS+

Mon Dec 30 11:28:42 UTC 2013

On (2013-12-30 05:06 -0500), Robert Drake wrote:

> TACACS+ was proposed as a standard to the IETF.  They never adopted
> it and let the standards draft expire in 1998.  Since then there

If continued existence of TACACS+ can be justified at IETF level, in parallel
with radius and diameter, I have some interest in the subject and would be
ready to work with draft.

> Encryption:
> 
> 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

It seems encryption is your only/major woe? Personally I don't like how we
need to keep reimplementing crypto per-application level. We're living in a
world where crypto should be standard for all connection, not application
issue. There are some solutions to this like BEEP framework or new L4 protocol
like QUIC and MinimaLT, any of which I think would be workable as mandatory
transport for TACACS.

> Clients:
> 
> "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

There is also commercial server 'radiator' which does radius and tacacs
amongst others.

> Did everyone already know this but me?  If so have you moved to

I think I missed the key revelation. The naive encryption? The limited amount
of software available?

> Kerberos?  Can Kerberos do everything TACACS+ was doing for router

I think from networker point of view, it's radiator or tacacs, if it has to
work today without new software. And if it can require new software, it can be
pretty much arbitrary new protocol, if sound justification can be found.

-- 
  ++ytti