Today we start with a new series of blog posts, namely, active directory components. In this three part series on Kerberos, we’ll be talking about it’s three heads:

• Part 1: What Kerberos is and how it works?
• Part 2: The notorious techniques of kerberoasting and ticketing attacks (golden and silver tickets)
• Part 3: Attempting to mitigate, and detect these issues.

Kerberos Authentication – The Basics

Kerberos comes into play when you as a user is reluctant to send credentials over the wire, Kerberos attempts to pave a path of secure authentication doing the following things:

• It never sends plain text credentials across the network.
• No encryption keys are directly exchanged.
• It enables a mutual authentication flow.
• Single Sign On (SSO) applicability.

Hell – The Realm of Kerberos

Sounds funny, I know, however the name “Kerberos” is the transliteration of the Greek word “Cerberus” who is also popularly known as the hound of hades, the guard dog to the gateways of hell. Cerberus prevented the passage of dead to the realms of the living.

Coming back to The Realm of Kerberos, before discussing this further let’s have a look at the elements.

• Principal: Uniquely identified objects in a realm, like users, service, application, etc.
• Client: A process that accesses a service on behalf of the user.
• Service: A resource within the realm that a client may access upon successful mutual authentication.
• Key Distribution Center: KDC for short, is the essence of Kerberos.
  • It supplies tickets and generates temporary session keys to allow secure access for a user.
  • Key storage.
  • Houses the Authentication and Ticket Granting servers
• Authentication Server: Acts as a validator of the user identifier, to verify a VALID/KNOWN user is requesting access, and issues a ticket granting ticket (TGT)
• Ticket Granting Server: TGS for short, acts as a validator of the service identifier, to verify a VALID/KNOWN service is being requested for access, and issues a service ticket

Lets look at all of these in greater detail with the help of the messages section of the Kerberos realm.

Messages

The process of Kerberos happens with a lot of messages passed between client and servers.

There are two types of messages; authenticators and tickets.

Authenticators are essentially record of information that are shown to have been generated using the clients session key which is only known to the client and the service. In simple terms, authenticators allows for a client to authenticate to a service and a service to authenticate to the client i.e. mutual authentication.

Tickets store all the other information related to the authentication such as: clients id, session keys, time stamps, service id, time to live, etc.

Now that we’ve covered the components and their basic details, let us now look at the Kerberos authentication in greater depth.

Kerberos Authentication

Lets break it down further into three flows, namely:

1. The Authentication Flow
2. The TGS Flow
3. The Service Flow

The Authentication Flow

User to Authentication Server

In this step a message is initiated by the user/client towards the authentication server which includes the following:

Message 1 – User Message – Clear Text

• Username and ID of the requesting user / client.
• Service Name / ID for which a request was initiated
• IP Address (Optional, can be single, multiple or null)
• Requesting lifetime for the TGT (Depends on how the Kerberos is setup, requested values are ignored if it does not adhere to supported values)

Authentication Server to User

In this step, the authentication server checks if the user details in the message matches any entry available in the KDC. If the user is found, the users secret key is fetched and returns 2 messages to the user as follows:

Message 1 – Client Message – encrypted with Client Secret Key

• TGS Name/ID.
• Timestamp of message creation.
• Lifetime of TGT.
• TGS Session Key.

Message 2 – TGT – encrypted with TGS Secret Key

• Username/ID.
• TGS Name/ID.
• Timestamp of message creation.
• User IP Details.
• Lifetime of TGT.
• TGS Session Key.

These encrypted messages are then sent to the user.

Next, the user decrypts the first message, by using his domain credentials, however this looks a little different under the hood; The password is used to generate the client secret key which unlocks the details for the user. The client secret key is generated as follows:

With successful authentication, the user now has access to the TGS Server with a valid TGS Session Key.

Note: The second message (TGT) cannot be decrypted as the client does not have the TGS Secret Key

This ends the requests with the Authentication server, let’s move on to the TGS Flow.

The TGS Flow

User to TGS Server

Now, with the previous Message 2 (TGT) the user creates another two messages, so 3 in total, which are sent to the Ticket Granting Server, these two messages are as follows:

Message 1 – User Message – Clear Text

• Service Name (Requested Service).
• Requested Lifetime.

Message 2 – User Authenticator – encrypted with TGS Session Key

• Username.
• Timestamp of message creation.

TGS Server to User

Now, the TGS performs a bunch of tasks to follow, before creating and sending messages, they are:

1. Check if the service requested is available in the KDC.
2. Fetch a copy of the service secret key for the valid service.
3. Decrypt the TGT with the it’s (TGS’s) own secret key.
4. Use the available TGS session key in the decrypted message to decrypt the user authenticator.
5. Validate the data contained in the Authenticator message with the TGT details.

If everything is good to go, the TGS performs one final task, which is to check the TGS cache for previously received authenticators from the same user (to provide replay protection); if no such entry is available the TGS now adds it to the cache and now moves onto the creation of its own messages.

Message 1 – Server Message – encrypted with TGS Session Key

• Service Name (Requested Service).
• Requested Lifetime.

Message 2 – Service Ticket – encrypted with Service Secret Key

Note: the Service secret key is randomly generated in the KDC

• Username.
• Timestamp of message creation.

These messages are now sent over to the user. Which takes us to the Service Flow

The TGS Flow

User to Service

With the newly received messages from the TGS, the user performs a specific set of tasks;

1. Decrypt the Server Message using the TGS Session Key received during the Authentication Flow.
2. Read the details of the message and retrieve the Service Session Key.
3. Create a new user authenticator encrypted with the Service Session Key.

The user now forwards the service ticket along with the new user authenticator;

Note: The second message (ST) cannot be decrypted as the client does not have the Service Secret Key

Message 1 – User Authenticator – encrypted with Service Session Key

• Username.
• Timestamp of creation.

Service to User

The Service now performs the following tasks;

1. Decrypt the service ticket using it’s (Service) own secret key.
2. Use the Service Session Key from the Decrypted message to decrypt the User Authenticator message.
3. Validate the data contained in the Authenticator message with the ST details.

If everything is good to go, the service performs one final task, which is to check the service cache for previously received authenticators from the same user. If no such entry is available the service now adds it to the cache and now moves onto the creation of its own messages.

Message 1 – Service Authenticator – encrypted with the Service Session Key

• Service Name / Details.
• Timestamp of creation.

The service sends this message back to the user; who already in possession of the service session key decrypts this message and gains access to the service; completing the mutual authentication flow.

Like the TGS and the Service, the user also has it’s own cache. It adds the encrypted service ticket for future use, until the lifetime of the ticket survives. Upon expiry the entire process goes again.

This completes the entire walkthrough of the Kerberos Authentication protocol and what goes around in the background. I have also created a diagrammatic representation of the entire flow we’ve just discussed just incase the visualization assists in understand the message flow in depth.