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" <[email protected]> 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 > >
