TACACS+

networkingsecurity

Stands for: Terminal Access Controller Access-Control System Plus (RFC 8907)

A protocol for centralising administrative access to network devices, separating authentication, authorization and accounting into distinct exchanges.

The separation is the practical difference from RADIUS: because authorisation is its own exchange, a device can ask the server about each command as it is typed, which is how per-command control and full command logging work. That makes it the usual choice for device administration while RADIUS remains usual for network access. RFC 8907 (September 2020) documents the protocol as deployed: TCP port 49, a 12-byte header with major and minor version, type (0x01 authentication, 0x02 authorization, 0x03 accounting), sequence number, flags, session id and length, and a body obfuscated by XOR with MD5-derived padding of the shared secret; the RFC itself says that is "best referred to as 'obfuscation' and not 'encryption'" and that the protocol "does not include a security mechanism that would meet modern-day requirements". Cisco's comparison puts the contrast plainly: "TACACS+ encrypts the entire body of the packet but leaves a standard TACACS+ header." The dependency deserves stating - if the server is unreachable and local fallback was never configured or never tested, the estate becomes unmanageable at exactly the moment somebody needs to log in.

TACACS+ is the protocol a router or switch uses to ask a server whether an administrator may log in, whether that administrator may run the command just typed, and to tell the server that the command was run. It is the descendant of the original TACACS of the ARPANET terminal servers and of Cisco's extended XTACACS, and it carried Cisco's name on it for two decades before it was written down for the record: RFC 8907, The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol, published in September 2020 by Dahm and Ota of Google, Medway Gash of Cisco, Carrel and Grant as an Informational document, describes the protocol as deployed since "The Draft" of 1998, the vendor specification that was never standardised until this document. The TACACS and XTACACS entry covers the ancestors.

The protocol runs over TCP on port 49. Every packet begins with a 12-byte header: a major and minor version, a type octet, 0x01 for authentication, 0x02 for authorization and 0x03 for accounting, a sequence number, flags, a session identifier and the length of the body. The three types are separate conversations, and that separation is the point. A RADIUS Access-Accept combines authentication with whatever authorisation the server chooses to attach; a TACACS+ authorization exchange is its own request and reply, which a device can make as often as it likes, including once per command. Cisco's comparison document, which also records that Cisco "seriously evaluated RADIUS as a security protocol before it developed TACACS+", states the consequence: "RADIUS does not allow users to control which commands can be executed on a router", whereas "TACACS+ provides two methods to control the authorization of router commands on a per-user or per-group basis". Accounting is a third exchange with its own flags, START (0x02), STOP (0x04) and WATCHDOG (0x08), so that a session's start, its end and its continued existence can each be recorded; the accounting entry and the article on who did what and when describe what the records contain.

Security is where RFC 8907 is unusually frank for a protocol document. The body of each packet is XORed with a pseudo-pad made of successive MD5 digests, the first computed over the session id, the shared key, the version and the sequence number and each later one over the same values plus the previous digest. The RFC says that this is "best referred to as 'obfuscation' and not 'encryption'", that the protocol "does not include a security mechanism that would meet modern-day requirements", and that it therefore "MUST be deployed over networks that ensure privacy and integrity", separated from other traffic. The header is never obfuscated, which is Cisco's "leaves a standard TACACS+ header". The practical reading is that TACACS+ belongs on a management network, or inside a tunnel, and that the shared key is a secret worth rotating. What is deployed in most estates is the RFC 8907 protocol on a protected network.

The operational risk is availability, and it is the one engineers remember. A device configured to authenticate administrators against TACACS+ servers it cannot reach will fall back to whatever its method list says, and if the list ends at the servers, or the local account at the end of it was never created or its password never tested, nobody can log in to fix the thing that broke the path to the servers. The discipline is a method list that ends in a tested local credential, servers reachable by more than one route, and a periodic exercise in which the fallback is actually used. The second habit is to treat the accounting side as a product in itself: command accounting from every device to a server that keeps it is the record that answers the question asked after every outage and every intrusion, and it exists only on devices where somebody turned it on.

Against RADIUS, the division is stable and worth stating as a rule: TACACS+ for device administration, where per-command authorisation and command accounting are the requirement, and RADIUS for network access, where the user or device is being admitted to a port, an SSID or a VPN and where 802.1X and the EAP methods only exist in RADIUS. Most estates run both, usually from the same policy servers, and the article on TACACS+ device administration walks a login and a command through the three exchanges.

Also known as: tacacs plus, tcp 49, command authorization, command accounting, device administration

← All glossary entries