Message Encryption
TACACS+ encrypts the entire message body using a pre-shared key. It only leaves the header in the clear, so without the key it is only really possible to determine who is client and who is server, plus what kind of messages are being passed (authentication or authorisation, query or response).
RADIUS uses a pre-shared key to authenticate messages going back and forth, but the messages themselves are unencrypted and can easily be read straight off the wire.
RADIUS uses UDP while TACACS+ uses TCP.
TCP offers several advantages over UDP. TCP offers a connection-oriented transport, while UDP offers best-effort delivery. RADIUS requires additional programmable variables such as re-transmit attempts and time-outs to compensate for best-effort transport, but it lacks the level of built-in support that a TCP transport offers:
-
TCP usage provides a separate acknowledgment that a request has been received, within (approximately) a network round-trip time (RTT), regardless of how loaded and slow the backend authentication mechanism (a TCP acknowledgment) might be.
-
TCP provides immediate indication of a crashed, or not running, server by a reset (RST). You can determine when a server crashes and returns to service if you use long-lived TCP connections. UDP cannot tell the difference between a server that is down, a slow server, and a non-existent server.
-
Using TCP keepalives, server crashes can be detected out-of-band with actual requests. Connections to multiple servers can be maintained simultaneously, and you only need to send messages to the ones that are known to be up and running.
-
TCP is more scalable and adapts to growing, as well as congested, networks.
RADIUS encrypts only the password in the access-request packet, from the client to the server. The remainder of the packet is unencrypted. Other information, such as username, authorized services, and accounting, can be captured by a third party.
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.
RADIUS combines authentication and authorization. The access-accept packets sent by the RADIUS server to the client contain authorization information. This makes it difficult to decouple authentication and authorization.
TACACS+ uses the AAA architecture, which separates AAA. This allows separate authentication solutions that can still use TACACS+ for authorization and accounting. For example, with TACACS+, it is possible to use Kerberos authentication and TACACS+ authorization and accounting. After a NAS authenticates on a Kerberos server, it requests authorization information from a TACACS+ server without having to re-authenticate. The NAS informs the TACACS+ server that it has successfully authenticated on a Kerberos server, and the server then provides authorization information.
During a session, if additional authorization checking is needed, the access server checks with a TACACS+ server to determine if the user is granted permission to use a particular command. This provides greater control over the commands that can be executed on the access server while decoupling from the authentication mechanism.
RADIUS does not support these protocols:
-
AppleTalk Remote Access (ARA) protocol
-
NetBIOS Frame Protocol Control protocol
-
Novell Asynchronous Services Interface (NASI)
-
X.25 PAD connection
TACACS+ offers multiprotocol support.
RADIUS does not allow users to control which commands can be executed on a router and which cannot. Therefore, RADIUS is not as useful for router management or as flexible for terminal services.
TACACS+ provides two methods to control the authorization of router commands on a per-user or per-group basis. The first method is to assign privilege levels to commands and have the router verify with the TACACS+ server whether or not the user is authorized at the specified privilege level. The second method is to explicitly specify in the TACACS+ server, on a per-user or per-group basis, the commands that are allowed.
Due to various interpretations of the RADIUS Request for Comments (RFCs), compliance with the RADIUS RFCs does not guarantee interoperability. Even though several vendors implement RADIUS clients, this does not mean they are interoperable. Cisco implements most RADIUS attributes and consistently adds more. If customers use only the standard RADIUS attributes in their servers, they can interoperate between several vendors as long as these vendors implement the same attributes. However, many vendors implement extensions that are proprietary attributes. If a customer uses one of these vendor-specific extended attributes, interoperability is not possible.
Due to the previously cited differences between TACACS+ and RADIUS, the amount of traffic generated between the client and server differs. These examples illustrate the traffic between the client and server for TACACS+ and RADIUS when used for router management with authentication, exec authorization, command authorization (which RADIUS cannot do), exec accounting, and command accounting (which RADIUS cannot do).
