The state of TACACS+

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