The state of TACACS+
christopher.morrow at gmail.com
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
> 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
> 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
> 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.
More information about the NANOG