The state of TACACS+

Robert Drake rdrake at direcpath.com
Sun Dec 28 23:02:49 UTC 2014


Picking back up where this left off last year, because I apparently only 
work on TACACS during the holidays :)


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.

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.

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

So, here is my TACACS RFC christmas list:

1.  underlying crypto
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