At the heart of the Kerberos protocol

24/09/2023 (updated on 05/09/2024) · 12 min read · cybersecurity cryptography authentication krb kerberos ticket  ·
Share on:

Translations

Overview

In this article, I take you to the heart of a network protocol that has been widely used for years and yet is not very well understood: Kerberos. Indeed, during professional discussions, I often realize that although Kerberos is very much in the public eye, there is a great deal of misunderstanding about how it works. Furthermore, most of the articles I have come across are a little too vague and approximate to me, unlike the Request for Comments (RFC, documents describing technical specifications for the Internet, issued by the Internet Engineering Task Force or IETF), which is long and tedious to read, albeit very exhaustive. That’s why I wanted to clarify things with this article.

Introduction

On IT networks, there are many access requests to services for which it is essential to verify the identity of the users wishing to use them. Examples include access requests to directories such as Microsoft Active Directory (AD), Web browsing via proxies, access to database servers, and so on. To achieve this without disrupting the user experience, transparent solutions exist such as Kerberos, a protocol based on symmetric cryptography with shared secrets. For more information on what cryptography is, I invite you to consult this article. First, we’ll look at the foundations of Kerberos, then at its components and how they interact with each other to deliver an authentication service. Then I will introduce the concept of delegation in Kerberos and present the most famous cyber attacks on this protocol.

Kerberos origins and objectives

The term Kerberos comes from ancient Greek and Greek mythology. It refers to a three-headed dog guarding the entrance to the underworld, preventing the dead from escaping. The analogy stems from the fact that Kerberos is based on a model with three main components. We’ll come back to this later.

Kerberos, guardian of hell

The Kerberos network protocol was developed by the Massachusetts Institute of Technology (MIT) in 1988 as part of a distributed computing project. It is based on the Needham-Schroeder protocol, which enables third parties to prove their respective identities using symmetrical encryption. The first public version of the Kerberos protocol was version 4, released in 1989. In 1993, version 5 was released, with improvements mainly on security aspects.

The objectives of the protocol are to provide means to verify identities on a network considered insecure or untrusted. To achieve this, Kerberos enables the authentication, either unidirectional or bidirectional (mutual), of a user or server in a transparent manner. Kerberos can thus be categorized as a Single Sign-On (SSO) system, which consists in performing a single authentication from the user’s standpoint, while propagating this authentication information across several services. In the case of Kerberos, tickets are distributed and reused.
Now it’s time to go into more details about Kerberos.

Kerberos components and operation

Kerberos is a three-headed dog. Actually it has even more heads. Indeed, there are several components involved in this protocol:

  • The principal, which is a single entity (e.g. a user) that participates in a network communication and consumes services against which it must authenticate.
  • The client, which enables the use of network services on behalf of the principal.
  • The Authentication Server (AS), which maintains a database of principals and their secret keys, derived from the password. Its role is to exchange identifiers for tickets to be used later in order to obtain other service tickets.
  • The Ticket-Granting Server (TGS), which is a server in charge of issuing tickets for the consumption of given application services.
  • The Key Distribution Center (KDC), which combines the AS and the TGS, usually on the same server.
  • The application server, which hosts a service to be consumed by the principal via the client, and controls access to this service.

We will now look at how these components work together to enable identity verification for the purpose of consuming an application service available on the network.

Kerberos operates on several principles:

  • Ticket exchange:
    • a ticket, called the Ticket-Granting Ticket (TGT) to request service tickets;
    • a Service Ticket to request access to the service in question.
  • The use and sometimes sharing of encryption keys:
    • a session key, which I note down as $S_{s}$, transmitted by the TGS to the client.
    • a session key, which I note $S_{c}$, transmitted by the AS to the client and used to encrypt or decrypt $S_{s}$.
    • a secret key, $K_{c}$, derived from the principal’s password, shared between the client and the AS and used to pre-authenticate and encrypt or decrypt $S_{c}$.
    • a secret key, which I note $K_{k}$, known only to the AS and used to encrypt or decrypt the TGT. In Windows environments, a predefined service account called krbtgt exists by default, as its password is used on the KDC to derive the $K_{k}$ encryption key.
    • a secret key, which I’ll note down as $K_{a}$, shared between the TGS and the application server, used in particular to encrypt or decrypt the Service Ticket. On the application server, this key is generally stored in a keytab (short for key table).

There is nothing like a diagram to help you understand how the protocol works, which can be summed up in three main stages:

  1. The principal connects to the client, which then requests a TGT from the AS. The AS checks the identity and sends back an encrypted TGT.
  2. Using the TGT, the client requests a Service Ticket for the given service from the TGS. The TGS checks the TGT and returns a Service Ticket.
  3. The client uses its Service Ticket to request access to the given service from the application server.

Simplified Kerberos operation

Now, for the more passionate among you readers, here’s what happens in detail.

Detailed Keberos operation

0. The principal connects to the client.

1. The client sends an $AS$_$REQ$ message to request a TGT from the AS for the given principal. This message contains a timestamp encrypted with the key $S_{c}$. The AS checks its database for the presence of the principal, then decrypts and verifies the timestamp to perform what is known as pre-authentication. Then, using the key $K_{c}$, it encrypts the session key $S_{c}$ and also encrypts a TGT using its key $K_{k}$.

$AS$_$REQ$ message

2. The AS sends an $AS$_$REP$ message containing the encrypted session key and TGT, which are then sent to the client. The client decrypts the session key with the $S_{c}$ key, which it uses to generate an Authenticator $A_{c}$, which certifies the client’s knowledge of $S_{c}$.

$AS$_$REP$ message

3. The client sends a $TGS$_$REQ$ message with its encrypted TGT and $A_{c}$, specifying the Service Principal Name (SPN) (service identifier) to request a Service Ticket for the given service from the TGS. The TGS checks the TGT, $A_{c}$ and prepares a Service Ticket which it encrypts with the key $K_{a}$, as well as a new session key $S_{s}$ which it encrypts with $S_{c}$. Note that the Service Ticket contains a Privileged Attribute Certificate (PAC) which contains the username, the Security IDentifier (SID, unique identifier on Windows) and the user groups. This enables the application server to verify specific user rights without making a request to the KDC.

$TGS$_$REQ$ message

4. The TGS sends a $TGS$_$REP$ message to the client in order to transmit the encrypted Service Ticket and the encrypted $S_{s}$ key. The client decrypts $S_{s}$ with $S_{c}$ and prepares an Authenticator $A_{a}$ which it encrypts with $S_{s}$.

$TGS$_$REP$ message

5. The client sends an $AP$_$REQ$ message to the application server in order to send the encrypted Service Ticket and $A_{a}$ to it. The application server decrypts and verifies $A_{a}$ and the Service Ticket using $K_{a}$.

$AP$_$REQ$ message

6. If everything is valid, the application server issues a $AP$_$REP$ message to confirm the client it may access the service.

The encryption algorithm used by Kerberos nowadays is Advanced Encryption Standard (AES), which has replaced Data Encryption Standard (DES) and Rivest Cipher 4 (RC4), initially deployed but less secure due to their susceptibility to brute force attacks. The CipherText Stealing (CTS) mode is used for AES to avoid the use of padding in block ciphers, and to give an encrypted message size equal to the clear message size. To ensure the integrity of messages encrypted with AES, the keyed-Hash Message Authentication Code (HMAC) SHA1-96 cryptographic hash function is generally used. This generates a 160-bit fingerprint, truncated to 96 bits. The HMAC keyed hash functions SHA-256 and SHA-384 (which generate longer, more secure fingerprints) have also been standardized, but are less widely used.
In addition, it should be noted that Kerberos allows extensions where asymmetric cryptography is employed, i.e. public and private key pairs are used instead of shared symmetric keys.
I bring you back to this article to review all these cryptographic notions.

Kerberos uses the User Datagram Protocol (UDP) transport protocol on port 88 (by default), but can also be established over the Transmission Control Protocol (TCP) on port 88 (by default), particularly when large tickets need to be transferred. It should also be noted that Kerberos communications are sometimes encapsulated into other protocols. This is the case, for example, in a Web communication between a client and a proxy that requires Kerberos authentication over the HyperText Transfer Protocol (HTTP).

Kerberos delegation

Microsoft has developed an approach for delegating access with authentication to application servers without involving the client. The most common use case concerns distributed applications where a client will first authenticate to an application service (e.g. a Web server) which needs to access another application service (e.g. a database) on behalf of the client.
In this context, the first delegation model proposed in Windows 2000 was the unconstrained delegation, where the client’s TGT is inserted into the Service Ticket so that the application server can decrypt it (because it has the key to do so) and thus reuse it on behalf of the client to obtain a Service Ticket in order to access the other application server. This model has a number of shortcomings: no delegation granularity, risk of TGT compromission leading to malicious generation of Service Tickets…

With Windows 2003, constrained delegation came up, where the services for which an application server can authenticate the user on its behalf are specified. The application server can then request Service Tickets from the KDC for the client. Additional Service Tickets associated with the identified services can then be requested via a Service Ticket (used in a $TGS$_$REQ$ request) which can be retransmitted using the S4U2Proxy extension. In some cases, where the client does not perform Kerberos and therefore has no TGT, a service may want to request a Service Ticket on behalf of the client to authorize the client to access the same service. This is made possible by the S4U2Self extension. Although this is an improvement in the authentication delegation approach, constrained delegation still exposes serious risks of lateral movements if the service with the rights to do constrained delegation is compromised.
In Windows 2012, Microsoft has introduced resource-based constrained delegation, enabling services to configure which accounts are authorized to delegate to them. However, this requires extra vigilance in the configuration.

Attacks on Kerberos

Several attacks have been described on the Kerberos protocol. In particular, we can cite:

  • Kerberoasting: this attack requires either a valid TGT or the ability to eavesdrop Kerberos-type network traffic. With the TGT, the attacker can then request TGSs, or if he has the ability to sniff the traffic, he can extract Service Tickets. The Service Tickets are partly encrypted with a hash of the password of the service account associated with the SPN: the secret key $K_{a}$. If a weak encryption algorithm such as RC4 is used and the password is not complex, a brute force attack could quite easily decrypt the Service Ticket and retrieve the service account password.
  • The ASReqroast: in this attack, an attacker listens to network traffic for $AS$_$REQ$ packets that use the RC4 algorithm in order to brute force the included timestamp in ordeer to find the $K_{c}$ encryption key and thus recover the password of the associated account.
  • The ASReproast: in this attack, if Kerberos pre-authentication is not configured, an attacker can send $AS$_$REQ$ messages which will be processed without verification. The attacker then listens to network traffic for $AS$_$REP$ reply packets and, using the RC4 algorithm for encryption, can brute force the message to retrieve the $K_{c}$ encryption key and the associated account password.
  • The Silver Ticket: using the service account key $K_{a}$, an attacker can forge a Service Ticket called Silver Ticket, giving access to a given application. The Silver Ticket attack therefore requires the compromission of a service account.
  • The Golden Ticket: using the KDC’s $K_{k}$ key, an attacker can forge TGTs giving access to any service. The Golden Ticket attack requires the compromission of the KDC’s service account.
  • The Skeleton Key: having compromised the KDC’s local administration, an attacker can install a backdoor by modifying the Kerberos configuration with RC4 (a weak algorithm without salting, i.e. without adding random data during the hashing operation) and adding a so-called Skeleton Key valid for all domain accounts. This allows an attacker to authenticate himself for any account when sending $AS$_$REQ$ messages, since the latter contain the encrypted timestamp determined from the Skeleton Key.
    The famous Golden Ticket!

Prevention of the attacks listed above aminly relies on the use of complex passwords, strong encryption algorithms and the regular renewal of passwords and encryption keys.

Conclusion

Together, we have dived into the heart of the Kerberos authentication protocol, widely used to verify identities wishing to consume services on an IT network. Based on symmetric encryption and ticket exchange, despite some of the attacks described, it remains sufficiently robust, if correctly used, to be preferred to other protocols such as New Technology LAN Manager (NTLM), because it does not directly transfer passwords or password hashes. Finally, remember that there are other SSO protocols (such as Security Assertion Markup Language or OpenID Connect) that are more suitable than Kerberos for usage over the Internet, without requiring a KDC deployed in a local network.

Sources

Translations