Kerberos Effect

Cerberus, the multi-headed dog, guarding the gates of the Underworld to prevent the dead from leaving. It is often called the "hound of Hades", god of the Underworld.

But, this is greek, how is this related to information security?

Kerberos is a computer network authentication protocol that works on the basis of tickets. How this works is that tickets are used to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner.

One can ask why are these required when we can use firewalls to solve network security problems? One drawback of the firewall is that it assumes the "bad guys" are on the outside, which is often a terrible assumption. In fact, most of the damaging incidents of computer crime are carried out by insiders.

Kerberos was created by MIT (Massachusetts Institute of Technology) as part of their protection program of the services provided by Project Athena.

The Kerberos ticket exchange is built around two principles:

1. Strong mutual authentication; and

2. Restricted access.

Take an example of a client (user, or Alice, sitting behind a computer) needs to access a network file server to read a file. Now, both, the server and the client ( Alice) decided to involve Kerberos authentication protocol to be sure of their identities.

Please note that Kerberos uses symmetric-key cryptography where a single key is employed for both encryption and decryption.

In an unsafe world of the internet, how will the server confirm that the message of Alice is indeed from Alice before it processes the message? This is resolved by the use of information of the shared secret key to confirm the identity of another end party. 

The client or the Alice sends the message that includes the client's name in plain text and an authenticator in encrypted form using a secret key. The authenticator is the data structure that includes two fields- The client's name and timestamp of the client's workstation.

After receiving the message, the server decrypts the authenticator with the secret key and checks the timestamp on the server-side. If the difference is within the acceptable skew, the server decides that the message is probably from Alice and if not, the message is automatically rejected.

Now, after this, in order to inform Alice that the server had received the message, Alice's encrypted timestamp with the secret key is sent by the server. Since the server sends only the timestamp rather than all other details from Alice's authenticator, the client can confirm that no one has received this message other than the server.

Now, the trick is to secure the secret keys shared between the client and the server, as both the parties use the same secret key. Also, in the real world, clients talk to several servers and vice versa. To address this problem, a Key Distribution Center (KDC), a trusted intermediary, is used.

KDC maintains a database of account information of the entire security principals in its empire. The cryptographic key that is kept secret between the KDC and security principal is one of the account information in the database. This key is usually a long-term key.

So, when the client wants to communicate with the server, it sends a request to KDC. Then, KDC distributes a session key for both the client as well as the server, wherein encrypted form client's copy is encrypted with the client's long term key and server copy with the server's long term key.

The funny thing about the above statement is that the client can start communicating with the server at any time either immediately after receiving the session key or after some time. Under the circumstances, the server needs to either store the session key that it received from KDC and also remember it for the client as part of handling the service every time the client requests. To avoid the bottleneck situation, instead of sending the session key to the server, the KDC sends the sever's copy of the key in the form of a session ticket to the client.

Now, the client receives the client's copy with the encrypted client's long term key and also the server's session key in a data structure known as Session Key. Now, the client holds the responsibility to manage the session ticket until it reaches the server. Now, the client can communicate with the server at any point after receiving the response from KDC.

Now, when the server receives the message, it decrypts the session ticket using the secret key (shared between the server and KDC). Then, extract the session key to decrypt the authenticator.

Now, we need to know that, the client's session key sent from KDC to the client is encrypted using the client's long term key. And, the client's long term key is taken from the credentials that are used to log-on to Alice's workstation by way of a one-way hash function. To enhance security, the session key was used in place of a long-term key.

So, when Alice, logs into her workstation, a long-term key is generated and a request is sent to KDC for a session key that is required between the KDC and the client. Upon receiving the request from Alice, KDC fetches the long-term key of Alice's from its database and responds its back to the client as Ticker Granting Ticket (TGT). TGT includes the session key, that is used in the communication between KDC and client. Note that TGT is encrypted with the long-term key of KDC and Client's session key is encrypted with the Client's long-term key. The session expires once the TGT is completed or expired.

Now, Alice can request a service from the server by sending a message that includes TGT and authenticator that is encrypted using the session key shared between client and KDC.