Background: I am the technical lead on a project to unite a Fortune 100 company’s routers and switches under a unified Cisco ACS 5.x deployment. This ACS deployment actually was pre-existing and already talks to Active Directory and RSA SecureID. This organization is VERY security aware and has good reason to be but for historical reasons some of the “silos” still use local username/passwords.
Problem: The issue is while the SSH session is AES256 encrypted and the AD connection is AES 256 encrypted the password is sent in clear text inside the TACACS+ packet. Even worse, the TACACS+ packet is "encrypted" by using an MD5 hash of the "secret" and simple XOR. MUCH worse is the fact the secret cannot be kept secret at all since it is stored in plain-text equivalent type-7 in the config*. This means that I have to consider the possibility that any administrator for a particular device can trivially steal the password of any other user who logs in. This is unacceptable and I have to find a solution.
*Yes, I am aware of the Secure Reversible Storage for AAA feature. As of now it is only supported on ISR routers and slated to be initially released to switches sometime in the next 12-18 months. Realistically that means for the next 5 years I will have devices that don’t support it
What I want/need:
I need some way to secure the password (and preferably username but not required) inside the TACACS+ (or RADIUS, I don’t care) portion of the traffic. Cisco’s documentation that they “encrypt” TACACS+ traffic is a bad joke. MAYBE it wasn’t such an issue 20 years ago, but MD5 and clear text secrets are totally not acceptable in 2015 and there must be some way to adequately secure this traffic.
Things I have looked at so far:
- RFC6187 – This is supported only in the 2900/3900 ISR routers and uses a certificate to provide the RSA keys. My understanding is this will be coming to the current generation of switches over the next 6-18 months. Unfortunately there is only one commercial SSH client that supports it and OpenSSH/Putty has said they will not ever be supporting it and VanDyke (SecureCRT) never got back to me when I inquired. Overall this looks designed for exactly one client: DoD with their CAC cards and while it may be of some use it will be years before a majority of devices in the network will support it. Plus, as a practical matter if Putty and OpenSSH don’t support it it is at best a partial solution
- MSCHAPv2 – The Nexus platform and a few others supports MSCHAPv2. While not ideal (amounts to weak single DES) it is FAR better than clear text. Unfortunately other than ASA and Nexus it is not supported on IOS for admin login but is for PPP login (See RANT below).
- RSA keys – Each user already has a corporate certificate with RSA keys associated. I COULD use an LDAP server to store the public key for each user. Unfortunately the documentation for this feature only mentions that the users public keys can be stored locally, does not mention anything about storing then in LDAP. Even doing that and not tying it into AD would present real challenges, possibly meaning I have to write a gnarly script to go through each user in AD, pull the certificate out, pull the RSA keys and store them in another LDAP database (editing the AD schema is out of the question). Using local RSA keys for hundreds of users on 10K devices is not feasible.
- Direct LDAP over SSL to AD – The last reference I could find says LDAP cannot be used for vty login but only for VPN login. AGAIN see RANT below
- Krb5 – Fine print says it only works with PPP AGAIN. AGAIN see RANT below
<RANT>
NOTE: If someone proves me wrong and is able to show that despite hours of searching documentation and multiple conversations with my account team there is (in currently available IOS) a way to secure the above traffic I will print this rant out and HAPPILY eat it AND post the picture of me doing it!!! And yes I am 100% serious!
At this point I need to vent. I have a dedicated Cisco account team who I highly respect that is DEDICTED to my Company 100%. When I bring this up and ask how to solve this problem all I get back is “Meh”. NO ONE in Cisco seems to care at all and Cisco as a company hasn’t even done the easy stuff to put even a thin veneer of Security on admin logins. To wit:
- MSCHAPv2 isn’t great, but the code is already in IOS and used to secure PPP. Why would you think that PPP passwords need better protection then the admin password for the whole box? Same with LDAP.
- They support LDAP over SSL for VPN logins so the IOS code is already written, why is it not supported for admin authentication??? I would be more than happy to use LDAP over SSL for authentication and TACACS+ for authorization.
- Why not secure this traffic with PEAP-MSCHAP and PEAP-GTC? IOS already has SSL code, these are existing well known protocols and would require no changes to the TACACS+ or RADIUS server to provide modern (relatively) secure solutions. As long as server verification is enabled there is no security risk with either of these, especially when used for device admin AAA
- TACACS+ is their protocol and they have the reference client and reference server implementations. Why is it not possible to run TACACS+ over SSL? Why have they not moved to a more secure hash algorithm such as SHA256 or SCRYPT to prevent brute forcing?
- They have very limited DIAMETER support for “sectors requiring secure transfer of sensitive customer data”. What is more sensitive than the admin logins of your devices? Why not become a leader in the industry by supporting an existing open standards secure protocol then BEAT THE COMPOTITION OVER THE HEAD with it when they only support insecure legacy protocols?
- Why is there not a champion in Cisco fighting for stuff like this? All I get from my account team is that the BU’s don’t want to take time out for doing cool stufflike “cloudy whatever” or “SDN flavor of the week” that MIGHT be used for 5% of their clients and do something like this to help secure the other 95% of their stuff?
I really don’t get it that I am the only person who seems to be saying this stuff but partly I blame Cisco. Their document touts how “TACACS encrypts the whole packet” without mentioning the encryption is 20 years old, uses a hash considered trash by today’s standards, the passwords are stored in clear text , and the coup de grace: that once you have the secrets and some traffic Wireshark will give you cleartext passwords all day long!
We are 15 years into the 21’st century and I would have thought we would have gotten past using insecure protocols written when AOL CD’s were a major thing.
</RANT>
