About this Blog

This Blog is meant to explain how the kerberos protocol works, there were no document which explains everything in one place. I was writing this documents based on the gathered informations.

Kerberos


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

Kerberos builds on symmetric key cryptography and requires a trusted third party.

Kerberos is the one of the oldest authentication mechanism which comes in to market even before the Oauth, SAML etc and it provides a SSO functionality across the netwrok.

Kerberos uses UDP port 88 by default.

Architecture


  1. Client ( C ): An entity which wants to make use of any service hosted on a server.
  2. Server (V): An entity which hosts different services which clients request for.
  3. Authentication Server (AS): A trusted Third Party which knows the passwords of all users and stores these in a centralized database. Also, the AS shares a unique secret key with each server. It shares a key Kcs with C, a key Kvs with V and generates new session keys Kcv.
  4. Ticket Granting Server (TGS): TGS, issues tickets to clients who have been authenticated to AS. Thus, the client first requests a ticket-granting ticket (Tickettgs) from the AS. The client module saves this ticket. Each time the user requires access to a new service, the client applies to the TGS, using the ticket to authenticate itself. The TGS then grants a ticket for the particular service. The client saves each service-granting ticket and uses it to authenticate its user to a server each time a particular service is requested.

KerberosArchitecture

 

Client Authentication

  • The client sends a cleartext message of the user ID to the AS (Authentication Server) requesting services on behalf of the user. (Note: Neither the secret key nor the password is sent to the AS.)
  • The AS checks to see if the client is in its database. If it is, the AS generates the secret key by hashing the password of the user found at the database (e.g., Active Directory in Windows Server) and sends back the following two messages to the client:

Message A: Client/TGS Session Key encrypted using the secret key of the client/user.

Message B: Ticket-Granting-Ticket (TGT, which includes the client ID, client network address, ticket validity period, and the client/TGS session key) encrypted using the secret key of the TGS.

  • Once the client receives messages A and B, it attempts to decrypt message A with the secret key generated from the password entered by the user. If the user entered password does not match the password in the AS database, the client’s secret key will be different and thus unable to decrypt message A.
  • With a valid password and secret key the client decrypts message A to obtain the Client/TGS Session Key. This session key is used for further communications with the TGS. (Note: The client cannot decrypt Message B, as it is encrypted using TGS’s secret key.) At this point, the client has enough information to authenticate itself to the TGS.

Client Service Authorization

  • When requesting services, the client sends the following messages to the TGS:

Message C: Composed of the TGT from message B and the ID of the requested service.

Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the Client/TGS Session Key.

  • Upon receiving messages C and D, the TGS retrieves message B out of message C. It decrypts message B using the TGS secret key. This gives it the “client/TGS session key”. Using this key, the TGS decrypts message D (Authenticator) and compare client ID from message C and D, if they match server sends the following two messages to the client:

Message E: Client-to-server ticket (which includes the client ID, client network address, validity period and Client/Server Session Key) encrypted using the service’s secret key.

Message F: Client/Server Session Key encrypted with the Client/TGS Session Key.

Client Service Request


  • Upon receiving messages E and F from TGS, the client has enough information to authenticate itself to the Service Server (SS). The client connects to the SS and sends the following two messages:

Message E: from the previous step (the client-to-server ticket, encrypted using service’s secret key).

Message G: a new Authenticator, which includes the client ID, timestamp and is encrypted using Client/Server Session Key.

  • The V decrypts the ticket (message E) using its own secret key to retrieve the Client/Server Session Key. Using the sessions key, SS decrypts the Authenticator and compares client ID from messages E and G, if they match server sends the following message to the client to confirm its true identity and willingness to serve the client:

Message H: the timestamp found in client’s Authenticator (plus 1 in version 4, but not necessary in version 5[6][7]), encrypted using the Client/Server Session Key.

  • The client decrypts the confirmation (message H) using the Client/Server Session Key and checks whether the timestamp is correct. If so, then the client can trust the server and can start issuing service requests to the server.
  • The server provides the requested services to the client.

Kerberos Message Exchange.


This will explain how and what are the messages are exchanging between the client and KDC to get the authentication ticket to server

KerberosMessageExchangeFlowDiagram
  1. C → AS :

    Below is the message that sends from client to AS

    C || TGSID || TS1

    In this message, the client requests a ticket-granting ticket by sending its identity and password to the AS, together with the identity of TGS, indicating a request to use the TGS service and a time stamp, so that the AS knows that the message is timely.

  2. AS → C :

    Below is the message that sends back from AS to C

    E(Kc, [Kc,tgs || TGSID|| TS2 || Lifetime2 || Tickettgs ])

    Tickettgs = E(Ktgs, [Kc,tgs || C || ADc || TGSID || TS2 || Lifetime2])

    The AS responds with a message, encrypted with a key derived from the user’s password that contains the ticket requested by client. This message also contains session key Kc,tgs to be shared between TGS and Client. The client retrieves this key. The ticket is encrypted with TGS’s key Ktgs which is already shared with AS. The ticket contains session key Kc,tgs which is retrieved by TGS. Like this, the session key has been securely delivered to both C and the TGS. The ticket also contains ADc (Network Address of client) which prevents the use of ticket from workstation other than one that initially requested the ticket.

  3. C → TGS :

    Below is the message that sends from client to TGS

    V || Tickettgs || Authenticatorc

    Authenticatorc = E(Kc,tgs[C||ADc||TS3])

    The client sends message to TGS stating the identification of the requested service V, Tickettgs, an authenticator which includes the identity of client C, address of Client ADc and a time stamp. The authenticator is intended for use only once and has a very short lifetime. The TGS can decrypt the ticket with the key that it shares with the AS. The TGS uses the session key Kc,tgs to decrypt the authenticator. The TGS can then check the identity and address from the authenticator with that of the ticket and with the network address of the incoming message. If all match, then the TGS is assured that the sender of the ticket is indeed the ticket’s real owner.

  4. TGS → C :

    Below is the message that sends back from TGS to Client

    E(Kc,tgs[Kc,v|| V ||TS4 ||Ticketv])

    Ticketv = E(Kv[Kc,v||C||ADc||V||TS4||Lifetime4])

    The TGS then sends C above message as a response to request. This message is encrypted by session key shared between TGS and client and includes a session key to be shared between Client and the server V, the identification of V, and the time stamp of the ticket. The ticket also includes session key to be shared between client and server V,and it is encrypted with V’s key KV .

  5. C → V :

    Below is the message that sends from client to Resource Server (v)

    Ticketv||Authenticatorc

    Authenticatorc = E(Kc,v[C||ADc||TS5])

    In this message the client sends the ticket received by TGS to server V. Client also sends an authenticator. The server can decrypt the ticket, recover the session key, and decrypt the authenticator.

  6. V → C :

    E(Kc,v[TS5+1])

    The server V sends the value of the time stamp from the authenticator, incremented by 1, encrypted in the session key Kc,v. C can decrypt this message to recover the incremented time stamp. Because the message was encrypted by the session key, C is assured that it could have been created only by V.

     

Conclusion


Thanks for reading this . I hope now you got some idea on how the kerberos handshaking process works internally.