SY0-501 Section 5.1 Compare and contrast the function and purpose of authentication services.

RADIUS

RADIUS (Remote Authentication Dial In User Service), defined in RFC 2865, is a protocol for remote user authentication and accounting. RADIUS enables centralized management of authentication data, such as usernames and passwords.

When a user attempts to login to a RADIUS client, such as a router, the router send the authentication request to the RADIUS server. The communication between the RADIUS client and the RADIUS server are authenticated and encrypted through the use of a shared secret, which is not transmitted over the network. The RADIUS server may store the authentication data locally, but it can also store authentication data in an external SQL database or an external Unix /etc/passwd file. The RADIUS server can also plug into a PAM (Pluggable Authentication Service) architecture to retrieve authentication data. The role of the RADIUS server as the centralized authentication server makes is an excellent choice for also performing accounting

RADIUS can significantly increase security by enabling the centralization of password management. Of course, the other side of that argument is that once you take over the RADIUS server, you have everything. RADIUS servers are available from many vendors. In addition, GNU RADIUS is an excellent non-commercial option. RADIUS utilizes the MD5 algorithm for secure password hashing. RADIUS is the de facto authentication provider in 802.11i wireless networks.

TACACS and TACACS+

Terminal Access Controller Access-Control System (TACACS) is a remote authentication protocol that is used to communicate with an authentication server commonly used in UNIX networks. TACACS allows a remote access server to communicate with an authentication server in order to determine if the user has access to the network. TACACS is defined in RFC 1492, and uses (either TCP or UDP) port 49 by default. A later version of TACACS introduced by Cisco in 1990 was called Extended TACACS (XTACACS). The XTACACS protocol was developed by and is proprietary of Cisco Systems.

TACACS allows a client to accept a username and password and send a query to a TACACS authentication server, sometimes called a TACACS daemon or simply TACACSD. This server was normally a program running on a host. The host would determine whether to accept or deny the request and send 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. TACACS+ and RADIUS have generally replaced TACACS and XTACACS in more recently built or updated networks. TACACS+ is an entirely new protocol and not compatible with TACACS or XTACACS. TACACS+ uses the Transmission Control Protocol (TCP) and RADIUS uses the User Datagram Protocol (UDP). Some administrators recommend using TACACS+ because TCP is seen as a more reliable protocol. Whereas RADIUS combines authentication and authorization in a user profile, TACACS+ separates the two operations.

TACACS+ in the switch manages authentication of logon attempts through either the Console port or Telnet. TACACS+ uses an authentication hierarchy consisting of (1) remote passwords assigned in a TACACS+ server and (2) local passwords configured on the switch. That is, with TACACS+ configured, the switch first tries to contact a designated TACACS+ server for authentication services. If the switch fails to connect to any TACACS+ server, it defaults to its own locally assigned passwords for authentication control if it has been configured to do so. For both Console and Telnet access you can configure a login (readonly) and an enable (read/write) privilege level access.

Kerberos

Kerberos is a distributed authentication service that allows a process (a client) running on behalf of a principal (a user) to prove its identity to a verifier (an application server, or just server) without sending data across the network that might allow an attacker or the verifier to subsequently impersonate the principal. Kerberos optionally provides integrity and confidentiality for data sent between the client and server. Kerberos was developed in the mid-’80s as part of MIT’s Project Athena. As use of Kerberos spread to other environments, changes were needed to support new policies and patterns of use. To address these needs, design of Version 5 of Kerberos (V5) began in 1989. Though V4 still runs at many sites, V5 is considered to be standard Kerberos.

Limitations of Kerberos

Limitations of Kerberos have been described in the literature. In particular, Kerberos is not effective against password guessing attacks; if a user chooses a poor password, then an attacker guessing that password can impersonate the user. Similarly, Kerberos requires a trusted path through which passwords are entered. If the user enters a password to a program that has already been modified by an attacker (a Trojan horse), or if the path between the user and the initial authentication program can be monitored, then an attacker may obtain sufficient information to impersonate the user. Kerberos can be combined with other techniques, to address these limitations.

To be useful, Kerberos must be integrated with other parts of the system. It does not protect all messages sent between two computers; it only protects the messages from software that has been written or modified to use it. While it may be used to exchange encryption keys when establishing link encryption and network level security services, this would require changes to the network software of the hosts involved.

Kerberos does not itself provide authorization, but V5 Kerberos passes authorization information generated by other services. In this manner, Kerberos can be used as a base for building separate distributed authorization services.

How Kerberos works

The Kerberos Authentication System uses a series of encrypted messages to prove to a verifier that a client is running on behalf of a particular user. The Kerberos protocol is based in part on the Needham and Schroeder authentication protocol, but with changes to support the needs of the environment for which it was developed. Among these changes are the use of timestamps to reduce the number of messages needed for basic authentication, the addition of a “ticket-granting” service to support subsequent authentication without re-entry of a principal’s password, and different approach to cross-realm authentication (authentication of a principal registered with a different authentication server than the verifier). The description is simplified for clarity; additional fields are present in the actual protocol. Readers should consult RFC 151 for a more thorough description of the Kerberos protocol.

Kerberos Encryption

Though conceptually, Kerberos authentication proves that a client is running on behalf of a particular user, a more precise statement is that the client has knowledge of an encryption key that is known by only the user and the authentication server. In Kerberos, the user’s encryption key is derived from and should be thought of as a password; we will refer to it as such in this article. Similarly, each application server shares an encryption key with the authentication server; we will call this key the server key. Encryption in the present implementation of Kerberos uses the data encryption standard (DES). It is a property of DES that if ciphertext (encrypted data) is decrypted with the same key used to encrypt it, the plaintext (original data) appears. If different encryption keys are used for encryption and decryption, or if the ciphertext is modified, the result will be unintelligible, and the checksum in the Kerberos message will not match the data. This combination of encryption and the checksum provides integrity and confidentiality for encrypted Kerberos messages.

LDAP

The Lightweight Directory Access Protocol, better known as LDAP, is based on the X.500 standard, but significantly simpler and more readily adapted to meet custom needs. Unlike X.500, LDAP supports TCP/IP, which is necessary for Internet access. The core LDAP specifications are all defined in RFCs.

The advantages of LDAP directories

Now that we’ve straightened that out, what are the advantages of LDAP directories? The current popularity of LDAP is the culmination of a number of factors. I’ll give you a few basic reasons, provided you keep in mind that it’s just part of the story.

Perhaps the biggest plus for LDAP is that your company can access the LDAP directory from almost any computing platform, from any one of the increasing number of readily available, LDAP-aware applications. It’s also easy to customize your company’s internal applications to add LDAP support. The LDAP protocol is both cross-platform and standards-based, so applications needn’t worry about the type of server hosting the directory. In fact, LDAP is finding much wider industry acceptance because of its status as an Internet standard. Vendors are more willing to write LDAP integration into their products because they don’t have to worry about what’s at the other end. Your LDAP server could be any one of a number of open-source or commercial LDAP directory servers (or perhaps even a DBMS server with an LDAP interface), since interacting with any true LDAP server involves the same protocol, client connection package, and query commands. By contrast, vendors looking to integrate directly with a DBMS usually must tailor their product to work with each database server vendor individually.

Unlike many relational databases, you do not have to pay for either client connection software or for licensing. Most LDAP servers are simple to install, easily maintained, and easily optimized. LDAP servers can replicate either some or all of their data via push or pull methods, allowing you to push data to remote offices, to increase security, and so on. The replication technology is built-in and easy to configure. By contrast, many of the big DBMS vendors charge extra for this feature, and it’s far more difficult to manage. LDAP allows you to securely delegate read and modification authority based on your specific needs using ACIs (collectively, an ACL, or Access Control List). For example, your facilities group might be given access to change an employee’s location, cube, or office number, but not be allowed to modify entries for any other fields. ACIs can control access depending on who is asking for the data, what data is being asked for, where the data is stored, and other aspects of the record being modified. This is all done through the LDAP directory directly, so you needn’t worry about making security checks at the user application level. LDAP is particularly useful for storing information that you wish to read from many locations, but update infrequently. For example, your company could store all of the following very efficiently in an LDAP directory:

– The company employee phone book and organizational chart

– External customer contact information

– Infrastructure services information, including NIS maps, email aliases, and so on

– Configuration information for distributed software packages

– Public certificates and security keys

SAML

Security Assertion Markup Language (SAML) is an open standard based on XML that is used for authentication and authorization data. Service providers often use SAML to prove the identity of someone connecting to the service provider. The current version is SAML v2.0.