cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

1034
Views
0
Helpful
1
Replies
Highlighted
Beginner

How to Secure admin credentials when using TACACS+/RADIUS

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:

  • Brute force attack on the MD5 hash – MD5 was considered weak in 1996 and by 2010 was considered “cryptographically broken”.  Additionally, both the TACACS+ and RADIUS protocols have other weaknesses that have not been addressed in 20 years. With the rise of cloud, FPGA and GPU-based MD5 crackers I just cannot see how anything based on MD5 can be considered secure, especially for something as critical as enterprise networks admin credentials
  • “Insider” threats – The fact that anyone with access to ANY device could steal anyone else’s password who they could get to login is extremely concerning. Look at what happened in San Francisco (http://www.techrepublic.com/blog/it-security/who-is-really-to-blame-for-the-san-fran-network-lockout/) and imagine what he could have done with more access then just his own!  

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.

  • RFC1687 – RFC1687 (Certificate authentication for SSH) is interesting but, even were it implemented in most IOS devices today (only ISR G2’s support it today) it could not be the whole solution for the simple fact that only one SSH client supports it and more importantly OpenSSH and Putty never will unless the OpenSSH developers have a change of heart. I also reached out to Van Dyke (SecureCRT) but have never heard back from them. This is honestly geared to exactly one client: The US DoD with their CAC cards. I understand code to support it on switching platforms is forthcoming in the 6-12 month timeframe but at best it will be 3-5 years before the network devices will have widespread support for it due to lag upgrading IOS’s, particularly since it will require going to a whole new IOS version.
  • RSA Keys – Cisco IOS does support RSA keys but I can find NO document that shows how to do it in a centralized manor. If someone can show me how to use LDAP (or DNS???) to retrieve public keys that might work. It would be gnarly (editing AD schema is verboten) but in theory I could do a standalone LDAP installation with a daily import of all user certificates, extract the RSA public keys using OpenSSL and then store them in  an anonymously searchable LDAP server. Ugly but doable.
  • Krb5- This is SCARY but IOS does support Kerberos. However it does not appear that ANYONE on the Internet is willing to fess up to ever having used krb5 against AD as an authentication source.  There are no “cookbook” style guides to making it work against AD. Further, I am not even sure it can be used with SSH and it looks like it might only support single DES which isn’t really good enough.
  • LDAP/LDAP over SSL – This would work (probably) but is not supported for Admin logins
  •  MSCHAPv2 – This isn’t great (amounts to single DES via Moxie Marlinspikes hack of the protocol) but it would be much better. Unfortunately it is only supported for PPP logins on IOS. It is supported via RADIUS on Nexus.

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>

1 REPLY 1
Highlighted
Advisor

Based on the fact that adequate security can not be provided for authentication sessions; I guess you could turn you attention to what to do to mitigate the issue.  One Time Passwords is the only solution that really stands out to me.

Then even if the session password is extracted, it can't be reused since the OTP would have already rolled.