Editing TACACS (section)

==Technical descriptions==

===TACACS===
TACACS is defined in <nowiki>RFC 1492</nowiki>, and uses (either [[Transmission Control Protocol|TCP]] or [[User Datagram Protocol|UDP]]) port 49 by default. TACACS allows a client to accept a username and password and send a query to a TACACS authentication server, sometimes called a TACACS daemon. It determines whether to accept or deny the authentication request and sends a response back. The TIP (routing node accepting dial-up line connections, which the user would normally want to log in into) would then allow access or not, based upon the response. In this way, the process of making the decision is "opened up" and the algorithms and data used to make the decision are under the complete control of whoever is running the TACACS daemon.

===XTACACS===
Extended TACACS (XTACACS) extends the TACACS protocol with additional functionality. It also separates the authentication, authorization, and accounting (AAA) functions out into separate processes, allowing them to be handled by separate servers and technologies.<ref>{{Cite web|url=https://epdf.pub/mike-meyers-comptia-security-certification-passport-second-edition.html|title=Mike Meyers' CompTIA Security+ Certification Passport, Second Edition - PDF Free Download|website=epdf.pub|language=en|access-date=2019-08-03}}</ref>

===TACACS+===
TACACS+ is a Cisco designed extension to TACACS that is described in RFC 8907. TACACS+ includes a mechanism that can be used to obfuscate the body of each packet, while leaving the header clear-text. Moreover, it provides granular control in the form of command-by-command authorization.{{ref RFC|8907}}

TACACS+ has generally replaced TACACS and XTACACS in more recently built or updated networks. TACACS+ is an entirely new protocol which is not compatible with its predecessors, TACACS and XTACACS.

=== Comparison with RADIUS ===

There are a number of differences between the two protocols which make them substantially different in normal usage.

TACACS+ can only use TCP, while RADIUS normally operates over UDP,<ref name="tacacs+v.radius">{{cite web |date=14 January 2008 |title=TACACS+ and RADIUS Comparison |url=http://www.cisco.com/c/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/13838-10.html |url-status=live |archive-url=https://web.archive.org/web/20140907214150/http://www.cisco.com/c/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/13838-10.html |archive-date=7 September 2014 |access-date=9 September 2014 |publisher=Cisco}}</ref> but can also use TCP (RFC6613), and for additional security, TLS (RFC 6614) and DTLS (RFC7360).

TACACS+ can operate in two modes.  One mode is where all traffic including passwords are sent in clear-text, and the only security is IP address filtering.  The other mode is data obfuscation (RFC 8907 Section 4.5), where the packet header is clear-text, but the body including passwords is obfuscated with an MD5-based method.  The MD5-based obfuscation method is similar to that used for the RADIUS User-Password attribute (RFC 2865 Section 5.2), and therefore has similar security properties.

Another difference is that TACACS+ is used only for administrator access to networking equipment, while RADIUS is most often used for end-user authentication.  TACACS+ supports "command authorization", where an administrator can log in to a piece of networking equipment, and attempt to issue commands.  The equipment will use TACACS+ to send each command to a TACACS+ server, which can choose to authorize, or reject the command.

Similar functionality exists in RADIUS in RFC 5607, but support for that standard appears to be poor or non-existent.

TACACS+ offers robust functionality for administrator authentication and command authorization, but is essentially never used for authenticating end-user access to networks.  In contrast, RADIUS offers minimal functionality for administrator authentication and command authorization, while offering strong support (and is widely used) for end-user authentication, authorization, and accounting.

As such, the two protocols have little overlap in functionality or in common usage.