The purpose of an authentication service is to establish the identity of a client authoritatively. In an insecure environment, identity may be established with a simple username, or bypassed altogether. In a secure environment, the client not only presents an identity (such as a username) but also provides authenticating information to prove that the identity provided is genuine.
With the use of a dedicated authentication server or service, an administrator can establish a single nexus for authentication, rather than establishing authentication individually for each network service to be provided. A VPN, print server, and web host, for instance, can all authenticate against a single authentication server. Without an authentication server, usernames and passwords (or other methods of identity verification) would have to be individually established on the VPN gateway, print server, and web server for each user. This section will cover the following topics:
- RADIUS
- TACACS
- TACACS+
- Kerberos
- LDAP
- XTACACS
RADIUS
RADIUS stands for Remote Authentication Dial-in User Service, which is a bit of a misnomer. Though originally conceived as a way for users of remote dial-in connections to authenticate, the RADIUS Protocol is an authentication service that can serve many different types of connections. Whether the connection is internal or remote, dial-up, wireless, or VPN, a RADIUS server can be used to authenticate the connection. RADIUS can also provide authorization and accounting. The focus of RADIUS is network access authentication.
The RADIUS Protocol is an older protocol designed primarily with authentication in mind, not necessarily authenticating in the most secure way possible. The only packets that are encrypted are password packets. These packets are generated through the use of an MD5 hash function, which is no longer considered secure. For this reason, the use of the RADIUS Protocol for authentication may expose both the unencrypted information, such as usernames, and the weakly encrypted content of the password packets to a snooper.
RADIUS officially uses UDP port 1812 for authentication and UDP port 1813 for accounting, but these port numbers were assigned after RADIUS had come into common use. Unofficially, RADIUS uses UDP port 1645 for authentication and UDP port 1646 for accounting. Many RADIUS implementations listen on both sets of ports.
TACACS
TACACS, or Terminal Access Controller Access-Control System, is an alternative basic authentication protocol. Like RADIUS, TACACS is an older protocol designed to authenticate remote connections, but it also can be used to authenticate connections from a variety of sources. TACACS provides the same type of authentication service as RADIUS, but without including the authorization and accounting components. It operates over TCP or UDP port 49.
One of the greatest benefits of TACACS is its ability to operate over TCP, which is considered more reliable. Like RADIUS, the focus of TACACS is network access authentication. It is an open authentication standard, though less fully featured than the Cisco proprietary TACACS+ and XTACACS. TACACS is still commonly used in UNIX environments.
TACACS+
TACACS+ allows for much more than simple authentication. TACACS+ is a Cisco proprietary protocol intended to improve upon the TACACS Protocol. The major enhancement in TACACS+ over TACACS is the inclusion of authorization and accounting. Furthermore, the authorization works at a granular level, known as command authorization, allowing a switch or a router to verify with a TACACS+ whether a remote user is authorized to execute specific commands before allowing the user to execute them.
Because TACACS+ does so much more than TACACS or RADIUS, it also tends to have a higher network resource overhead. For instance, multiple challenge response sessions occur for each session, one each for authentication, authorization, and accounting. TACACS+ is considered more secure than RADIUS, as the entire authentication session is encrypted, not just the password packets.
TACACS+ authentication, authorization, and accounting components are modular, where RADIUS integrates authentication and accounting. This allows TACACS+ to offload authentication while still implementing the other features of TACACS+.
Due to the feature-set and Cisco proprietary nature of TACACS+, it is most commonly used to control access to routers and switches. TACACS+ is not backwards compatible with earlier TACACS versions.
Kerberos
Kerberos is a network authentication protocol wherein the client and the server authenticate to one another and can present that authentication to other network services. This allows a user to authenticate against a single server for multiple services.
Kerberos is designed to allow secure authentication for varied network resources across insecure networks. Clients are authenticated and are granted tickets to authorize access to network resources. The process is designed so that the user keys (passwords) never traverse the network, and each ticket builds on previously established authentication and authorization. The Kerberos resource request process is described in detail as follows:
The Authentication Server is concerned with verifying the identity of the user. This is accomplished by the user sending an unencrypted user ID to the server. This is the only unencrypted communication that occurs. The server then uses symmetrical encryption and a shared secret to generate a secret key, usually the hash of the shared secret. This key is known as the user secret key. The authenticating user already has a copy of this user secret key. This key is never sent across the network.
The server uses this user secret key to securely send the user a Ticket Granting Service (TGS) session key. Only a user in possession of the user secret key is able to read this TGS session key.
The Authentication Server also sends the user a Ticket Granting Ticket (TGT), which is encrypted with the server secret key. The TGT contains client ID, client network address, ticket validity period, and the client TGS session key. The user does not have the information necessary to decrypt the TGT.
Now that the user has received a TGT and a TGS session key, the user has enough information to authenticate to the TGS server.
To request access to a network service, the client will send the ticket granting service the TGT and the client ID of the requested service. The client will also send their client ID but will encrypt it using the TGS session key. The TGS server is able to decrypt the TGT to extract the client’s TGS session key, and then use the client’s TGS session key to authenticate the client.
When the TGS server authenticates the client, it delivers the information necessary for the client to authenticate to the requested service server. The TGS will send the client a Client/Server Ticket, which is encrypted with the service server’s secret key. The client cannot decrypt the Client/Server Ticket, just as the client cannot decrypt the TGT.
The TGS will also send the client a Client/Server Session Key, encrypted with the previously established Client/TGS session key. Through this series of secure exchanges, the client is now in possession of all the data necessary to authenticate to the service server.
The client will provide the service server the Client/Server Ticket, which the service server is able to decrypt. The Client/Server Ticket contains the client ID, client network address, validity period, and the Client/Server Session Key. The client will also provide the service server an authentication with the client ID, encrypted with the Client/Server Session Key. This authenticates the client to the service server. The server responds with an authentication message to the client, encrypted using the same Client/Server Session Key. This authenticates the service server to the client.
After this exchange, the authentication and authorization is complete, and the service server can provide services to the client until the client tickets expire. Upon ticket expiration, the entire process repeats for any tickets that have expired.
LDAP
While LDAP (Lightweight Directory Access Protocol) is not an AAA service per se, it can be a very simple and low overhead way to read or change X.500 directory information across a network. LDAP is a very common way to access Active Directory, Apple Directory, and Novell eDirectory information. LDAP operates over TCP port 389 most commonly. It can also run over UDP port 389.
The use of LDAP can make locating network resources and information regarding network resources much more efficient. LDAP can support queries from a wide variety of sources, potentially providing a single point of network user management.
XTACACS
XTACACS stands for Extended TACACS, which is the intermediate technology between TACACS and TACACS+. Where TACACS provides only authentication and TACACS+ provides modular authentication, authorization, and accounting with command-level authorization, XTACACS was developed as a step toward changing TACACS to fulfill the needs of the AAA security model. It includes supports for authorization and accounting but has a more limited feature set than TACACS+ does.
XTACACS is backward compatible with TACACS. Both TACACS and XTACACS have largely been replaced by TACACS+.