What is Kerberos

Kerberos is a network authentication protocol based on conventional cryptography; that is to say, it relies on symmetrical cryptographic algorithms that use the same key for encryption as for decryption (“Ferguson and Schneier 2003”:BookBibliography). Network authentication protocols do two things: help you discover who is on the other end of the wire, and help you and your peer exchange a cryptographic key (also known as a session key) so you can maintain integrity and confidentiality protection for the ensuing conversation. What follows is a simplified description of Kerberos that will help you understand what's going on under the hood in Windows.

Kerberos gets its name from the mythological three headed dog that guards the entrance to Hell. The three heads can be thought of as representing the three entities involved: the client, the server, and a trusted authority known as the Key Distribution Center, or KDC (in Windows, each domain controller acts as a KDC, with Active Directory hosting the security account database, as mentioned in WhatIsASecurityPrincipal). The KDC is the keeper of secrets. Say Alice and Bob are members of some Windows domain. They each share a secret password with the domain controller (KDC) for that domain. Now, technically, the KDC doesn't know the cleartext password but rather a one-way hash, which is used as the basis for a cryptographic "master key." So Alice shares a master key with the KDC, and Bob shares a different master key with the KDC. Alice doesn't know Bob's master key, and Bob doesn't know Alice's, so neither has a direct way of verifying the other's identity. The KDC must get involved and introduce Alice to Bob, and Alice and Bob must trust what the KDC says (you can see why the security of domain controllers is paramount). Figure 59.1 shows this relationship.

Figure 59.1 The three heads of Kerberos

The essence of Kerberos is key distribution. The job of the KDC is to distribute a unique session key to each pair of security principals that want to establish a secure channel. To illustrate this, I'll describe a simplified version of Kerberos first to help you get the basic idea; then I'll show what bits I omitted and provide a more complete story.

Say Alice wants to communicate with Bob. She sends a message to the KDC stating, "I'm Alice, and I'd like to talk to Bob. Help me out here, will you?" The KDC obliges by generating a random cryptographic key for Alice and Bob to use (let's call this K_ab) and sends two copies of it back to Alice. The first copy is for her to use and is sent to her along with some other information in a data structure encrypted using Alice's master key. The second copy is packaged along with Alice's name in a data structure known as a "ticket." The ticket is encrypted with Bob's master key and is effectively a message to Bob saying, "This is your KDC. Alice wants to talk to you, and here's K_ab, a session key that I've created for you and Alice to use. Besides me, only you and Alice could possibly know the value of K_ab, because I've encrypted it with your respective master keys. If your peer can prove knowledge of this key, then you can safely assume it's Alice." Figure 59.2 shows this exchange.

Figure 59.2 Alice asks the KDC for a ticket for Bob.

Now Alice must send the ticket to Bob along with proof that she knows K_ab, and she must do it in a way that allows Bob to detect replays from attackers listening on the network where Alice, Bob, and the KDC are conversing. So she sends the ticket to Bob along with what's called an authenticator, which is simply a data structure containing her name and the current time, all of which is encrypted with the session key, K_ab. Bob takes the ticket, decrypts it, reads the message it holds from the KDC, pulls K_ab out of the ticket and decrypts the authenticator using it, and compares the name in the authenticator with the name in the ticket (this provides evidence that the authenticator was indeed encrypted with K_ab; otherwise, the name in the authenticator would come out garbled when Bob decrypted it). Finally, Bob checks his replay cache, which is a list of recently seen authenticators, making sure he's never seen this particular authenticator before (this mitigates replay attacks). If Alice's timestamp isn't within five "minutes"¹ or so of the current UTC time on Bob's wall clock, he simply rejects the request with a hint of what his clock says (time isn't a secret, after all). This allows Bob to prune his replay cache so it doesn't grow without bound, and Alice can retry with a fresh authenticator that Bob will accept. Note that keeping clocks synchronized is important in Kerberos, which is why domain controllers normally provide a time service as well as a Kerberos KDC.

Whoever is on the other end of the wire has claimed to be Alice, and Bob wants to verify that whoever it is really knows K_ab, which will prove to him that it's indeed someone who knows Alice's master key. Assuming all goes well, Bob accepts this authenticator as proof that it's Alice on the other end of the wire.

If Alice wants Bob to prove his identity as well (this is the optional mutual authentication feature in Kerberos), she indicates this in her request to him via a flag. Once Bob is satisfied with Alice's proof, he takes the timestamp she sent, encrypts it with K_ab, and sends it back to her. Alice decrypts this and verifies that it's the timestamp she originally sent to Bob. She now knows that whoever is on the other end of the wire knows K_ab and infers that it's Bob because only he could have decrypted the ticket to retrieve K_ab.² Figure 59.3 shows this exchange.

Figure 59.3: Alice authenticates with Bob

As I explained earlier, this isn't truly Kerberos, but it's close. Real Kerberos includes an extra step for additional security. When Alice first logs in, she actually asks the KDC for what is called a "ticket-granting ticket," or TGT. This is just like the ticket she gets for Bob, except it's designed for use with the KDC and is thus encrypted with a very strong master key known only to the KDC. The TGT contains a session key (let's call it K_ak) to be used by Alice in her communications with the KDC throughout the day. So, in Figure 59.2, when Alice requests a ticket for Bob she actually sends along her TGT plus an authenticator with her request. The KDC then sends back Alice's copy of K_ab encrypted with K_ak (as opposed to Alice's master key, as I described in my earlier, simplified description). What does this buy us? It reduces the exposure of Alice's master key. Theoretically she doesn't even need to remember her master key once she receives the TGT.³ Besides, it's a really good idea to avoid encrypting lots of data with long-term keys (the master key doesn't change until Alice changes her password).

To summarize, a Kerberos credential consists of a ticket plus the associated session key (a copy of which resides inside the ticket for the server's use). As a client authenticates with various servers on the network, she collects these credentials in a cache in her logon session (WhatIsALogonSession). The ticket itself is useless to an attacker without the associated key, although there's the possibility of using it to perform a dictionary attack against the server's master key, which is a subject I'll return to later in this item.

From a purely practical standpoint, what do you think will happen if you go into Active Directory and reset the password for a service account? Any tickets issued from that point forward for the service will be encrypted using the new master key. This means you'd better shut down and restart the service process so that it knows its new master key; otherwise, anyone trying to authenticate with that server will fail! What about clients that already authenticated with that server earlier in the day? Their tickets won't be usable after the server restarts with a new master key. When they try to reconnect to the server they will fail to authenticate. Having these clients log out and log back in (or, more simply, clearing the ticket cache using a tool like kerbtray.exe, which comes with the Windows 2000 server resource kit) solves the problem. It's probably best to change service account passwords late at night after most folks have gone home!

Here's another practicality about Kerberos. It doesn't work well over the Internet. Imagine being at company A and trying to authenticate with a KDC at company B. The firewall for company A probably isn't going to let you make outgoing requests unless you're doing it over port 80, with HTTP. A Kerberos KDC expects to receive TCP or UDP requests over port 88. So, until we start tunneling Kerberos over port 80 (as we seem to be tunneling everything else these days with Web services), don't expect Kerberos to take over the Internet! Where you'll find it used mostly is on the corporate intranet.

Cross-Domain Authentication and Domain Trusts

What if Alice and Bob aren't in the same domain? Let's say Alice is in DomA and Bob is in DomB. In this case, no one single authority knows both Alice's and Bob's master keys. This is where trust relationships come in. If DomB trusts DomA, by definition it trusts DomA to issue TGTs on its behalf. So what Alice needs to do in this case is go to her own authority (DomA), present her TGT and a fresh authenticator to prove her identity, and ask for a TGT for DomB. But here's the rub: If DomA issues a TGT for DomB, that ticket must be encrypted using a key that both DomA and DomB share! Otherwise, how would DomB ever be able to decrypt it? This is what a trust relationship in Kerberos establishes: a shared secret between authorities. If you've ever established a trust relationship manually (via the Active Directory Domains and Trusts MMC snap-in), you know that a password is required; this is what that password is used for (if you set up a manual trust, make sure the password is at least 20 characters long and randomly generated!)

Once Alice gets a TGT for DomB, she can proceed as I described earlier, presenting her TGT plus a fresh authenticator to DomB and asking for a ticket for Bob, then sending Bob this ticket plus a fresh authenticator.

Now, more generally, transitive trusts are possible in Kerberos. If authority A trusts B, and B trusts C, then A trusts C indirectly. But what if a principal in A wanted to authenticate with a server in C? She would have to follow the trust path, getting TGTs for each domain in the path. But because she's caching each ticket in her logon session, she has to transit any given trust path only once per day. That’s because once she's got a TGT for a particular authority, she can authenticate directly with that authority as long as her TGT hasn't expired. Once her TGT expires (technically it can be renewed for up to seven days before this happens), she'll need to transit the trust path again from the beginning. Active Directory domains are set up to take advantage of this transitive trust. Each domain you create in a tree has a trust relationship with its parent and all of its children. And the root domain of each tree in a forest has trusts with every other root domain in the forest. This means you can have 100 domains in a forest, and all of them will have Kerberos trusts either directly or indirectly (via transitive trust) with each other. I've shown this in Figure 59.4.

Figure 59.4 Transitive trust in a forest

In the Figure, Alice in domain C needs to talk to domains C, A, B, and D, in that order, to transit the trust path to the server in domain D. But once she's done that, as long as she doesn't log out (thus losing her logon session and its associated ticket cache), and as long as her tickets haven't expired, she can talk to any servers in domain B (for example) without having to talk to domains C or A again. An administrator can short-circuit this trust path by manually adding a trust from D to C as well. This allows Alice to get to resources in domain D a bit quicker and more reliably (otherwise, if domain A or C is out of commission when she first tries to transit the trust path, Alice is out of luck). Note that all of this complexity is hidden from programmers. Even if you were adding Kerberos support to an application manually (as I do in WhatIsSSPI), you wouldn't need to worry about transiting trust paths. The client-side Kerberos plumbing in Windows takes care of that automatically when you initiate an authentication handshake with a server. But I still think it's important to know what's happening, because you'll develop a better intuition for solving problems that way, and you'll better understand domain administration as well.

What Else Is in a Ticket?

In the previous discussion, I omitted some details in order to focus on how Alice proves her identity to Bob. Let me now fill in some of the more practical details that you might find interesting. The first is that tickets contain group SIDs. This allows a domain controller to communicate domain group membership to servers, avoiding the need for the server to make a network round-trip to discover this information. Considering the way groups work in Windows (WhatIsAGroup), this can actually mean contacting two domain controllers if the client and servers are in different domains. But it also means that there can be significant latency (typically up to 10 hours) in the domain group SIDs a server receives for a client. Say, for example, that the client authenticates with the server first thing in the morning, disconnects, and is removed from a domain group at lunchtime. If the client is still logged in at the end of the day and connects and reauthenticates with that same server, she'll be sending the same ticket to the server, with the same set of groups. The server will believe the client is still in a group when she's actually been removed. The only way to clear up this discrepancy is for the client to retrieve a fresh ticket before going to the server, and that will only happen if the client's ticket cache has been purged or if she's logged out and logged back in. In WhatIsSecurityContext, I mentioned the same type of problem that servers have caching security contexts (tokens) for clients. Well, it turns out that even if you throw away the client's token and force her to reauthenticate, when Kerberos is in use it's likely that you'll still have up to 10 hours of latency in the resulting group SIDs.

Kerberos tickets also contain times. These times include a window during which the ticket is valid plus a limit on how long the ticket can be "renewed." As I hinted earlier, tickets are valid for 10 hours from the time the client first logged in, but they can be renewed before they expire for up to 7 days. All of these numbers can be changed via Kerberos security policy, which is part of group policy (WhatIsGroupPolicy). Renewal allows the KDC to verify that the client's account hasn't been disabled and allows fresh group SIDs to be placed in the new ticket. The time limitations are there to reduce the window during which an attacker can use a stolen ticket.

Kerberos tickets may contain network addresses restricting their use. Thus, if Alice is at IP address 67.129.90.150 when she requests a ticket for Bob, her ticket may specify that it must be used from 67.129.90.150 and no other address. This makes an attacker's life a bit harder by forcing him to either use the ticket from Alice's machine or spoof Alice's IP address.

User-to-User Authentication

Bob (the server in our example) has a master key that may often be exposed to dictionary attacks because the KDC encrypts all tickets for him with his master key. Say Alice wants to know Bob's password. She knows that if she asks for a ticket for Bob, that ticket will be encrypted with Bob's master key, which is derived from his password. So Alice can use a ticket for Bob to mount a brute-force or dictionary attack against his password.

With most password-based systems, you need to choose good passwords to foil brute force or dictionary attacks by eavesdroppers. Humans have trouble remembering long passwords, but if you're configuring an account specifically for a daemon (WhatIsADaemon), remember that a machine can remember much better passwords than a human can! So be sure to use extremely long, randomly generated passwords for servers. For example, if you randomly generate a 20-character password that includes upper- and lower-case letters, numbers, and punctuation, you'll have about 128 bits of entropy, which leads to a very strong master key. Settle for no less! For some sample code that randomly generates passwords like this, you might want to look at my Password Minder tool, which you can download from this book's Web site .

But what if some of our servers aren't daemons? What if we're using Kerberos to do peer-to-peer authentication, and Bob is a real human with a less than stellar password? Well, first of all Bob's password better not be too weak, because when he first logs in an attacker eavesdropping on his TGT request can use that information to mount a dictionary attack against his password (the TGT is encrypted using Bob's master key). But throughout the day, as other peers connect to Bob they're constantly sending him tickets encrypted with his master key, giving the bad guy even more chances to attack. Plus, didn't I say earlier that Kerberos allows the client to forget her master key once she receives her initial TGT? If Bob (a peer-to-peer agent—acting as both a server and a client, or "servent") has forgotten his master key, how can he possibly decrypt incoming tickets?

Kerberos includes a feature known as "user-to-user" authentication to help with these situations. The idea is to avoid encrypting tickets with the master key of a servent. Here's how user-to-user authentication works. Before talking to the KDC, Alice first contacts Bob and asks for a copy of his initial TGT. Bob sends this to Alice (remember a ticket alone without the corresponding key is useless — Alice can't use this to pretend she's Bob). Alice then makes her normal request to the KDC, asking for a ticket for Bob. But she includes an additional ticket with her request: Bob's TGT. The KDC decrypts Bob's TGT and retrieves the session key that Bob and the KDC use to communicate. It then uses this session key, which is long and random and thus not vulnerable to dictionary or brute-force attacks (as Bob's master key might be), to encrypt the ticket sent back to Alice. It's a tradeoff between performance and security; an extra round-trip or two in the morning seems like a reasonable price to pay for reduced exposure of Bob's master key. But how does Windows know when to use this feature? How does it know when the server you're contacting is actually a servent with a potentially vulnerable password?

Windows Server 2003 makes this decision based on whether the target server account has been anointed with at least one service principal name (SPN). If you've configured your service to run as Network Service or SYSTEM, then you don't need to do anything special because a machine account always has a set of SPNs defined for it by default. But if you've set up a custom domain account to run your server, you'll want to add an SPN to it; otherwise, you'll be suffering extra round-trips for user-to-user authentication for no good reason. Besides, you'll want your clients to use the SPN to identify the server anyway, as you'll learn in WhatIsAServicePrincipalNameSPN.

¹ The allowable skew, along with other Kerberos parameters such as ticket lifetime, is configurable via security policy.

² The KDC also knew K_ab at one time (the KDC generated the key in the first place, remember?) and could very well be impersonating Bob or could have leaked K_ab to a bad guy, but remember that Alice and Bob must trust the KDC not to play these games. Domain controllers must be carefully guarded against compromise!

³ I say theoretically because Windows does cache the client's master key in her logon session for use with an older protocol called NTLM, and to request a new TGT after the one she has can no longer be renewed.

PortedBy RubenBartelink