The state of TACACS+

Mon Dec 30 13:48:53 UTC 2013

I don't think radius nor kerberos nor ssh with certificates supports
command authorization, do they?
On Dec 30, 2013 6:33 AM, "Saku Ytti" <saku at ytti.fi> wrote:

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