Kerberos Part 1

Ed. Note: This is a reprint, with some slight updates of a series that we started many years ago. Over the next few weeks we'll update all of the existing parts, and maybe even finish the series!

Apple made a decent sized splash in a relatively small pond when they announced the inclusion of a Kerberos Key Distribution Center ( kdc) with Panther Server. Prior to OS X Server 10.3 setting up a kdc on OSX was a real pain. With 10.3 and Open Directory 2.0 the kdc became almost an afterthought. It was automatically set up and done in a fairly elegant way that ensured that most admins didn't even know they were "kerberized."

This is all fine and good, but we're left with very few Mac admins really know what Kerberos is, let alone know what to do when it goes wrong. Hopefully this series will get you more than up to speed on what it is and what to do with it.

1. Introduction

First off we'll get the trivia out of the way. Kerberos is the Greek spelling of what is better known as Cerberus, the three-headed dog that guarded the underworld in Greek mythology. It's properly pronounced with a hard "k" sound and does not rhyme with Cerberus. The Massachusetts Institute of Technology has been running the project for over 20 years. Versions 1 through 3 were experimental. Version 4 was the first one to be used in production over a decade ago. However, there are some serious security issues with version 4, so now everyone should be using, as Apple does, version 5.

Kerberos does one thing, and only one thing. Lucky for us it happens to do it very well. Kerberos is a method of authentication and only authentication. That means it only validates username password combos. After that it's up to the service using the username and password to do the rest of the work. Kerberos doesn't not authorize a valid user to use a service, and it doesn't provide any services itself. It only authenticates.

Alright, Kerberos authenticates, big deal. There are a lot of authentication methods out there. APOP, Apple's SASL Password Server, PAM and a host of others all do this already. What Kerberos brings to the party is that it allows the authentication of a user without ever having to have that user's password go across the network. Every other popular service either just transmits the password to the server in plain text, or has a convoluted method for encrypting the password and then sending it across the network.

If Kerberos only did this, it would be cool, but not legendary. Kerberos goes one step further and allows for a single sign on (SSO) environment. This enables a user to enter their password once during login and never have to authenticate to a network service again. As this is going on, not only is the user's password never transmitted, but it is never cached on the local machine either. All in all an incredibly secure and ingenious solution to the authentication problem.

A number of SSO environment's depend on Kerberos for their SSO features. For example Microsoft's Active Directory leverages Kerberos in this way. You'll also find Kerberos tightly integrated into many Linux and other Unix-based identity management systems.

2. How it works

It's easiest to show how Kerberos does it's magic by walking through a typical Kerberos transaction.

Step 1 - A user, we'll call him Xander, sits down at the client machine and logs into the system. The local machine knows it's using Kerberos for authentication so it looks in a config file for the name of the Kerberos authentication server, commonly known as the kdc. The local machine takes Xander's login name, "xander", and creates the basic building block of Kerberos, a principle. This is just the user's short name followed by the Kerberos realm that the user belongs too. In our case Xander's principle is xander@AFP548.COM. The realm, AFP548.COM in our example, is commonly the DNS domain of the organization, although it can be anything you want. Using DNS domains keeps it simple and should prevent you from getting confused with someone else's realm. Also, Kerberos realms are traditionally done in all caps to distinguish them from the DNS domains that they are derived from. The local machine sends the principle to the kdc unencrypted. It has no real sensitive information, so there is no need to waste cycles on protecting it.

Client to kdc -> user principle

	xander@AFP548.com

Step 2 - The kdc, specifically the authentication server part of the kdc, gets the principle. It looks up the principle in it's user database looking for a match. This database is the central repository for all username/password combinations.

If Xander is a valid user, which he is, the kdc will find his entry. It can then pull Xander's password from the database. Since the client didn't send the password, the kdc can't tell at this point if the user is actually legit or not. So, the kdc engages in a bit of sneakiness. It crafts a message back to the client machine containing a Ticket Granting Ticket (TGT) and a session key encrypted with a hash of Xander's password.

The TGT, we'll get to in a bit. The session key is going to be used by the client and the server to encrypt any further communication between the two. From now on if the client sends a request to the server that isn't encrypted by this session key, the server will ignore it.

Ingenious!

The server can now be secure that the user is legit because valid communications after this will use the session key which the client could only get access to if it actually knew the correct password in the first place. Kerberos is full of domino-like events like this. They all have to be in place for the user to be valid.

kdc to Client -> the first session key, encrypted with a hash of the user's
password, and the TGT

	{SessionKey1}hashed user password, TGT

Step 3 - If Xander entered the correct password, the client system will be able to decrypt the session key. This tells the local machine to let Xander log in. So far so good.

The client also now has the TGT. This is literally the "ticket" to everything else that the client wants to do. The TGT is encrypted so that only the kdc can decipher it. The client has no way of getting access to what's actually in it. Which is fine since the client doesn't need to. From now on, instead of using Xander's password to ensure he is who he says he is, Kerberos will use the TGT instead. This means that, two packets and a few milliseconds after Xander has logged in, the system has validated him and then eradicated any trace of the password he just entered.

Step 4 - Xander's using his machine, he gets bored with his local off-line collection of AFP548.com articles. He would like to make sure that he has the latest collection. He knows that his wonderful admin keeps an updated archive on the server, so he'll just fileshare them over.

This is where step 4 kicks in. Xander is going to be using a network resource that is going to want him to authenticate. Since Kerberos is a single sign on solution, we can't ask for his password again. Instead the client machine is going to send Xander's TGT and a request to access the AppleShare fileserver, files.afp548.com, to the kdc. The request does not go to the fileserver itself. Files.afp548.com doesn't know what Xander's password is since all the passwords are kept in the kdc's database, so it can't authenticate him even if it wanted to.

To validate Xander to the kdc, the client machine will pack an authenticator into the request to the kdc. This is usually just a simple timestamp that has been encrypted with the session key that the client received from the kdc in the previous step.

So, for step 4 we have the TGT, exactly as it came from the kdc, the authenticator, which proves to the server that Xander is actually Xander, and a request to use an AppleShare server. The request takes the form of the service principle for the AFP server. Much like Xander has a principle in the kdc's database, the AFP server on files.afp548.com also has one. In our example the service principle would be afpserver/files.afp548.com/AFP548.COM. The first part is what we are going to be using, the afpserver, the second part is the DNS name of the server hosting the service, files.afp548.com, and the third part is the Kerberos realm, AFP548.COM.

Client to kdc -> the TGT to verify who we are, the service principle, which is
our actual request for a service, and then an authenticator encrypted with the
session key the client shares with the kdc to prove that the client knows the
original password

	TGT,service principle,{authenticator}SessionKey1

Step 5 - The kdc, specifically the ticket server part of the kdc, gets the request. It uses the shared session key to validate the user. It then uses the TGT, which contains the user principle, in this case xander@AFP548.COM, to begin crafting a "service ticket." This consists of two pieces. The first is the user principle from the TGT. The second part is a session key that the kdc generates which will be used to secure, and validate, the communication between the client and the service. Both of these pieces are encrypted with a password known only by the kdc and the service itself. This password is part of the process that occurs when you integrate the service, in our case the AFP server on files.afp548.com, into the Kerberos realm.

The kdc then includes a copy of this second session key encrypted with the first session key. Since the client doesn't know the service's password it won't be able to decrypt the second session key, so it needs a copy of it's own.

kdc to Client -> the user principle combined with the second session key
encrypted with the service key and the second session key encrypted with the
first session key

	{user principle, SessionKey2}ServiceKey, {SessionKey2}SessionKey1

Step 6 - The client can now authenticate itself to the service. This part will vary with each service since the Kerberos specification allows the individual developers to do what they want to here, but it usually goes something like this:

The client will send the user principle and second session key, which have been encrypted by the service's password, unchanged to the server. In addition to prove that it isn't just replaying a packet that it got off of the network, the client will create another authenticator. Again this is something simple like a timestamp. The client encrypts this with the second session key that it received in the last exchange.

Client to Service -> the same user principle combined with the second session
key and encrypted by the service key that the client received in the previous
step and an authenticator encrypted with the second session key

	{user principle, SessionKey2}ServiceKey, {authenticator}SessionKey2

Step 7 - So now we are back to the a similar brand of sneakiness that occurred with the original response from the kdc to the client. The service can decrypt the user principle/session key combo since it knows the password it shares with the kdc. This gives it access to the second session key, which it uses to decrypt the second half of the actual service request it just received. If it can successfully read this it has a very high degree of confidence that the client is actually who it says it is since it wouldn't be able to use the second session key if it didn't know the first session. Which it couldn't get access to if it couldn't decrypt the original kdc response if it didn't know the user's actual password.

If everything checks out with the service then Xander is authenticated to the AFP server. At this point, five packets later, Kerberos is done. It's now up to the AFP server to see if the user "xander" is actually authorized to use any of the sharepoints it is serving.

3. More complications

Those 5 packets were Kerberos in it's basic form. It works, and it does the job efficiently, but it does leave a few holes.

First off, since the kdc will happily give out a response encrypted by the user's password to anyone who sends it a username, the second step in our example above, passwords can be vulnerable to an off-line dictionary attack. In this case an evil person, perhaps at smb139.com, could send a user principle to the server, record the response and then devote a large amount of computing resources at their leisure off-line to crack the encryption. After which the ner-do-well would have access to the password hash. Still not the password itself, but enough to convince Kerberos that it is that user.

Good password policies that force the users to have long non-dictionary passwords mitigate this attack. However, users don't always follow good password policies. So, to prevent this attack Kerberos has a feature to have the client send an authenticator, this time a timestamp encrypted with the user's hashed password, to the kdc before it will respond with step 2.

A second hole in our scenario is step 7. Sure, Xander has authenticated himself to the AFP server, but who's to say the AFP server is legit? Smb139.com could have hacked afp548.com's DNS server and redirected communications to it's servers. The evil server would happily accept the client's packet in step 6 and act like everything is cool. Even though the evil server can't make sense of anything in the packet it could have been set up to look and act like the real file server. However, horror of all horrors, the sneaky bastards at smb139.com have replicated the article database, with the exception of doing a search and replace swapping Apple with Amiga, and good with bad.

To prevent this, Kerberos also has the functionality to have the service respond with an authenticator, another timestamp encrypted with the second session key, before the client will actually go through with the connection.

You can even go another step and tie TGTs and service tickets to specific IP addresses. In this case the kdc would incorporate the client's IP address into the tickets. If the request came from another IP, even if the request was good otherwise, the kdc would ignore it.

The big problem with this is that it really doesn't play nice with NAT and other services like VPNs that need to change the headers on a packet to work. So, in order to keep things working Apple has defaulted to addressless tickets, although you can re-enable this if you want.

4. Pervasive security

In addition to the optional bits I've mentioned above, Kerberos has a number of always-on features that lock things down.

Every communication is timestamped. If the timestamp is more than 5 minutes off, this can be adjusted on a per site basis, then the request is invalid. This helps prevent any monkey business by people replaying packets at a later time. It also means that all of your servers and client machines need to be using the same clock. Network time servers always play a role in Kerberos.

Also Kerberos servers keep a log of what packets they have received. Once a packet has been accepted it can't be used again. This also prevents a replay attack, potentially disallowing a baddie from replaying a packet even if it is within five minutes of when it was originally sent since the original packet has a good chance of getting to the server first.

In addition to the five minute window for service tickets, the TGTs themselves are only good for 8-10 hours. They need to be renewed after that, which Kerberos can do automatically. However if an attacker was able to compromise your TGT, they would only be able to use it for 8-10 hours before having to break into your system all over again.

5. DNS, DNS, DNS

Malfunctioning or non-existent DNS is pretty much a deal killer with Kerberos. There are ways around this, but they are ugly, they smell, and will probably break shortly after you set them up.

As you should have noticed by now the Kerberos realm goes hand in hand with your DNS domain. Also all of the principles reference DNS names for the servers that they correspond with. DNS needs to be working well for Kerberos to work well.

For extra credit you can even use DNS to let your clients know where your kdc is and if you have a backup. We'll talk more about this later on.