Using Kerberos

Let’s take a look at the model because we have to serve a role within Kerberos. The first of those is the authentications server, the second is the ticket granting server. So this process, I’ve split up over a number of slides just because it is long, it is complicated. OK, so I’ll give an overview. I’ll talk through each of these steps. Now the first starting point for this is that the user logs on to the client. So we’re separating out the user and the client as part of this transaction. The user enters their username and their password onto the client, and the client transforms the user password into the key of a symmetric cypher, into a key that can be used.

The client then sends a plain text message, an open message of the user ID to the requesting services on behalf of the user. So neither the secret key nor the password is transmitted to the authentication server, the authentication server that AS checks to see if the client is registered in its database. Now, for a client to be registered in its database, this presupposes that something like Active Directory has shared information with the authentication server. So this is where the trusted third party comes in. If the client ID is in the authentication server database, it sends back the following two messages to the client.

Firstly, a client TGS session key, and this is encrypted using the secret key of the client user. And secondly, a ticket granting ticket, a TGT. And this includes the client ID, the client network address, a validity period, and the client TGS session key. And this is encrypted using the secret key of the TGS, the ticket granting server. At this point, the client cannot decrypt that second message. That second message is encrypted with the secret key of the ticket granting server.

The first message though, if the user-entered password matches the password in the authentication server database, and again, that presupposes that link to Active Directory for it to have access to that database, then it will be able to decrypt the first message. That first message containing the client TGS session key. So then we move forward and the client will request services from the ticket granting server. It now has a way of communicating with the ticket granting server because it has the ticket granting ticket. So it sends the following message to the ticket renting server, it sends two messages to the ticket renting server. Firstly, the ticket granting ticket, that it received from the authentication server.

And secondly, something we call an authenticator. Now, the authenticator is composed of the client ID and the time stamp. And this is encrypted using the client TGS session key. So the client TGS session key is what gives us the ability to talk to the ticket granting server. The ticket granting server retrieves the message from the client, decrypts it using the TGS secret key. It has that key so it can decrypt that packet. And it gives the client a client TGS session key. Using this key, the ticket granting server can decrypt the authenticator message, and it can compare the client ID to make sure that they match from the two messages to make sure that they match.

If they do match, it will send to the client

two more messages: a client to server ticket which includes the client ID, the client network address, a validity period, and the client server session key. And this is encrypted now with the services secret key. And the second message is the client service session key encrypted with the client TGS session key.

So now, the client can send to the service the information it’s received from ticket granting server. And the client has enough information to authenticate itself now to the service. The client connects to the service and sends two messages. Firstly, the client server ticket that its received from the ticket granting server. And this is encrypted using the service’s secret key. Secondly, it sends a new authenticator. And this new authenticater includes the client ID, a time stamp, and it’s encrypted using the client server session key. The service can then decrypt the message using its own secret key to retrieve the client server session key. Once it has the client service session key, it can form a secure channel with the client.

So the service provider decrypts the client to serve a ticket key using its own key. This provides the client server session key. And using this, the service decrypts the authenticator. And if it matches, again, if the client ID matches it sends the client timestamp from the authenticator back to the client, encrypted using this client server session key. And the client checks the timestamp. If it matches, if it’s within the tolerance, then a trust relationship is established. So Kerberos is fairly complicated in forming a session, a trusted channel, but it is a very strong model. We said version five has been in use since 1993. Microsoft have used this since 2000 within Windows 2000, onwards.

So it is a very strong model. It’s not usable in every set of circumstances because of that need for the trusted third party. And again, we do need those two Kerberos roles to exist for us to begin using Kerberos.