Kerberos Is on Guard in Windows NT 5.0

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}K_{C1, 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}K_{C1, 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: {K_{C1, KDC}, Timestamp}K_C1, {TGT_{C1, KDC}}K_KDC