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