Protocol: An analogy

This lesson presents an analogy of the Kerberos protocol.

We have discussed the various components involved in the Kerberos operation in the previous lesson. In this lesson, we’ll look at a simplified analogy before presenting the actual Kerberos protocol interactions.

Kerberos authentication boils down to a two-step process:

  1. Obtaining the Ticket Granting Ticket from the Authentication Server (AS).

  2. Obtaining a Service Ticket for a service the client intends to communicate with. The Ticket Granting Service (TGS) dispenses a service ticket but requires the client to submit the TGT it received in step one.

In this lesson, we’ll examine the first leg of this interaction: obtaining a TGT from the AS.

We’ll construct an analogy to explain the Kerberos protocol. Say you are equipped with boxes that you can lock by using a colored key. If you lock a box with a red key, you can only open it using the red key.

You want to send a faraway friend some documents in a box but you have no way of ensuring that the box isn’t tampered with during transit, that it is really received by your friend, or that your friend can know for sure that the box came from you. In this imaginary setup there are two more actors, an oracle (Authentication Server) and a postman (Ticket Granting Server). Additionally, you are in possession of a red-colored key with which you can lock a box. Similarly, the postman has a yellow key and your friend has an orange key. The oracle also has a copy of your key and the postman’s key, while the postman has a copy of your friend’s key. The initial setup looks like this:

In order for you to be able to send the important documents to your friend, the following interactions must take place.

  1. You initiate the protocol by sending an empty box to the oracle.
  1. The oracle puts a green key in your box and locks it with your red key. The oracle also sends a second box that has a copy of the green key but is locked using the yellow key.
  1. You receive two boxes. You can open the red box as it is locked with the red key, and now you retrieve the green key. You have the second box, but you can’t open it since it is locked with the yellow key. The state of all the participants so far is shown below:
  1. Now you put a message in a new box, lock it with the green key, and send the two boxes to the postman.
  1. The postman first opens the yellow box, since only they possess the yellow key. Opening the yellow box allows the postman to retrieve the green key and open the green box. The postman reads the name of the friend you want to send the documents to.
  1. The postman prepares another box, places a blue key inside, and locks it with the green key. The postman also prepares an orange box, places the blue key inside it, and locks it with the orange key. The two boxes are sent over to you.
  1. You can retrieve the blue key by opening the green box and you can send the orange box to your friend.
  1. Your friend receives the orange box and can open it to retrieve the blue key.
  1. Eureka! Now both you and your friend are in possession of a blue key.
  1. You can prepare a box, place the treasure map in it and send it over to your friend who in turn can open the box since he also has the blue key. He can find the treasure, place the gold coins in the box, lock it with the blue key, and send back to you.

The above interactions describe the essence of the Kerberos protocol. The Kerberos protocol itself is based on the Needham-Schroeder protocol.

In the next lesson, we’ll map these interactions to the actual components of the Kerberos ecosystem.