The Three-Headed Hound of the Underworld (Kerberos)

Kerberos is simply a “ticket-based” authentication protocol. It enhances the security approach used by password-based authentication protocol. Since there might be a possibility for tappers to take over the password, Kerberos mitigates this by leveraging a ticket (how it is generated is explained below) that ideally should only be known by the client and the service.

When a client requests access to a service, it has to communicate with three parties. Each communication involves the use of “ticket”. Those parties are:

• the Authentication server
• the Ticket Granting Server
• the service it want to connect to

Both the Authentication Server and the Ticket Granting Server live within the Key Distribution Centre (KDC). KDC is simply a third-party used to authenticate the access request from the client to the service.

The Client & the Authentication Server

Step 1. This is the first authentication step. When the user does the login or executes kinit USERNAME command, the client sends out an information to retrieve the Ticket Granting Ticket (TGT). Such an information consists of the followings:

• The Client ID
• The ID of the Ticket Granting Server
• The Client IP address
• Validity period of the TGT

Step 2. The Authentication Server performs a check to see whether the Client ID exists in the KDC database.

Step 3. If the client exists in the KDC database, then the Authentication Server will randomly generate a key called TGS SESSION KEY. This key will be used for communication between the client and the Ticket Granting Server.

Step 4. The Authentication Server sends back two messages to the client.

The first message is the TGT which consists of the followings:

• The Client ID
• The TGS ID
• Current Timestamp
• The Client IP address
• Validity period of the TGT
• TGS SESSION KEY

The above message (TGT) is encrypted using the TGS SECRET KEY.

Meanwhile, the second message (let’s call it Ticket Granting Server Session Key) consists of the followings:

• TGS ID
• Current timestamp
• Validity period of the TGT
• TGS SESSION KEY

The above message is encrypted using the CLIENT SECRET KEY. This client secret key is password plus a salt that are hashed using a certain algorithm that was selected during the Kerberos setup.

Step 5. Upon receiving back the two messages, the client can now decrypt the Ticket Granting Server Session Key using its CLIENT SECRET KEY. Doing so, the client should have retrieve the TGS SESSION KEY.

The other message, namely TGT, can’t be decrypted since the client does not know the TGS SECRET KEY.

The Client & the Ticket Granting Server

At this point, the client already possess the TGS SESSION KEY and TGT message (can not be decrypted).

Step 1. The client sends out two messages along with the TGT to the Ticket Granting Server.

The first message is called the Authenticator and is encrypted with the TGS SESSION KEY. It consists of the followings:

• The Client ID
• Current timestamp

Meanwhile, the other message is unencrypted and consists of the followings:

• The ID of the requested service
• Validity period of the ticket for the requested service

Step 2. The Ticket Granting Server will then check whether the requested service exists in the KDC database.

If it exists, then the TGT is decrypted using the TGS SECRET KEY. The TGS SESSION KEY stored within the TGT is used to decrypt the Authenticator.

Step 3. The TGS does the followings upon decrypting the TGT and the Authenticator.

• Compare the Client ID in the Authenticator to the one in the TGT
• Compare the timestamp in the Authenticator to the one in the TGT (the tolerance of difference can be configured)
• Check whether the TGT is already expired (based on the Validity period of the TGT)
• Check whether the Authenticator does not exist in the TGS's cache
• Compare the client’s IP address to the one in the TGT

Step 4. If the previous checks returns no error, the TGS sends back two messages to the client.

The first one is the service ticket which consists of the followings:

• the Client ID
• the ID of the requested service
• the Client’s IP address
• Current timestamp
• Validity period of the service ticket
• REQUESTED SERVICE SESSION KEY

The above service ticket is encrypted with the REQUESTED SERVICE SECRET KEY.

Meanwhile, the other one (call it SERVICE SESSION KEY) consists of the followings:

• the ID of the requested service
• Current timestamp
• Validity period of the service ticket
• REQUESTED SERVICE SESSION KEY

The above message is encrypted with the TGS SESSION KEY.

Step 5. Upon receiving both messages, the client can decrypt the SERVICE SESSION KEY with its TGS SESSION KEY. Doing so, the client should have retrieved the REQUESTED SERVICE SESSION KEY.

The Client & the Requested Service

Step 1. Similar to the previous interaction, the client sends out two messages to the requested service.

The first one is the Authenticator that consists of:

• The Client ID
• Current timestamp

The above message is encrypted with the REQUESTED SERVICE SESSION KEY.

Meanwhile, the other one is the service ticket retrieved previously.

Step 2. Since the requested service has the REQUESTED SERVICE SECRET KEY, it can fetch the REQUESTED SERVICE SESSION KEY from the encrypted secret key.

Step 3. The fetched REQUESTED SERVICE SESSION KEY is then used to open the Authenticator.

Step 4. The requested service performs the followings:

• Compare the client ID in the Authenticator to the one in the service ticket
• Compare the timestamp in the Authenticator to the one in the service ticket (the tolerance of difference can be configured)
• Check whether the service ticket is already expired (based on the validity period)
• Check whether the Authenticator does not exist in the service's cache
• Compare the client’s IP address to the one in the service ticket

Step 5. If the previous checks returns no error, the requested service sends back a message to the client. The message consists of the followings:

• the Client ID
• Current timestamp

The above message is encrypted with the REQUESTED SERVICE SESSION KEY.

Step 6. The client receives the message and decrypts it with the REQUESTED SERVICE SESSION KEY.

Finally

The client has now been authenticated to use the service. Next time it requests access to the service, it can just use the cached encrypted service ticket (as long as the ticket is still valid).