ComputerWeekly.com.com

Five steps to using the Kerberos protocol

By Jan De Clercq

Windows Server 2003 security infrastructures The following excerpt, courtesy of Elsevier Digital Press, is from Chapter 5 of the book "Windows Server 2003 security infrastructures" written by Jan De Clercq. Click for the complete book excerpt series or purchase the book.



Kerberos: The basic protocol

The Kerberos authentication protocol is the default authentication protocol of Windows Server 2003. This section examines how the protocol works by breaking down the complexity of the protocol into five steps.

The first two excerpts provide important introductory information to consider while reading through the five steps. Then, step 1 explains how Kerberos uses symmetric key cryptography to authenticate entities. Step 2 describes the three different entities that the Kerberos protocol deals with and why a key distribution center (KDC) is necessary, step 3 sheds light on the connection between the session key and the master key and step 4 describes the two ways in which the KDC distributes the encrypted session keys to the user and the resource server. Finally, step 5 explores an important weakness in the protocol involving the Ticket Granting Ticket limiting the use of the master keys.

The two excerpts at the end pull together the five steps and include a brief explanation of how Kerberos extensions relate to Windows 2000, XP and Windows Server 2003. Helpful diagrams are provided throughout the section to help readers visualize the various steps.

The following table of contents will help you navigate your way through the introduction, five steps of the basic Kerberos protocol and concluding summaries.

TABLE OF CONTENTS
   Five steps to Kerberos
   Kerberos design assumptions
   Step 1: Kerberos authentication is based on symmetric key cryptography
   Step 2: The Kerberos KDC provides scalability
   Step 3: The ticket provides secure transport of the session key
   Step 4: The KDC distributes the session key by sending it to the client
   Step 5: The Ticket Granting Ticket limits the use of the master keys
   Bringing it all together
   Kerberos data confidentiality, authentication and integrity services


Five steps to Kerberos
Return to Table of Contents

The following sections explain the basic Kerberos protocol as it is defined in RFC 1510. Those not familiar with Kerberos may be bewildered by the need for numerous diverse keys to be transmitted around the network. In order to break down the complexity of the protocol, we will approach it in five steps:

Before starting to explore how Kerberos works, we must explain the notations that will be used in the illustrations:

Figure 5.1 Session keys and encrypted session keys.

To ease reading we will talk about a "client," Alice, and a "resource server" that authenticates using Kerberos. The identities used in this Kerberos authentication exchange are Alice's SID and the SID of the service account that is used by the application or the service responsible for the resource. To be fully correct we should talk about the "service account of the service," but this would not promote ease of reading. Also, when we talk about Alice, we really mean the LSA on Alice's machine impersonating Alice and acting on her behalf. From now on, the following words are synonyms: principal and security principal and entity, and domain and realm.


Kerberos design assumptions
Return to Table of Contents

Before diving into the nuts and bolts of the protocol, let's have a quick look at some of the design assumptions the Kerberos designers at MIT took. It is very important to keep these assumptions in mind as we run through the Kerberos internals.

Figure 5.2 Kerberos authentication is based on symmetric key cryptography.


Step 1: Kerberos authentication is based on symmetric key cryptography
Return to Table of Contents

To authenticate entities Kerberos uses symmetric key cryptography (When the Kerberos design was started, public key cryptography was still patented (by RSA). This explains why the default Kerberos protocol (as defined in RFC 1510) relies on symmetric key cryptography.) In symmetric key cryptography the communicating entities use the same key for both encryption and decryption. The basic mathematical formula behind this process is the following:

If the encryption (E) and decryption (D) processes are both using the same key K, the decryption of the encrypted text (M) results in the readable text (M).

This is what happens when Alice wants to authenticate to a resource server using a symmetric key cipher (illustrated in Figure 5.2):

Why does this process authenticate Alice to the resource server? If the resource server can successfully decrypt the message, this means if the decryption process results in Alice's name and an acceptable timestamp, the resource server knows that only Alice could have encrypted this information, because she is the only one, besides the resource server, who also knows the symmetric key. In this context acceptable means the following: Upon receipt of Alice's encrypted packet, the resource server will compare the timestamp in Alice's packet against the local time. If the time skew between these two timestamps is too big, the resource server will reject the authentication attempt, because a hacker could have replayed Alice's original authentication packet.

In this explanation you may have noticed the differences and similarities with the NTLM authentication protocol. Both Kerberos and NTLM use symmetric cryptography for authentication: "If you can prove you know your secret key, I believe you are who you say you are." In NTLM the knowledge of the secret key is proven using a challenge-response mechanism. Kerberos uses symmetric encryption of the timestamp and the user's name to do the same thing.

The encrypted packet containing Alice's name and the timestamp is known in Kerberos as the authenticator, and the symmetric key is called a session key. A session key exists between all Kerberos principals that want to authenticate to each other.

A critical element in this exchange is the timestamp: It provides "authenticator uniqueness" and protects against replay attacks. Without the authenticator, a hacker could grab a ticket off the network and use it to impersonate Alice to a resource server. The timestamp explains the time sensitivity of the Kerberos protocol and of Windows 2000 and Windows Server 2003.

Remember from the introduction that Kerberos can provide "mutual" authentication: To provide this the Kerberos protocol includes an additional exchange that authenticates the server to the client. In this example, it means that, in turn, the server will encrypt its name and the current timestamp and send it to Alice.

A big problem when using a symmetric protocol is the secure distribution of the secret key. The secret key is generated at one side of the communication channel and should be sent to the other side of the communication channel in a secure way. Secure means that the confidentiality and integrity of the key should be protected. If anybody could read the secret key when it is sent across the network, the whole authentication system becomes worthless: The secrecy of the secret key is a vital part of a symmetric cipher.

Steps 2, 3, and 4 explain how the Kerberos developers have resolved the problem of secure session key distribution.


Step 2: The Kerberos KDC provides scalability
Return to Table of Contents

The Kerberos protocol always deals with three entities: two entities that want to authenticate to one another and one entity that mediates between these two entities for authentication: the key distribution center (KDC). Why do we need a KDC?

Suppose that Alice is part of a workgroup consisting of five entities that all want to authenticate to one another using symmetric key cryptography. Because every entity needs to share a secret key with every other entity, we will need 10 keys. The mathematical formula behind this is n (n - 1)/2. In a 50,000-employee company we would need about 1.5 billion keys. Not only would we have to deal with an enormous amount of keys, but there would also be an enormous amount of small authentication databases: On every client there would be one, containing all the secret keys of the entities with which the client wants to authenticate. This solution is clearly not scalable to the level of a big environment. Imagine having to use such a solution on the Internet.

To make Kerberos more scalable, the Kerberos developers included the concept of a KDC. KDC is a trusted third party with which every entity shares a secret key: This key is called the entity's master key. All entities trust the KDC to mediate in their mutual authentication. The KDC also maintains a centralized authentication database containing a copy of every user's master key.

Figure 5.3 A KDC provides scalability.

In Windows Server 2003 the KDC is a service that is installed on every domain controller as part of the dcpromo Active Directory installation process. Every Windows Server 2003 domain controller runs a KDC service (The KDC itself is made of two subservices: the Authentication Service (AS) and the Ticket Granting Service (TGS); in other Kerberos implementations these two subservices can run on different machines, but this is not possible in Windows 2000 and Windows Server 2003.) and hosts an Active Directory (AD) instance, the central authentication database (On an interesting note, a standard Kerberos domain is made up of a master KDC and one or more slave KDCs. The master KDC is collocated with a read-write copy of the authentication database (single-master model). In Windows 2000 and Windows Server 2003 every KDC server hosts a read-write copy of the domain portion of the Active Directory (multimaster model.) As a consequence, a domain with multiple domain controllers provides fault tolerance for the authentication process and the authentication database. If one DC is down, another one can automatically take over. Also, the AD authentication database is replicated between domain controllers.

The concept of a master key is not new to Windows 2000, Windows Server 2003, and Kerberos: It already existed in NT4 and earlier Windows versions. In Windows the master key is derived from a security principal's password.

The password is a secret key that is shared between each individual security principal and the central authentication authority (in the Kerberos case the KDC). Both the entity and the KDC must know the master key before the actual Kerberos authentication process can take place. For obvious security reasons, the AD never stores the plain password but a hashed version (the hash algorithm used is MD4).

An entity's master key is generated as part of the domain enrollment process (e.g, when the administrator enrolls the user and enters a password). A machine's master key is derived from the machine password that is automatically created when an administrator joins the machine into a domain.


Step 3: The ticket provides secure transport of the session key
Return to Table of Contents

Figure 5.4 shows the three basic entities with which the Kerberos protocol deals: a client (Alice), a resource server and a KDC. Figure 5.4 also shows the master keys that are shared between the entities participating in the authentication process and the KDC.

Remember that in the first step we talked about the problem of distributing the secret key (the session key) when dealing with symmetric key ciphers. This section explains how Kerberos resolves this problem. It makes

Figure 5.4 Kerberos entities and master key concept.

the link between the session key and the master key (introduced in step 2) and explains why we really need a master key in the Kerberos protocol.

In Section 5.2.3, we explained that every entity shares a master key with the KDC. We also said that all entities trust the KDC to mediate in their mutual authentication. Trust in this context also means that every entity trusts the KDC to generate session keys. In the scenario shown in Figure 5.4, the resource server would never trust Alice to generate session keys, because Alice has not authenticated yet to the resource server (the other way around would not work either).

So far, so good. Alice needs to authenticate to the resource server and requests a session key from the KDC. The KDC will generate the session key5 and distribute it to both entities. After the KDC has generated the session key, it must communicate it to both Alice and the resource server. To secure the transport of the session key to a particular entity, Kerberos encrypts it with the master key of that entity.

Because there are two entities, Alice and the resource server, two encrypted versions of the session key must be generated:

In Kerberos terminology, the session key encrypted with the resource server's master key is known as a "ticket." A Kerberos ticket provides a way to transport a Kerberos session key securely across the network. Only the

Figure 5.5 Windows Server 2003 key hierarchy.

destination resource server and a Windows Server 2003 domain controller can decrypt it.

By securing the transport of the session key using the master key, Kerberos creates what is known as a key hierarchy. Figure 5.5 shows the Windows Server 2003 key hierarchy, which consists of:

In this key hierarchy the following are also true:


Step 4: The KDC distributes the session key by sending it to the client
Return to Table of Contents

The KDC can distribute the encrypted session keys to Alice and the resource server in two ways:

The first method has the following disadvantages:

Figure 5.6 Kerberos ticket distribution Method 1.

Figure 5.7 Kerberos ticket distribution Method 2.

Because of the disadvantages associated with Method 1, Kerberos uses the alternative explained next as Method 2 (see Figure 5.7):

The key advantage of Method 2 lies in its unique caching architecture: Alice's machine can cache tickets and reuse them. Also, it takes away the need for the server to cache the tickets: It receives them from the clients as needed. This architecture makes the Kerberos protocol stateless on the server side. This has obvious advantages if you want to implement a load balancing or redundancy solution on the server side: There is no need to bother about keeping the session keys synchronized between the different domain controllers.

On the client side, tickets are kept in a special system memory area, which is never paged to disk. The reuse of the cached tickets is limited because of a ticket's limited lifetime and renewal time. Windows 2000, XP, and Windows Server 2003 maintain a ticket cache for every security principal logon session. The ticket cache is purged when the logon session ends. The cache is preserved and written to disk when a system goes into hibernation mode.

Figure 5.8 The use of the master key.


Step 5: The Ticket Granting Ticket limits the use of the master keys
Return to Table of Contents

There is yet another important weakness in the protocol that we have not addressed so far: The session key that is sent back from the KDC to Alice is encrypted using Alice's master key (as shown in Figure 5.8). This encrypted packet is sent over the network every time Alice needs a session key to authenticate to a resource server. This means that every time there is an opportunity for hackers to intercept the encrypted packet and to perform -- possibly offline -- a brute-force attack on the encrypted packet and derive the user's master key.

In a brute-force attack, a hacker tries to guess the key that was used to encrypt a packet by trying out all the possible keys and looking at the result. Such attacks are not unrealistic: Remember some of the tools that were mentioned in Chapter 2 (L0phtcrack, John the Ripper...) to do brute-force attacks on the SAM or AD database or on the authentication packets sent across the network?

There is clearly a need here for a strong (Strong means less susceptible to brute-force attacks. To resist these attacks there are two possibilities: (1) Use longer keys -- longer keys create bigger key spaces and make it more difficult to guess the right key; (2) change the keys more often -- this limits the chance for brute-force attacks. In other words, limit the lifetime of the keys; this principle is often referred to as perfect forward secrecy (PFS). The Kerberos developers have chosen the latter solution.) secret to replace Alice's master key: This will be the role of the session key that is shared between each entity and the KDC. This session key will replace Alice's password, and it will be used to authenticate Alice to the KDC after the initial authentication (There are also other reasons why the concept of a session key shared between every Kerberos entity and the KDC is important: it allows for the KDC's AS and TGS services to be hosted on different machines (this cannot be done in Windows, but is often done in UNIX Kerberos implementations), and it enables cross-domain authentication referrals (explained later).)

Although it has an identical function (authentication), the session key introduced in this step is not the same as the one used in the previous sections. This session key is shared between Alice and the KDC, and the other session key is shared between Alice and the resource server.

Just like Alice's master key, both Alice and the KDC must know this session key. To securely transport this session key, we will use the same mechanism as the one described in steps 3 and 4:

Figure 5.9 shows how this new session key (Sku) and the associated TGT are used in the basic Kerberos protocol exchange:

This sequence shows how in the basic Kerberos exchange:


Bringing it all together
Return to Table of Contents

In this section we will bring together all the elements that were brought up in the previous five steps. Figure 5.10 shows the complete Kerberos protocol: It consists of three subprotocols (or phases), each one made up of two steps. In the following list, the cryptic names between parentheses are the names of the Kerberos protocol messages as they are called in the Kerberos standard documents.

During these exchanges the following keys and tickets are cached on Alice's computer: the TGT, the ticket used to authenticate to the resource server, and two session keys -- one to authenticate to the KDC and one to authenticate to the resource server.


Kerberos data confidentiality, authentication and integrity services
Return to Table of Contents

Windows 2000, XP and Windows Server 2003 all include the Kerberos extensions that can be used to provide data confidentiality, authentication and integrity for messages that are sent after the initial Kerberos exchange outlined in the previous sections. These extensions are known as the KRB_PRIV (providing data confidentiality) and the KRB_SAFE (providing data authentication and integrity) Kerberos extensions. They are based on the existence of a session key between two entities at the end of a Kerberos authentication protocol exchange:

Click for the next excerpt in this series: Logging on to Windows using Kerberos.


Click for the book excerpt series or visit Elsevier to obtain the complete book.

27 Sep 2004

All Rights Reserved, Copyright 2000 - 2024, TechTarget | Read our Privacy Statement