In simplest words, Kerberos is an authentication protocol which can service requests over an untrusted network such as the Internet. Kerberos formed its name from Greek mythology which was a three-headed dog that guarded the gates of Hades. Similarly, in Kerberos authentication, we have three heads representing:

• A client
• A server
• A Key distribution center (KDC) – This is Kerberos third-party authentication service

KDC is an intermediary where the client as well as the server, require to trust KDC. KDC provides two services:

• Authentication service
• Ticket granting service

KDC authentication mechanism uses a shared secret key to allow packets traveling on the network to be transmitted in a secure way. This protects and prevents from replay attacks or eavesdropping.

The Tickets provide mutual authentication between the nodes to verify their identity in a secure way.

Kerberos Protocol

In brief, we have explained what exactly is Kerberos. Let us look at some details about the Kerberos protocol. The Kerberos protocol heavily works on shared secret key. To explain this, let us assume we have a host A which wants to communicate with server B. This is done in three phases. The KDC is a combination of:

• Ticket Granting Service - TGS
• Authentication Service – AS

Phase 1 – In this phase, the client has to authenticate itself and request a ticket from Kerberos. In turn, Kerberos will grant a ticket and a session key. The ticket will be used for requesting other tickets and services. The session key is used for communication between the client and the server.

Phase 2 – The ticket from the first phase is used by the client to request a ticket from the TGS.

Phase 3 – The client uses the ticket to communicate to the intended server.

In detail, a client sends a plain text request to the Authentication server (AS) to get a ticket in order to communicate with the TGS. The request contains a Login name along with the TGS name. The AS from its active directory gets the login name and authenticates this.

Once authenticated the AS will create a ticket which will contain:

• The login name – same as one shared by the host
• TGS name – same as one shared by the host
• Client network address
• TGS Session key

The AS then seals this using the TGS secret key. Along with this the AS also creates a random session key for the client and TGS communication. The session key and the already sealed ticket are then encrypted using the host secret key. This is again sent back from the AS to the host.

If the client is a valid client, then the complete sealed message can be decrypted using the client's secret key. The client will find the session key and the ticket. Note that the ticket cannot be decrypted by the client since this is sealed with TGS secret key.

Now the client will send a request to the TGS. The request will contain:

• The sealed ticket as sent by the AS to the client.
• Additionally, the client will send authenticator information which will be sealed with the session key.

The TGS will first decrypt the ticket with its secret key to obtain a session key. Using this session key, TGS will decrypt the authenticator information. Some basic validity checks and timestamp check is done at the TGS end.

This completes the initial part of authentication between the client and the TGS. Once this is done, TGS will generate a ticket for the client to communicate with the server. This ticket will contain:

• Ticket sealed with server B key.
• Creates a session key and the entire message is encrypted using the TGS session key.

This message is then sent back to the client. The client decrypts this message using the TGS session key. With this, the client has a new session key and a ticket to use for communicating with the server. The client will communicate to the server; in the same way, it did with the TGS.

Details about Kerberos

Kerberos is the primary authentication protocol for Windows server. This is also used by web services, email client, telnet, and FTP. Kerberos is an open standard. It supports mutual authentication and requires both clients as well the server to complete the authentication process. Kerberos supports multi-level authentication and hence is robust in many ways. The complete protocol does not require the client to share any password and hence is safe from packet sniffers and eavesdropping.

As long as the ticket timestamp is valid, the client can perform transactions. This does not require the client to re-authenticate itself. Kerberos uses renewable sessions wherein only the first time it needs to authenticate through the KDC.

• Kerberos architecture has a single point of failure. In case the Kerberos server is down, then no service will be accessible.
• The protocol is closely tied to timestamp between the requestor and the server. The clocks of the hosts need to be synchronized at all times
• The administration protocol changes between different server implementations. This is not standardized.
• In case KDC is attacked then the complete eco-system will be susceptible to hacks.
• The architecture requires each host to first register with the KDC and makes the overall architecture complex.