2.1 The Three As

We'll start out our discussion with a topic that many network professionals deal with on a daily basis, the three As. Authentication, authorization, and auditing are a crucial part of any network security scheme, yet the distinction between them is often unclear. Each one of these components serves a separate, distinct purpose in a network security scheme. In particular, we will focus on authentication and authorization, and how they relate to each other.

2.1.1 Authentication

Simply put, authentication is the process of verifying the identity of a particular user. To authenticate a user, the user is asked for information that would prove his identity. This information can fall into one or more of three categories: what he knows, what he has, or what he is. These categories are referred to as factors.

The first factor, what he knows, is the most common factor used in authentication today. A secret password is generated when the user is granted access to a machine or network. That secret can either be generated by the user himself, by choosing his own password and giving it to the system administrator when he grants the user access, or automatically through some process that generates random passwords.

The second factor, what he has, is a less common but more secure alternative. An example of this type of authentication is the widely deployed RSA SecurID token. The SecurID token is a small electronic device that has an embedded encryption key and an LCD display. Every minute, an algorithm runs inside the device and updates the LCD display with a new six-digit combination. Only the person who possesses the device can tell what the correct password is. Other systems, such as smart card systems, operate on similar principles.

The third factor, what he is, enters into the realm of biometrics. Since all humans have distinguishing characteristics, biometrics measures the physical properties of some portion of our body and uses that information to authenticate users. Current biometric systems include fingerprint scanning, retina scanning, voiceprint recognition, and face recognition. Biometrics does not yet enjoy a wide market for several reasons: products are still immature for widespread use, some are very expensive (such as retina scanning), and, perhaps the most important reason of all, there is currently little software support for these devices.

Of course, an authentication system can combine these factors. For example, the RSA SecurID login process involves not only the SecurID token but also a numeric PIN. Therefore, SecurID combines the first two factors, what you have and what you know. Obviously, a system that combines more than one factor is more secure than a system which depends on only one.

The Kerberos protocol itself does not specify which authentication factors must be used. Although most implementations use a password-based system, there are implementations, such as the one present in Microsoft's Windows 2000 and above, which allow Kerberos login tied to the use smart cards. Smart cards, which we'll cover further in Chapter 10, avoid the use of passwords as the sole factor of authentication. Therefore, they make the login process easier on users, as well as providing a more secure authentication mechanism.

Once the server receives the information from the user that proves his identity, the server determines whether that information is correct. Does the password that the user entered match the one listed in the password database? If so, then the user is authenticated. If not, then the request is denied.

Attacks against authentication systems are typically performed in a brute-force manner, where an attacker utilizes a computer that tries combination after combination until the user's password is found. Different policies can be employed during authentication to prevent an attacker from continuously trying a large list of passwords, and we'll discuss those in Chapter 6.

2.1.2 Authorization

Authorization refers to granting or denying access to specific resources based on the requesting user's identity. This step is performed after a user is identified through authentication. Authorization is usually performed through access control lists, which associate user identities with specific rights. Authorization includes information such as a user's group membership, user policies, and other information that determines what level of access that user has to computer or network resources.

It is important to note that the ability to make correct authorization decisions rests solely on a solid authentication mechanism. The only way that a correct authorization decision can be made is if the user has already been correctly authenticated. Authorization ceases to work if the authentication method can't be trusted. If the authentication mechanism returns a false identity to the authorization mechanism, then there is no way for the authorization mechanism to correct this, and it can allow an attacker to masquerade as a legitimate user.

As a result, solid authorization mechanisms depend on an effective authentication system. Systems that depend on weak authentication will fail, no matter how sophisticated the authorization may be. An example is the standard NFS protocol. NFS requires servers to trust the clients, since users are "authenticated" by a plaintext UID sent by the client. Clearly, this mechanism makes it trivial to spoof any username on an NFS server. The ease of bypassing authentication negates any sophisticated Access Control List authorization mechanism that may be employed on the server, since an attacker can easily masquerade as any other user ID given control of a client machine.

2.1.3 Auditing

The final A in the three As is auditing. Auditing takes the results from authentication and authorization and records these results into an audit log. The audit log records all actions taken by the authentication and authorization steps for future review by an administrator. While authentication and authorization are preventative systems in which unauthorized access is prevented, auditing is a reactive system. Auditing will not prevent an attacker from gaining access to your network; instead, it will give you a detailed log of when, where, and how the attacker penetrated your systems.

All Kerberos implementations we will cover have the ability to log events that take place during authentication requests. We'll take a very close look at auditing in Chapter 6, where we'll review what logging can be enabled in the various Kerberos implementations and how to view those logs.