The state of TACACS+
Jared Mauch
jared at puck.Nether.net
Mon Dec 29 15:45:49 UTC 2014
On Mon, Dec 29, 2014 at 09:32:51AM -0600, Colton Conor wrote:
> Scott,
>
> Thanks for the response. How do you make sure the failsafe and/or root
> password that is stored in the device incase remote auth fails can't be
> accessed without having several employees engaged? Are there any mechanisms
> for doing so?
Yes, this is possible as you can prevent the last resort username
being used by having your AAA try tacacs+ first and having a non-overlapping
username so it's rejected if t+ is operational.
You should use username blah secret magic vs password as well
to leverage md5 vs the reversable process.
> My fear would be we would hire an outsourced tech. After a certain amount
> of time we would have to let this part timer go, and would disabled his or
> her username and password in TACAS. However, if that tech still knows the
> root password they could still remotely login to our network and cause
> havoc. The thought of having to change the root password on hundreds of
> devices doesn't sound appealing either every time an employee is let go. To
> make matters worse we are using an outsourced firm for some network
> management, so the case of hiring and firing is fairly consistent.
You can automate the login/change with scripting leveraging the
clogin tool part of rancid. If you have a proper inventory of these devices
and they are in rancid, it's easy to do clogin -x /tmp/commands `cat routerlist`
- Jared
> On Mon, Dec 29, 2014 at 9:22 AM, Scott Helms <khelms at zcorum.com> wrote:
>
> > 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 at 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 at 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 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
> >> >
> >> >
> >>
> >
> >
--
Jared Mauch | pgp key available via finger from jared at puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.
More information about the NANOG
mailing list