nanog mailing list archives
Re: The state of TACACS+
From: Scott Helms <khelms () zcorum com>
Date: Mon, 29 Dec 2014 10:22:51 -0500
Colton, Yes, that's the 'normal' way of setting it up. Basically you still have to configure a root user, but that user name and password is kept locked up and only accessed in case of catastrophic failure of the remote authentication system. An important note is to make sure that the fail safe password can't be accessed without having several people engaged so it can't be used without many people knowing. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor <colton.conor () gmail com> wrote:
We are able to implement TACAS+. It is my understanding this a fairly old protocol, so are you saying there are numerous bugs that still need to be fixed? A question I have is TACAS+ is usually hosted on a server, and networking devices are configured to reach out to the server for authentication. My question is what happens if the device can't reach the server if the devices network connection is offline? Our goal with TACAS+ is to not have any default/saved passwords. Every employee will have their own username and password. That way if an employee gets hired/fired, we can enable or disable their account. We are trying to avoid having any organization wide or network wide default username or password. Is this possible? Do the devices keep of log of the last successful username/password combinations that worked incase the device goes offline? On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake <rdrake () direcpath com> wrote: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 theextentit 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 dieswhilea session is open only accounting would be affected. That does increase the vendors/implementors work but it might be doableinphases 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 increasecomplexitytoo 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, butthesession basis of the protocol has always made that not feasible). It's possible that one of the L4 protocols Saku Ytti mentioned, QUIC orMinimaLTwould 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.-- -JHSo, 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 tohavea 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
Current thread:
- Re: The state of TACACS+ Robert Drake (Dec 28)
- Re: The state of TACACS+ Christopher Morrow (Dec 28)
- Re: The state of TACACS+ Jimmy Hess (Dec 28)
- Re: The state of TACACS+ Randy Bush (Dec 28)
- Re: The state of TACACS+ Robert Drake (Dec 29)
- Re: The state of TACACS+ Jimmy Hess (Dec 28)
- Re: The state of TACACS+ Colton Conor (Dec 29)
- Re: The state of TACACS+ Scott Helms (Dec 29)
- Re: The state of TACACS+ Colton Conor (Dec 29)
- Re: The state of TACACS+ joseph . snyder (Dec 29)
- Re: The state of TACACS+ Jared Mauch (Dec 29)
- Re: The state of TACACS+ Scott Helms (Dec 29)
- Re: The state of TACACS+ Robert Drake (Dec 29)
- Re: The state of TACACS+ Berry Mobley (Dec 29)
- Re: The state of TACACS+ Michael Douglas (Dec 29)
- Re: The state of TACACS+ Colton Conor (Dec 29)
- Re: The state of TACACS+ Michael Douglas (Dec 29)
- Re: The state of TACACS+ Tim Raphael (Dec 29)
- Re: The state of TACACS+ Scott Helms (Dec 29)
- Re: The state of TACACS+ Christopher Morrow (Dec 28)