Back In Time

For today's post, we're going back in time. Come with me for a trip down memory lane to January 1997...

• Bill Clinton just had his second inauguration
• Jerry Maguire is the #1 film at the box office (and Tom Cruise takes the Golden Globe for best actor - musical or comedy)
• NBC has the Top 5!?!? most-watched shows with ER, Seinfeld, Friends, Naked Truth, and Single Guy.
• The Green Bay Packers, led by some guy named Brett Farve, defeat the New England Patriots in Super Bowl XXXI. This was before Tom Brady.
• Florida, coached by the legendary Steve Spurrier, is crowned national champion in college football, with Danny Wuerffel taking the Heisman trophy.
• Toni Braxton was owning the pop charts for Un-Break My Heart. The top rock song is One Headlight by The Wallflowers.
• The (original) Final Fantasy VII releases in Japan, eventually becoming the best-selling game of 1997
• Half of all U.S. homes with Internet access are using America Online¹

And last but certainly not least, Cisco Systems drops a Draft RFC for the TACACS+ protocol.

The TACACS-what?

Ah yes, the Terminal Access Controller Access Control System Plus: Besides totally sounding like something sold at RadioShack, the Terminal Access Controller Access Control System Plus is responsible for, get this, controlling access.

If you recall back to my first article I mentioned that routers are devices responsible for forwarding network traffic based on IP addresses. There are all sorts of networking devices, including switches, firewalls and wireless access points. A single organization could have tens to hundreds of these devices, making at least some form of centrallized management a requirement.

TACACS+ is a form of AAA system, and it does a few things that are considered critical in the cybersecurity space.

• Authentication: Validates that a user is who they say they are, usually by requiring a password and checking it against a centralized database. In the real world, you might use an ID card (such as a driver's license) to prove your identity.
• Authorization: Validates that you are allowed to do what you are trying to do. There are various levels of privilege on a system: One user might only be allowed to view the routing table, while another user might be allowed to change device configuration. Sticking with our drivers license allegory, a Class C license allows driving non-commercial vehicles, but you need a Class A CDL to drive a tractor-trailer.
• Auditing: Captures all activity performed by a user. On a network device, this would capture when a user logged in and what commands were ran. This is similar to some companies using GPS trackers on company vehicles to track a driver's route and confirm they aren't exceeding the speed limit. This is also known as accounting.

To accomplish this, TACACS+ provides a central server that can be thought of as an arbiter. Clients send administrative requests to the TACACS+ server, which either approves or denies the request based on policy.

This is nice. Now, if a network administrator leaves the company, you only have to disable their access in one place, as opposed to having to touch potentially hundreds of devices. In addition, you can have multiple policies configured, one for read-only access², another for your network management system, and maybe a third for your administrator, allowing the implementation of least privilege.

The major calling card for TACACS+ is that traffic between the client devices and the TACACS+ server is encrypted, using a shared secret key. This is pretty crucial, at best intercepting this traffic will leak information about the network and at worst could leak credentials (i.e. the keys to the kingdom). The other major competing protocol is RADIUS, and it only encrypts the password, so clearly TACACS+ is a major step up.

But TACACS+ was also proposed in 1997, so does that encryption hold up to a modern context? Before we take a look at the cryptographic guarantees provided by TACACS+, let's define strong encryption.

Strong Encryption

Encryption is a means to guarantee the confidentiality of information. But is all encryption created equal?

Of course not, we have historical schemes like the Caesar cipher and the Enigma and even some more modern computational encryption schemes like DES which are completely broken by modern standards.

So what do we mean by strong encryption?

The National Institute of Standards and Technology bases their definition of strong encryption on the amount of work that is required to break the scheme. Let's take AES as an example. If we take the "weakest" key size of 128 bits and using a brute-force attack (i.e. try every single key til you find the right one), to have a 50% chance of breaking the encryption you would have to try at least half the keys. How long does this take to find the correct key?

This takes 2^127 operations, which is a really, really big number. Ever heard of a Undecillion? It's bigger than one of those. To brute force a 128-bit AES key takes 1 billion billion years. No, that's not a typo, Our sun will expand to a red giant and consume the Earth well before that AES-128 key is cracked using brute-force, barring some major computational advances.

There are other goals of strong cryptography (we also care about integrity as well), but when coming across any modern use of the term encryption, it should at least meet the NIST definition.

TACACS+ is Encrypted?

So is TACACS+ "encrypted"? According to many reputable sources, including Cisco themselves, it is!

• From Cisco: "TACACS+ encrypts the entire body of the packet but leaves a standard TACACS+ header. Within the header is a field that indicates whether the body is encrypted or not. For debugging purposes, it is useful to have the body of the packets unencrypted. However, during normal operation, the body of the packet is fully encrypted for more secure communications.""
  • And from a configuration guide for Cisco IOS XE 16: "The TACACS+ protocol provides authentication between the network access server and the TACACS+ daemon, and it ensures confidentiality because all protocol exchanges between a network access server and a TACACS+ daemon are encrypted."
• From Wikipedia: "TACACS+ encrypts all the information mentioned above and therefore does not have the vulnerabilities present in the RADIUS protocol."
• From Palo Alto: "TACACS+ encrypts usernames and passwords, making it more secure than RADIUS, which encrypts only passwords."
• From PortNox: "One unique feature TACACS offers the encryption of an entire packet beyond the header...TACACS+ offers encryption for all packets and ensures higher security.*³

So case closed, right? It's in the official documentation! TACACS+ is encrypted, we can trust it to protect our critical infrastructure, networking devices, account passwords, and activity. Let's throw a bunch of money at a TACACS+ system and sleep sound at night knowing our device administration is safe.

Or we could talk more.

TACACS+ "Encryption": The Deets

The TACACS+ protocol includes a header, which provides the version number, a sequence number, various flags (such as whether the packet is encrypted), a session_id, and the length of the data. The header is always sent in clear text. The details of the packet header is presented here mainly to show that the session_id, the seq_no, and the version are contained in cleartext in the packet.

    1 2 3 4 5 6 7 8  1 2 3 4 5 6 7 8  1 2 3 4 5 6 7 8  1 2 3 4 5 6 7 8

    +----------------+----------------+----------------+----------------+
    |major  | minor  |                |                |                |
    |version| version|      type      |     seq_no     |   flags        |
    +----------------+----------------+----------------+----------------+
    |                                                                   |
    |                            session_id                             |
    +----------------+----------------+----------------+----------------+
    |                                                                   |
    |                              length                               |
    +----------------+----------------+----------------+----------------+

The data section could be one of three different types of packets.

• START: Sent only by the client, it describes the authentication performed and includes the username.
• CONTINUE: Sent only by the client, it normally defines a command entered by an administrative user
• REPLY: Sent only by the server as a response to the START or CONTINUE packets.

We'll omit the details of these packets for brevity.

Finally, we have what the Draft RFC refers to as the creation of the pseudo one-time pad. This is done by taking the key, which is pre-shared between the server and the client and never sent over the network, along with the session_id, seq_no, and version which are all available in the packet header, and feeding it as the input to the MD5 hash function. Subsequent blocks feed the previous hash value into the calculation, as defined below:

   MD5_0 = MD5{session_id, key, version, seq_no}

   MD5_1 = MD5{session_id, key, version, seq_no, MD5_0}

    ....

   MD5_n = MD5{session_id, key, version, seq_no, MD5_n-1}

With all the preliminaries out of the way, we can finally define the TACACS+ encryption method. The packet header is sent in the clear, and is not encrypted. We take the output of the MD5 hash function defined above, and then XOR with the plain text (i.e. the data packet header) to receive the cipher text. Since the MD5 hash function is 16 bytes long, it's effectively a block cipher. The process iterates to the first, second, and third block, until there is no more data to encrypt. Decryption simply reverses the process, taking the ciphertext and the MD5 hash and, running XOR, and receiving the plaintext.

Note that TACACS+ was developed during a time when cryptography export restrictions were still very much in place, and many Cisco devices required a special firmware image and/or license to enable cryptographic payloads. MD5 was never a part of the export restrictions, and that may explain why it was chosen for TACACS+.

Now that we've defined the TACACS+ encryption process, let's look at some attacks against the scheme.

Attacks vs. TACACS+ "Encryption"

The most glaring issue with TACACS+ "encryption" is that it utilizes the MD5 hash function. MD5, and other hash functions, effectively takes in an arbitrary length input and compresses it to a smaller length string. If you've never played with MD5 before, try typing a few strings into CyberChef.

A cryptographic hash function needs to fulfil a property known as collision resistance. It should be computationally infeasible (i.e. take a really long, sun exploding amount of time) to find two inputs that hash to an identical output.

MD5 was defined in 1992, and by 1996, flaws were already known with MD5. By 2008, MD5 was considered cryptographically broken.

Nowadays, if you can sniff a TACACS+ payload, you can recover the secret key using some helpful scripts along with hashcat. Once the password is recovered, Wireshark will happily decode the communications. Game Over.

So is the use of MD5 the only cardinal sin when it comes to TACACS+. Not quite. The OpenWall project posted a scathing analysis back on May 30, 2000. The coup-de-grace was administered by RFC 8907:

The TACACS+ protocol does not include a security mechanism that would meet modern-day requirements. These security mechanisms would be best referred to as "obfuscation" and not "encryption", since they provide no meaningful integrity, privacy, or replay protection. An attacker with access to the data stream should be assumed to be able to read and modify all TACACS+ packets.

So there we have it. By our modern definition TACACS+ doesn't use encryption and provides no meaningful protection.

So, problem solved?

Not really. You're still very hard pressed to find this information in an easily digestible form on Cisco's website, and as you saw above, vendor documentation and even cybersecurity certification materials still refer to the protocol as secure.

It's technically possible to wrap TACACS+ packets with IPSec, but that's more of a mitigation strategy than a fix to the TACACS+ protocol itself.

Per a draft RFC published March 31, 2022 TACACS+ encryption was finally deprecated, but it should be noted that the RFC has expired. A new draft RFC published June 29, 2023 defines the obsolescence of TACACS+ obfuscation and recommends TLS 1.3 to provide protection for TACACS+ packets.

So hey, maybe Cisco will finally get around to updating their 25 year old protocol. But it seems they have bigger things in mind.⁴