Kerberos Authentication Explained

What is Kerberos

In Greek mythology, Kerberos is a creature that is a three-headed dog that guards the gate toward the underworld. In a nutshell, it’s a security guardian.
Back to our network world, Kerberos is a computer network authorization protocol that allows clients and servers to communicate in a secure manner (symmetric key cryptography). It is designed by MIT.

Terminology

Kerberos is a protocol which uses within the client-server model. Before we explore the authorization process, we ought to know some terms in Kerberos.

• KDC (Key Distribution Center)
  Which issues the TGT to the client and contains TGS and AS.

• AS (Authorization Server)
  Which forwards the username to a KDC.

• TGS (Ticket-granting Service/Server)
  A service that can generate TGT.

• TGT (Ticket-granting Ticket)
  A data segment that is time-stamped and encrypted by using the TGS secret key and returns to the client.

• principal
  A service node which guards by Kerberos.

• SS (Service Server)
  Also called a principal that provides specific services for clients.

• SPN (Service Principal Name)
  The literal meaning of this word.

• Realm
  Which encompasses all services that you can access.

Principal

When requiring access to a service or host, there are four components that you need to keep back in your mind.

• AS
• TGS
• SS
• Client

So, let’s begin to cross this mysterious jungle.

Process 1: Getting TGT

1. The client sends the plaintext to AS.
   The plaintext contains:

   • name/ID
   • timestamp

2. AS verifies timestamp, then lookups client by client’s username to ensure that the client is a legal principle.
   If the time gap between the client and AS is upper than 5min, the client will be refused by AS.

3. AS generates a TGT and a TGS session key which used for communicating with TGS.

4. AS sends two messages (TGT and TGS session key) back to the client.
   The client secret key is created by the client within the registration process (Using command “addprinc”).

   TGT which encrypted by TGS secret key (client cannot decrypt TGT) contains:

   • your name/ID
   • the TGS name/ID
   • timestamp
   • your network address
   • lifetime of TGT
   • TGT session key

   Info package which encrypted by client secret key which KDC owning it contains:

   • TGS name/ID
   • timestamp
   • lifetime
   • TGS session key

5. The client fetches TGT and TGS session key which can be obtained by decrypting info package.

Process 2: Requesting access to a specific service(principal)

In this step, you just communicate with TGS.
6. The client sends the plaintext request, the authenticator and TGT to TGS.

The plaintext contains:  
- service name/ID  
- lifetime of the ticket for the service  

The authenticator which encrypted by TGS session key contains:  
- your name/ID  
- timestamp  

7. TGS verifies if the service exists.

8. TGS decrypts TGT and the authenticator, then comparing properties.
   TGS can use the TGS secret key to decrypt TGT. So TGS can obtain the TGT session key which can decrypt the authenticator. After that TGS needs to compare the information which is TGT provided by AS to the information which is the authenticator created by the client.

9. TGS sends the service session key and the service ticket.
   The service ticket which encrypted by service secret key contains:

   • your name/ID
   • service name/ID
   • your network address
   • timestamp
   • lifetime of this service ticket
   • service session key

   Info package which encrypted by TGS session key contains:

   • service name/ID
   • timestamp
   • lifetime of the service ticket
   • the service session key

10. The client fetches the service ticket and the service session key which can be obtained by decrypting the info package.

Process 3: Communicating with the service

From now, you just communicate with the service.
11. The client sends the authenticator and the service ticket to the service server.
The authenticator encrypted by the service session key contains:
- your name/ID
- timestamp

12. The service decrypts the service ticket and the authenticator, then compares properties.
    The service server can use the service secret key to decrypt the service ticket. So the service server can obtain the service session key which can decrypt the authenticator. After that, the service server needs to compare the information which is the service ticket provided by TGS to the information which is the authenticator created by the client.

13. The service sends the authenticator to the client in order to confirm its identity.
    The authenticator encrypted by the service session key contains:

    • the service name/ID
    • timestamp

14. The client decrypts the authenticator and knows it has been authenticated to use the service by cached the service ticket.