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.
Windows Authentication 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 in fact a string on the form primary/instance@REALM and is thus divided into three parts. For a user this is <username>/<role>@<domain> with the possibility of omitting role while a service would be on the form host/<hostname>@<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 a shared secret with the Client and another secret shared with the Service. How the Secrets are generated or distributed is out of scope.

AS Exchange

  1. 1.
    The Client sends one message in plaintext to the AS with Client-ID, TGS-ID.
  2. 2.
    The AS checks if the user exists in the KDC DB. If the user exists, the exchange continues.
  3. 3.
    The AS creates a random-generated TGS-Sesson key.
  4. 4.
    The AS replies with two messages, the TGT encrypted with the TGS-Secret and another message (A) encrypted with the Client-Secret. The TGS-Session is included in both.
  5. 5.
    The Client receives the encrypted TGT and encrypted message (A) and decrypts (A) with its Client-Secret to get the TGS-Session. The encrypted TGT is stored in the Client's keytab.

TGS Exchange

  1. 1.
    The Client send three messages to the TGS, one message called authenticator which is encypted with the TGS-Session, a plaintext message with Service-ID and the encrypted TGT.
  2. 2.
    The TGS checks if the Service exists in the KDC DB. If the service exists, the exchange continues.
  3. 3.
    The TGS decrypts the encrypted TGT and gets the TGS-Session and uses it to decrypt the encrypted autenticator message
  4. 4.
    The TGS performs a series of checks. If all checks passes, the exchange continues.
    1. 1.
      The TGS checks if the TGT has expired using the timestamp
    2. 2.
      The 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. 3.
      The TGS checks if the authenticator with the corresponding timestamp already exists in the KDC-cache which would indicate a replay-attack
  5. 5.
    The TGS generates a random-generated Service-Sesson key.
  6. 6.
    The TGS replies with two messages, one message (B) that is encrypted with the TGS-Session and the Service Ticket which is encrypted with Service-Secret. The Service-Session key is included in both.
  7. 7.
    The Client receives the encrypted message (B) and the encrypted Service Ticket and decrypts (B) with the TGS-Session to get the Service-Session. The encrypted Service Ticket is stored in the Client's keytab.

Service Exchange

  1. 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. 2.
    The Service decrypts the Service Ticket with its Service-Secret and gets Service-Session which it uses to decrypt the authenticator.
  3. 3.
    The Service performs a series of checks in a similar manner as the TGS:
    1. 1.
      The Service checks if the Service Ticket has expired using the timestamp
    2. 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. 3.
      The Service checks if the authenticator with the corresponding timestamp already exists in the Service-cache which would indicate a replay-attack
  4. 4.
    The Service stores the Service-Session locally and associates it with the Client.
  5. 5.
    The Service replies with one message called authenticator which is encrypted with Servce-Session
  6. 6.
    The Client receives the autenticator and decrypts it with the Service-Session in order to verify the identity of the Service.
  7. 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

[MS-KILE].pdf
3MB
PDF
Microsoft Kerberos Network Authentication Service V5 Extensions