08-13-2015 06:52 PM - edited 03-10-2019 10:58 PM
Background: I am the technical lead on a project to standardize router and switch logins for a Fortune 100 company based on Cisco ACS 5.7. The Cisco ACS installation was pre-existing and used by one of the (many) silos in the organization and is now being expanded to encompass roughly ~10K devices. This is a (mostly) Cisco shop. 80% of the devices are Cisco IOS based with a few Nexus and a few outposts of Brocade and Extreme. The ACS installation is already AD integrated as well as integrated using native RSA SDI to RSA ACE servers for devices requiring two-factor authentication.
Problem: The problem is that while the SSH traffic from client to device is AES256 encrypted via RSA keys and the AD traffic from ACS to AD domain controllers is AES256 encrypted w/ Kerberos, the only thing protecting the password (or two factor PIN+token code) in transit between the network devices and the ACS server is a crappy MD5 hash based encryption created when AOL CD’s were a thing. To make matters worse, the “secret” isn’t really a secret at all since it is stored in plain-text equivalent type-7* in the configuration.
* I know about Secure Reversible Passwords for AAA however it is currently only available for ISR routers and code for switches is at least 6 months out so it is at least 1-2 years out before it will be on any significant portion of the network devices
Already, one of my admin users flipped out when he discovered that putting the secret into Wireshark decrypted the passwords of EVERYONE logging into the device. This also critically undermines two-factor since if you get the PIN all you need is to "borrow" a token to login as someone else and everyone knows someone is bound to leave their token in a desk drawer.
What I need is a way to protect the login password in transit through TACACS+ from two things:
What I have already looked at:
Note: It would be acceptable not to use RADIUS/TACACS for authentication but to use them for the authorization part.
Solution requirements: Whatever the solution is should protect the password between the device and the authentication source. Preference is at least 3DES/AES but at this point I would take anything. I also have great leeway to design this. If I need a standalone LDAP DB to store public keys, so be it. I am handy with Bash, OpenSSL, python, Windows, and Unix/Linux so if someone can even point me in a general direction I should be able to get something going! Also, I would settle for a 90% solution, i.e. works for everything but resource accounts which still use standard username/password.
<RANT>
NOTE: This is literally keeping me awake at night. If there is a solution I don't know about that I can deploy today I will eat this rant and post pictures and be happy to do it! I really dont think secure admin logins is asking to much!
Here is the part where I vent. Basically this problem has been vexing me for 6 weeks. I have a 100% dedicated Cisco account team that I greatly respect and trust but I get the distinct feeling NO ONE in Cisco cares that the most critical authentication traffic on the network is being secured using crappy MD5 hash’s with the keys stored IN CLEAR TEXT. When I asked about getting the MSCHAPv2 added to admin logins the response I got was “Meh, the business units don’t want to be distracted from implementing cloudy this, SDN that, or IoT the other to actually create a secure administrative method.” The really galling part is this should not be rocket science. LDAP over SSL is already in IOS, MSCHAPv2 is already in IOS and as I recall PEAP-MSCHAPv2 as a supplicant is already in IOS. ACS already supports all these and there are no changes required to the TACACS+ or RADIUS protocols.
Of course, this begs the question of why Cisco doesn’t step up and support a truly secure protocol. They support DIAMETER in a few verticals (where the protection of client information is critical) but why isn’t the protection of large enterprise admin logins as critical? Why hasn’t Cisco moved TACACS+ to a secure HASH algorithm (SHA256 or SCRYPT) since it is their protocol and they own the reference Client and server implementation? Why hasn’t Cisco created TACACS over SSL? The worst part is if Cisco did fix this they could use it as a club to beat their competition into submission: “Those Brocade/Extreme/HP guys, they don’t support any way to actually secure your password, they still use PAP/ASCII”.
Please someone explain to me a rational reason we are using early/mid 1990 ideas to secure the critical networks of the 21’st century???
</RANT>