If you were in the mythological Roman underworld of Hades, you would have much to fear from Kerberos. This ferocious three-headed dog guards Hades with six sharp eyes and many sharp teeth. But because you are in the real world, you don't have to worry about Kerberos--unless you are a hacker.
Besides being a mythological character, Kerberos is the new security protocol in Windows NT 5.0. It replaces the NT LAN Manager (NTLM) as the default authentication protocol in NT 4.0. (For more information about the relationship between Kerberos and NT 5.0, see "How Kerberos Fits into the Windows NT 5.0 Security Model,".)
Instead of three heads, NT's Kerberos has a three-sided, shared-secret key authentication process that lets network users prove their identity without exposing information that could compromise network security. What do shared-secret key and three-sided mean?
Shared-secret key denotes that two parties share the key, or the secret, to verify identities. In contrast, some encryption schemes use a private/public key approach in which one party possesses two keys: a public key, which the party shares with those it wants to have access to its system, and a private key, which it shares with no one. These keys, together, verify identity.
Three-sided signifies that the authentication process involves three components, the first of which is the client (or the client application) representing the user. (For an illustration of how a client application would use Kerberos, see "How Authentication Is Used in Network Applications,") Kerberos uses Data Encryption Standard (DES) shared-secret key cryptography to authenticate clients in unprotected networks (i.e., networks that consist of unsecured host machines). Although DES has proved an effective encryption technique, a few hackers have cracked the code. So Kerberos also lets you use other encryption algorithms, such as triple DES. (For more information about how Kerberos' evolution led to this feature, see "A History Lesson,".)
The second component in Kerberos' authentication process is the resource that wants to ensure clients are legitimate. This resource is often a network server.
The third component is the central repository for information about clients. In most cases, the repository is a Key Distribution Center (KDC) service. The KDC account database contains the identities and master keys (i.e., passwords) of all network clients and servers within the network's administrative domain, or realm.
To thwart unauthorized access to the database, the network server's private master key encrypts all of the clients' master keys. The administrators' local KDC password, in turn, protects the private master key. The KDC password is the last line of defense. A physically secure KDC is an essential component of an effective Kerberos system.
Now that you know the components in the Kerberos process, let's take a look at how they work together to authenticate clients within a realm and between realms.
How Kerberos Guards Your Network Within a Realm
When a PC user wants to access information on a network server (S1) within a
realm, the Kerberos-enabled client (C1) contacts the KDC with a request for
credentials. This request triggers a chain of events that leads to the
authentication of clients.
Kerberos uses messages to let each Kerberos component know what is occurring during the authentication process. In many cases, these messages are notated by symbols. Although many different symbol or code characters exist for notation, they usually follow a certain pattern, such as
KDC > C1: \{12345\}KC1, S1
In this code, KDC > C1 specifies that the KDC is sending a message to C1. The message then follows the colon. When the message is in brackets \{ \}, it is encrypted; when a message is not in brackets, it isn't encrypted. The letter K after the bracketed message represents the key, and the subscript letters and numbers that follow represent the clients and servers that can access the key. So the translation of the code KDC > \{12345\}KC1, S1 is that the KDC is sending the encrypted message of 12345 to C1, and C1 and S1 possess the key to decrypt the message.
Understanding Kerberos code takes practice. To help you better understand the Kerberos code and process, here is a typical exchange between a KDC, C1, and S1:
C1 > KDC: C1, KDC, Timestamp
Translation: C1 is sending a plain-text message to the KDC requesting a ticket to communicate with S1. This message contains the client username, server or service name, and a timestamp. The purpose of the timestamp is to stop protocol sniffers (readily available devices for debugging networks) from capturing packets and replaying the transmission later in an attempt to gain access to the server.
KDC > C1: \{KC1, KDC, Timestamp\}KC1, \{TGTC1, KDC\}KKDC
Translation: The KDC is sending back an encrypted message to C1. The KDC encrypted the message with an algorithm using C1's password. The message contains a timestamped session key to use with the KDC and a general ticket, called a ticket-granting ticket (TGT), which C1 can use to obtain future tickets for specific services within the KDC's administrative realm.
The TGT eliminates the need to follow the entire client authentication process with the KDC for every network request. It also eliminates the need to send passwords across the network because the user decrypts the ticket using his or her password at the client location.
C1 > KDC: \{C1 Authenticator, S1, Timestamp\}KC1, KDC, \{TGTC1, KDC\}KKDC
Translation: C1 is sending a request to the KDC to communicate with S1. C1 encrypts this request with the session key that it obtained from the KDC. The request contains S1's name, the timestamp, and the TGT.
Once the KDC receives this request, it decrypts the request with the session key to verify that the request came from C1. The KDC then creates a new session key that C1 and S1 will share. The KDC also creates a specific ticket to present to S1. This ticket contains the client/server shared session key, C1's name, C1's network adapter card address, the ticket's life span, and the timestamp. Finally, the KDC encrypts the new session key and the ticket.
KDC > C1: \{KC1, S1, Timestamp\}KC1, KDC, \{TicketS1\}KS1
Translation: The KDC is sending the encrypted new session key and ticket to C1.
C1 > S1: \{C1 Authenticator\}KC1, S1, \{TicketS1\}KS1
Translation: C1 is sending the encrypted ticket to S1 along with a timestamp authenticator encrypted with the shared session key. S1 then uses its own password to decrypt the ticket and retrieves its copy of the shared session key. S1 uses the shared session key to decrypt the timestamp authenticator to see when C1 sent the ticket. If C1 sent the ticket recently, S1 trusts that the KDC generated the ticket and authenticated C1.
S1 > C1: \{C1 Authenticator\}KC1, S1
Translation: S1 is encrypting and sending C1's original timestamp authenticator back to C1. C1 decrypts the timestamp authenticator with the shared session key, verifying that the authenticator must be from S1 because only S1 could have decrypted the original ticket, obtained the session key, and used the key to encrypt the timestamp authenticator. C1 and S1 have now authenticated each other as being who they say they are and communication can ensue between them.
How Kerberos Guards Your Network Between Realms
The authentication of clients between realms isn't all that different from
authentication within a realm. Each realm has its own KDC and ticket-granting
service. Instead of creating a separate account in each realm for the same user,
Kerberos lets realms register with each other to pass authentication requests
among the KDCs.
In realm-to-realm authentication, C1 contacts the KDC to create a session key to communicate with the remote KDC. The KDC then sends C1 a ticket to contact the remote KDC. C1 then obtains a ticket from the remote KDC to communicate with servers or services in the other realm.
With NT 5.0, you don't need direct registration between every realm. NT 5.0's Kerberos supports a hierarchy of realms so that a client can contact one realm, which knows of another realm, and so on, until the client locates the remote KDC that can issue a ticket for the server in the desired realm. (In contrast, earlier versions of Kerberos used in UNIX and on the Internet require direct registration.)
Even the Mighty Sometimes Falter
Although Kerberos is an effective tool to prevent unauthorized network
access, no protector is fail-safe. Even the three-headed dog was thwarted on
several occasions. Hercules, for instance, tore Kerberos from the underworld one
time and dragged the dog to the surface.
The Kerberos authentication process is susceptible to several problems. For example, Kerberos can fall victim to password dictionary attacks if the client chooses a password that others can easily discern. NT provides some administrative tools, such as account lockout and complex password policy enforcement, to deal with this issue. Another weakness of Kerberos is that the KDC must be physically protected. Improper handling or unsuitable environmental conditions will negate any assurance of client authentication.
You also need to consider the human element in your network's security. The mythical Kerberos succumbed to bribes of cake by Ulysses, who retrieved some of the dead from Hades while the dog was distracted. Similarly, people can succumb to modern-day bribes, so the KDC server needs to be in a locked facility. Although this issue is beyond the scope of Kerberos' protocol, you must consider it to ensure a secure system.
I don't want to scare you away from using Kerberos with this discussion about what can go wrong. Rather, I want to prepare you for what might occur. If you properly set up Kerberos and address Kerberos' weaknesses, including the human element, you will have a ferocious Kerberos guarding your network from unwanted visitors.