14.3 Kerberos Authentication Review

Kerberos runs on a system of tickets issued by the Key Distribution Center (KDC). To gain access to a network resource, you must have a ticket for authentication. The KDC is the main communication intermediary in this scheme and runs as a service on Windows 2003 Server domains. In fact, every Windows 2003 Server domain controller is a KDC by default. The purpose of the KDC is to grant initial tickets and Ticket-Granting Tickets (TGTs) to principals . In Kerberos, a principal can be a user , machine, service, or application. By presenting a pre-shared secret, each principal gets a unique TGT.

The KDC is comprised of two components , which are the Authentication Service (AS) and the Ticket-Granting Service (TGS). The AS is the first subprotocol activated when the user logs on to the network. The AS provides the user with a logon, a temporary session (encryption) key, and a TGT. The AS response includes two copies of the session key, one encrypted with the TGS's key, located in the TGT, and one copy that is encrypted with the user's key (password). This shared session key between the user and the TGS enables the single sign-on capability of Kerberos.

Unless the realm uses preauthentication, the KDC will happily issue a TGT to anyone . The ability to decrypt the message containing the shared session key is what "authenticates" a user.

When a principal wants to communicate with another principal, it presents its unique TGT to the KDC. Figure 14-1 shows an overview of the Kerberos communication sequence.

Figure 14-1. The steps of Kerberos authentication

As shown in the figure, authentication is a sequential process, as follows :

1. The principal (in this example, the Client) first makes an authentication service request to the KDC for a Ticket-Granting Ticket (TGT).

2. The KDC responds to the Client with a TGT. This includes a key (ticket session key) and is encrypted with the Client's password.

3. The Client uses its new TGT to request a Ticket-Granting Service (TGS) ticket in order to access the other principal (in this example, the Server).

4. The KDC responds to the Client by issuing a TGS ticket to the Client to access a specific resource on the Server. Note that here again a session key is generated, and two copies are made. One copy is intended for the application server and is encrypted with the application server's key (the ticket), and the other copy is sent to the user, encrypted with the session key from the AS exchange.

5. The Client presents the TGS as a request to the Server.

6. The Server authenticates the Client by acknowledging the TGS. If mutual authentication is specified, the Client reciprocates by authenticating the Server as well. Thus, the knowledge of this shared session key between the user and the service provides mutual authentication. As long as both parties demonstrate that they know this shared key (for example, by generating a random number on the Client, sending it encrypted with the session key, and expecting that number + 1 back from the Server), then mutual authentication has occurred.

Without mutual authentication, an attacker could mount a man-in-the-middle attack and log into a machine that assumed decryption of a TGT implies successful authentication.

14.3.1 Accessing Cross-Domain Network Resources

In Windows Server, establishing a domain implicitly creates a Kerberos realm with the same name . Using the example above, suppose the Client would like to access resources from an entirely different domain (realm), as shown in Figure 14-2. As you recall, the Client first received the TGT from the KDC in its own domain (Domain 1). However, this TGT only works in the current domain (Domain 1). If the Client wants to access a resource in a trusted domain (Domain 2), it must request a new TGT. This is known as cross-domain network access . Thus, the KDC from Domain 1 issues the Client a new TGT that provides authentication to the KDC in Domain 2.

Figure 14-2. Cross-domain Kerberos authentication

Such cross-domain authentication is known as Kerberos referrals , which is unique to Windows. Other (non-Windows) implementations of Kerberos must realize before contacting the KDC that the requested resource is not in the local realm and must therefore ask directly for the cross-realm ticket.

The steps involved are as follows:

1. The Client in Domain 1 wishes to access a network resource (in our example, a network printer) in remote Domain 2. The Client has already been authenticated to the KDC in Domain 1 and has received a TGT. The Client presents the TGT to the KDC in Domain 1 and requests a TGS to access the remote network resource.

2. The KDC in Domain 1 cannot provide a TGS to the network resource in Domain 2, since the network resource is in a remote domain. Instead, the KDC in Domain 1 responds to the Client with a TGT for Domain 2.

3. The Client presents the new TGT to the KDC in Domain 2.

4. The KDC in Domain 2 responds with a TGS for the network resource.

5. The Client accesses the network resource in Domain 2 using the new TGS.

14.3.2 Weaknesses in the Kerberos Protocol

While Kerberos is a drastic improvement in security over the archaic NTLM (NT LAN Manager), Kerberos as implemented in Windows (and other operating systems) is still potentially vulnerable. For example, Frank O'Dwyer provides the following attack (included with permission).

It is well known that the LM and NTLM authentication schemes used by NT4 (and for backward compatibility in Windows 2000) are susceptible to offline password-guessing attacks. Password-cracking tools such as l0phtcrack have ably demonstrated this vulnerability. However, the question of whether it is feasible to adapt these techniques to attack the Kerberos 5 authentication scheme used by Windows Server has not received the same level of public attention. It is also worrying that the general presumption seems to be that Kerberos 5 solves the password-cracking issue once and for all, provided Kerberos alone is used in a domain. In fact, Kerberos 5 has long been known to have vulnerabilities to offline password-guessing attacks. The problem is explicitly stated in RFC 1510:

"Password guessing" attacks are not solved by Kerberos. If a user chooses a poor password, it is possible for an attacker to successfully mount an offline dictionary attack by repeatedly attempting to decrypt, with successive entries from a dictionary, messages obtained which are encrypted under a key derived from the user's password.

We'll investigate the feasibility of exploiting one of Kerberos's vulnerabilities to design a point-and-click "l0phtcrack-style" password-cracking tool. We won't actually build the tool, but we'll consider what would be involved in making one and how well and how fast it might work in recovering passwords.

Password-based login is not the only option in Kerberos 5, nor is it the only option in Windows Server. It is also possible to log in using a public key-based scheme, PKINIT, which does not suffer from the problem outlined here. Windows Server includes support for this scheme too, with or without smart card assistance. This discussion applies only to the option that is enabled by default and is most widely used, which is to use passwords to log in.

14.3.2.1 Vulnerability

In order to mount an offline dictionary or brute force attack, some data that can be used to verify the user's password is needed. One way to obtain this from Kerberos 5 is to capture a login exchange by sniffing network traffic.

In Kerberos 5 a login request contains preauthentication data that is used by Kerberos to verify the user's credentials when a TGT is issued. The basic preauthentication scheme used by Windows Server and other Kerberos implementations contains an encrypted timestamp and a cryptographic checksum, both using a key derived from the user's password.

The timestamp in the preauthentication data is ASCII-encoded prior to encryption and is of the form YYYYMMDDHHMMSSZ (e.g., "20020304202823Z"). This provides structured plain text that can be used to verify a password attempt: if the decryption result "looks like" a timestamp, then the password attempt is almost certainly correct. A password attempt that recovers a plausible timestamp can also be verified by computing the cryptographic checksum and comparing it to the one in the preauthentication data.

14.3.2.2 Obtaining the password-verification material

Using a test Windows Server domain, we create a login attempt for the user "frank" with the password "frank"; the exchange is captured with the freely available sniffing tool WinDump (a Windows implementation of tcpdump). The captured exchange is investigated with the freely available ASN.1 decoder dumpasn1 (http://www.rtner.de/software/oid.html) and the Kerberos 5 specification.

As expected, the capture contained the following preauthentication data:

 2 30   72:   SEQUENCE { 4 A1    3:     [1] { 6 02    1:       INTEGER 2          :       } 9 A2   65:     [2] { 11 04  63:       OCTET STRING, encapsulates { 13 30  61:           SEQUENCE { 15 A0   3:             [0] { 17 02   1:               INTEGER 23          :               } 20 A2  54:             [2] { 22 04  52:               OCTET STRING          :                 F4 08 5B A4 58 B7 33 D8 09 2E 6B 34 8E 3E 39 90          :                 03 4A CF C7 0A FB A5 42 69 0B 8B C9 12 FC D7 FE          :                 D6 A8 48 49 3A 3F F0 D7 AF 64 1A 26 3B 71 DC C7          :                 29 02 99 5D          :               }          :             }          :           }          :       }          :     } 

The second octet string contains the encrypted timestamp that can be used to seed an offline attack. The details of this are publicly documented in the Internet Draft draft-brezak-win2k-krb-rc4-hmac-03.txt .

14.3.2.3 Decrypting the timestamp

The Brezak Internet Draft also contains a detailed description of how the RC4 key is derived from the user's password, as well as pseudocode for decrypting and verifying the timestamp. Implementing it is straightforward (the code here used the OpenSSL cryptographic libraries) and yields the necessary password test function for mounting an offline attack.

It is not necessary to compute the expensive embedded cryptographic checksum in order to verify a password ”you can simply decrypt it and search for an ASCII string that looks like a timestamp. If the decryption does not recover a timestamp, the password tried is incorrect. If the decryption does recover a timestamp, the password is almost certainly correct, and if you wish, you can use the cryptographic checksum in the encrypted data to further verify this. As most passwords tried will be incorrect, the overhead involved in doing this extra verification after the initial check for a recovered timestamp succeeds is minimal.