The state of TACACS+
Christopher Morrow
morrowc.lists at gmail.com
Mon Dec 29 03:21:46 UTC 2014
On Sun, Dec 28, 2014 at 6:02 PM, Robert Drake <rdrake at direcpath.com> wrote:
> Picking back up where this left off last year, because I apparently only
> work on TACACS during the holidays :)
avoiding relatives? :)
>
>
> On 12/30/2013 7:28 PM, Jimmy Hess wrote:
>>
>> Even 5 seconds extra for each command may hinder operators, to the extent
>> it would be intolerable; shell commands should run almost
>> instantaneously.... this is not a GUI, with an hourglass. Real-time
>> responsiveness in a shell is crucial --- which remote auth should not
>> change. Sometimes operators paste a buffer with a fair number of
>> commands, not expecting a second delay between each command --- a
>> repeated delay, may also break a pasted sequence.
>>
>> It is very possible for two of three auth servers to be unreachable, in
>> case of a network break, but that isn't necessary. The "response
>> timeout" might be 5 seconds, but in reality, there are cases where you
>> would wait longer, and that is tragic, since there are some obvious
>> alternative approaches that would have had results that would be more
>> 'friendly' to the interactive user.
>>
>> (Like remembering which server is working for a while, or remembering
>> that all servers are down -- for a while, and having a 50ms timeout,
>> with all servers queried in parallel, instead of a 5 seconds timeout)
>
> I think this needs to be part of the specification.
>
> I'm sure the reason they didn't do parallel queries was because of both
> network and CPU load back when the protocol was drafted. But it might be
> good to have local caching of authentication so that can happen even when
> servers are down or slow. Authorization could be updated to send the
> permissions to the router for local handling. Then if the server dies while
> a session is open only accounting would be affected.
Juniper, at least, does the authorization cache on the device trick...
(or really scoping of commands/areas a user is permitted via a local
cache file in /var/tmp)
>
> That does increase the vendors/implementors work but it might be doable in
> phases and with partial support with the clients and servers negotiating
> what is possible. The biggest drawback to making things like this better is
> you don't gain much except during outages and if you increase complexity too
> much you make it wide open for bugs.
and I wonder what percentage of 'users' a vendor has actually USE tac+
(or even radius). I bet it's shockingly low...
> Maybe there is a simpler solution that keeps you happy about redundancy but
> doesn't increase complexity that much (possibly anycast tacacs, but the
> session basis of the protocol has always made that not feasible). It's
does it really? :)
> possible that one of the L4 protocols Saku Ytti mentioned, QUIC or MinimaLT
> would address these problems too. It's possible that if we did the
> transport with BEEP it would also provide this, but I'm reading the docs and
> I don't think it goes that far in terms of connection assurance.
>
> So, here is my TACACS RFC christmas list:
>
> 1. underlying crypto
juniper, cisco, arista, sun, linux, freebsd still can't get TCP-AO working...
they don't all have ssl libraries in their "os" either...
Getting to some answer other than: "F-it, put it i clear text" for new
protocols on routers really is a bit painful... not to mention ITARs
sorts of problems that arise.
-chris
> 2. ssh host key authentication - having the router ask tacacs for an
> authorized_keys list for rdrake. I'm willing to let this go because many
> vendors are finding ways to do key distribution, but I'd still like to have
> a standard (https://code.google.com/p/openssh-lpk/ for how to do this over
> LDAP in UNIX)
> 3. authentication and authorization caching and/or something else
More information about the NANOG
mailing list