Kerberos Authentication Protocol

This entire page is based on RFC 4120 and RFC 4556, documentation from MIT Kerberos as well as this great guide to Kerberos by Lynn Root.

The Domain Controller (DC) is responsible for security authentication requests within a network domain and controlling access to domain resources. It authenticates users, stores user account information and enforces security policy for a domain. The DC host can achieve this using Microsoft's Active Directory (AD) or an identity management software such as and FreeIPA. Both are more than capable to act as the centerpiece in a kerberized network environment.

There are two main implementations of the Kerberos authentication protocol, AD and MIT Kerberos.

Integrated Windows Authentication (link) supports two authentication protocols, Kerberos and NTLM where Kerberos is vastly superior in terms of security. While Kerberos usually preferred, NTLM can still be used as a fallback. Some services, in particular legacy systems, may support Windows Authentication but only with NTLM.

The Concepts

Kerberos provides a means of verifying the identities of principals, which is a workstation user or a network server, on an untrusted network by relying on a trusted third party, the Key Distribution Center (KDC). The KDC itself consists of two main components, the Authentication Server (AS) and the Ticket-Granting Server (TGS). The set of AD domains (and thus services) in which the KDC has the authority to authenticate a user make up the Kerberos Realm.

The Kerberos authentication uses a shared secret symmetric-based encryption key which is known only to two entities, the KDC and the client. How the secret is made known or stored to the client or the KDC in not part of the protocol. In the simplest case an admin enters it manually.

The protocol in its entirety is designed such that the KDC and the Service never communicates directly. This is achieved trough a ticket-based authentication with two types of tickets.

  • Ticket Granting Ticket (TGT) is issued by the AS and is used to authenticate the user towards the TGS.

  • Service Ticket is issued by the TGS and used to authenticate the user towards services.

In order to receive these tickets, different sub-protocols or exchanges are used. In order the access the service, there are therefore three entities the user needs to interact with, the AS, TGS and the service itself. When interacting with the AS and TGS, the client receives two encrypted messages, of which only one can be decrypted using the shared secret.

Finally, Kerberos is time-sensitive since the tickets include timestamps. This means that all hosts in the Kerberos Realm needs to be time-synchronized through, for example, an NTP service.

The principal is an entity (user, computer, etc) which can be assigned Kerberos tickets. It is denoted using different formats.

  • Down-Level Logon Name: DOMAIN\UserName

  • User Principal Name (UPN): username@domain

The secret is determined byhash(username+password)where the username acts as a salt. Services use generated keys as passwords which are stored on the host instead of a password which would require a user-interaction to enter it.

The Protocol

Kerberos consists of several sub-protocols/exchanges which are defined below.

Pre-requisite:

The KDC must have three shared secrets setup before the exchange starts:

  • A secret shared between KDC and the Client (Client-Secret)

  • A secret shared between KDC and the Service (Service-Secret)

  • A secret shared internally between KDC/AS and KDC/TGS (TGS-Secret).

The secrets are used for symmetric encryption. How the secrets are generated or distributed is out of scope.

Note: In Active Directory (AD), TGS-Secret is actually the KRBTGT account's password hash. As you see below in the KDC/AS Exchange, it is used to encrypt the TGT. This is important in Golden Ticket Attacks.

KDC/AS Exchange

Purpose: Clients gets a TGS-Session (before the TGS) and an encrypted TGT Client and can now start the authentication against the KDC/TGS.

  1. The Client sends one message in plaintext to the KDC/AS with Client-ID, TGS-ID.

  2. The KDC/AS checks if the user exists in the KDC DB. If the user exists, the exchange continues.

  3. The KDC/AS creates a random-generated TGS-Sesson key.

  4. The KDC/AS replies with two messages. The TGS-Session is included in both.

    1. Message (A) which is encrypted with the Client-Secret.

    2. Message (B) which is the TGT, encrypted with the TGS-Secret .

  5. The Client decrypts (A) with its Client-Secret to get the TGS-Session. The encrypted TGT (B) is stored in the Client's keytab.

KDC/TGS Exchange

Purpose: Client gets a Service-Session (before the Service) and an encrypted Service Ticket and can now start the authentication against the Service.

  1. The Client send three messages to the KDC/TGS, one message called authenticator which is encypted with the TGS-Session, a plaintext message with Service-ID and the encrypted TGT.

  2. The KDC/TGS checks if the Service exists in the KDC DB. If the service exists, the exchange continues.

  3. The KDC/TGS decrypts the encrypted TGT and gets the TGS-Session and uses it to decrypt the encrypted autenticator message

  4. The KDC/TGS performs a series of checks. If all checks passes, the exchange continues.

    1. The KDC/TGS checks if the TGT has expired using the timestamp

    2. The KDC/TGS compares the Client-ID and the timestamp in the TGT and authenticator message, the first should be identical and the second should be within the configured time-tolerence (~2 mins)

    3. The KDC/TGS checks if the authenticator with the corresponding timestamp already exists in the KDC-cache which would indicate a replay-attack

  5. The KDC/TGS generates a random-generated Service-Sesson key.

  6. The KDC/TGS replies with two messages. The Service-Session key is included in both.

    1. Message (C) which is encrypted with the TGS-Session

    2. Message (D): The Service Ticket, encrypted with Service-Secret.

  7. The Client decrypts (C) with the TGS-Session (from the KDC/AS exchange) and gets the Service-Session. The encrypted Service Ticket is stored in the Client's keytab.

Service Exchange

Purpose: The Client and the Service are authenticated (2-way) through Service-Session.

  1. The Client sends two messages to the Service, one message called authenticator which is encrypted with the Service-Session and the encrypted Service Ticket.

  2. The Service decrypts the Service Ticket with its Service-Secret and gets Service-Session which it uses to decrypt the authenticator.

  3. The Service performs a series of checks in a similar manner as the KDC/TGS:

    1. The Service checks if the Service Ticket has expired using the timestamp

    2. The Service compares the Client-ID and the timestamp in the Service Ticket and authenticator message, the first should be identical and the second should be within the configured time-tolerence (~2 mins)

    3. The Service checks if the authenticator with the corresponding timestamp already exists in the Service-cache which would indicate a replay-attack

  4. The Service stores the Service-Session locally and associates it with the Client.

  5. The Service replies with one message called authenticator which is encrypted with Servce-Session

  6. The Client receives the autenticator and decrypts it with the Service-Session in order to verify the identity of the Service.

  7. The Client and the Service are now authenticated against each other and shares the Service-Session key which will be used together with the Service Ticket in future requests.

Extra Resources

PreviousAttacking AD environmentsNextNTML Authentication

Last updated