Secure your application with Kerberos

kerberos Apr 16, 2021

Network security has always been the talk of the town. Several protocols in market helped us to stay secured in this world of malicious attackers and Kerberos is one of them. Kerberos has made the internet secure, and enables users to focus on work on the Internet without compromising safety.
Let's understand the workflow of Kerberos in detail.

Kerberos is a network security protocol that authenticates service requests between two or more trusted hosts across an untrusted network. It is currently the default authorization technology used by Microsoft Windows, and implementations of Kerberos exist in Apple OS, FreeBSD, UNIX, and Linux.

Contrary to traditional approach of storing passwords locally or sending over the internet, Kerberos follows 'ticket based approach'. It identifies nodes to communicate over the non-secure network through these tickets. Here, ticket will act as your proof of identity encrypted with a secret key for the particular service requested – on your local machine. As long as the ticket is valid, you can access the requested service that is within a Kerberos realm. Your ticket is refreshed when you sign on to your computer, or when you kinit USER within your terminal.

Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. After a client and server has used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity as they go about their business.

What is Kerberos Realm?

Kerberos Realm defines 'who can access what'. Admins create Kerberos realms i.e. what all is available to access. Your machine, the Client, lives within this realm, as well as the service or host you want to request and the Key Distribution Center, KDC.

According to Cloudera documentation:
"The realm is similar to a domain in DNS in that it logically defines a related group of objects, although rather than hostnames as in DNS, the Kerberos realm defines a group of principals . Each realm can have its own settings including the location of the KDC on the network and supported encryption algorithms."

Components of Kerberos:

Client: The client can perceive as the user and used to initiate communication for a service request
Server: The server hosts the service the user wants to access
AS: This is the place where actual authentication happens. In case of a successful authentication, a ticket called TGT (Ticket Granting Ticket) gets issued to the client by AS to assure the other servers that the client is authenticated.
KDC: In a Kerberos environment, the authentication server logically separated into three parts: A database (db), the Authentication Server (AS), and the Ticket Granting Server (TGS). These three parts, in turn, exist in a single server called the Key Distribution Center.
TGS: The TGS is an application server that issues service tickets as a service.

Let me demonstrate how Kerberos ensured security in my project:


To access the HDFS Service to put some files, first I need to introduce myself to the Authentication Server. Logging into computer, or kinit USERNAME. This command will start an introduction that initiates with a plaintext request to get a Ticket Granting Ticket (TGT). This request comprises of:
- Name/ID
- The name/ID of the requested service (in this case, service is the Ticket Granting Server),
- Network address (may be a list of IP addresses for multiple machines, or may be null if wanting to use on   any machine), and
- Requested lifetime for the validity of the TGT

The Authentication Server will check the username existence in the KDC database (no credentials are checked at this point)


The Authentication Server will then send back two messages. One message is the TGT that is encrypted with the TGS Secret Key. This'll contain:

  • Name/ID,
  • The TGS name/ID,
  • Timestamp,
  • Network address,
  • Lifetime of the TGT,
  • TGS Session Key

The other message will be encrypted with the Client Secret Key. The client secret key is not transferred but is retrieved from the password (more to speak the hash) found in the user database. This happens all on the server side. The message contains:

  • The TGS name/ID,
  • Timestamp,
  • Lifetime (same as above), and
  • TGS Session Key


These messages are then delivered to the client and the user is requested for the password. The password is then converted (hash, appending a salt (made up of user@REALMNAME.COM)) to the client secret key. Note that this key was also generated on the server side in the previous step.
This key can be used for decrypting the second message in order to obtain the TGS Session Key. Message can't not decrypted with an incorrect password.

The encrypted TGT is stored in credential cache.


Still the TGT can't be read as the TGS Secret Key is needed to decrypt it. Though we have the TGS Session Key now. The next step is to send two messages. First message is the prepared Authenticator, encrypted with the TGS Session Key, containing:

  • Name/ID
  • Timestamp

Another one is an unencrypted message that contains:

The requested HDFS Service name/ID we want to access, and
Lifetime of the Ticket for the HDFS Service,

Now send these messages (unencrypted message along with the encrypted Authenticator) and TGT to the Ticket Granting Server.

The Ticket Granting Server checks the KDC database to see if the HDFS Service exists.

If yes then TGS decrypts the TGT with its Secret Key. Since the now-unencrypted TGT contains the TGS Session Key, the TGS can decrypt the Authenticator you sent.


The TGS will then do the following:
- Compare the client ID from the Authenticator with the TGT
- Compare the timestamp from the Authenticator with the TGT
- Check to see if the TGT is expired (the lifetime element),
- Check that the Authenticator is not already in the TGS’s cache (for avoiding replay attacks), and
- If the network address in the original request is not null, compares the source’s IP address to your network address (or within the requested list) within the TGT.


The Ticket Granting Server then randomly generates the HDFS Service Session Key, and prepares the HDFS Service ticket that is encrypted with the service secret key and contains:

  • Name/ID
  • HDFS Service name/ID
  • Network address
  • Timestamp
  • Lifetime of the validity of the ticket
  • HDFS Service Session Key

Then the TGS sends you two messages. One is the encrypted HDFS Service Ticket; the other contains the following:

  • HDFS Service name/ID
  • Timestamp
  • Lifetime of the validity of the ticket
  • HDFS Service Session Key

that is encrypted with the TGS Session Key.

Our machine decrypts the latter message with the TGS Session Key that it cached earlier to obtain the HDFS Service Session Key. However, our machine can not decrypt the HDFS Service Ticket since it’s encrypted with the HDFS Service Secret Key.

To now access the HDFS Service, our machine prepares another Authenticator message that is encrypted with the HDFS Service Session Key and contains:

  • name/ID,
  • timestamp,

Machine will then send the Authenticator and the still-encrypted HDFS Service Ticket received from the TGS.

The HDFS Service then decrypts the Ticket with its Secret Key to obtain the HDFS Service Session Key. It then uses that Session Key to decrypt the Authenticator message you sent.


Similar to the TGS, the HDFS Server will then do the following:

  • compares your client ID from the Authenticator to that of the Ticket,
  • compares the timestamp from the Authenticator to that of the Ticket (typicalKerberos-system tolerance of difference is 2 minutes, but can be configured otherwise),
  • checks to see if the Ticket is expired (the lifetime element),
  • checks that the Authenticator is not already in the HDFS Server’s cache (for avoiding replay attacks), and
  • if the network address in the original request is not null, compares the source’s IP address to your network address (or within the requested list) within the Ticket.


The HDFS Service then sends an Authenticator message containing its ID and timestamp in order to confirm its identity to you and is encrypted with the HDFS Service Session Key.


The client then reads the authenticator message by decrypting with the cached HDFS Service Session Key, and knows that it has to receive a message with the HDFS Service’s ID and timestamp. And now you have been authenticated to use the HDFS Service. Future requests use the cached HDFS Service Ticket, so long as it has not expired as defined within the lifetime attribute.

That's how Kerberos ensures security. Hope it helped you understand the details of Kerberos. Happy Coding!



Tech Enthusiast