How Kerberos Works

What is Kerberos?

Kerberos is an authentication protocol. In cybersecurity parlance, authentication refers to the process of verifying a user's identity. Think of a password prompt or a biometric identification device like a fingerprint reader; these are examples of things that enable authentication. The Kerberos protocol defines a cryptographically secure method for two computers on a network to authenticate one another without a pre-shared secret key. In short, this is achieved by means of an intermediary authentication server, though the details are obviously a lot more complicated. Since Kerberos authentication is mutual between all the machines involved, it is resilient against man-in-the-middle attacks. Because its authenticator messages include timestamps, it is resilient against replay attacks. That said, the protocol is not perfect, and many successful attacks have taken advantage of its complexities. This is why it's so important to understand how the Kerberos protocol works, and when it doesn't.

Symmetric Encryption

Kerberos relies on symmetric encryption: a secure class of cryptographic algorithm that uses an identical key for encryption and decryption of the same message. In contrast, asymmetric or public-key encryption uses a public key for encryption, and a separate, secret key for decryption.

Symmetric key encryption is significantly more performant than the asymmetric approaches. While symmetric algorithms use simple modular arithmetic, asymmetric algorithms require a bunch of extremely messy calculations related to exponentiation and factorization, leading to orders-of-magnitude slower performance. When Kerberos was first being developed at MIT in the 1980s, public-key cryptography was still an immature technology, and the faster symmetric algorithms were the obvious choice. Symmetric Key Encryption continues to serve the Kerberos protocol well to this day.

Though the type of encryption Kerberos uses in a given implementation or configuration is very relevant to the security of the system it's being used in, the specification does not prescribe the use of one particular set of cryptographic algorithms; it merely defines the steps the involved parties take when communicating. In the past, the now-depreciated DES or RC4 algorithms were used. In practice, modern Kerberos uses 256-bit AES encryption, which is generally considered the gold standard as of time-of-writing. For this explanation, the most standard configurations are assumed.

Tripartite Structure

A typical Kerberos authentication involves three parties.

1. The client, a user who is requesting access to resources on a service server.

2. The Key Distribution Server, or KDS. This is the intermediary server. It is composed of two services: the Authentication Server (AS) and the Ticket Granting Server (TGS).

3. The Service Server. This is the endpoint of contact, and provides services or resources to the client after authentication is achieved.

The security of the Kerberos protocol depends on carefully managing which secrets are known to which parties at what time. Because the process is quite complicated, a single authentication involves the exchange of five different cryptographic keys.

Secret Keys

The secret to Kerberos' effectiveness lies in its key-exchange process. No key is ever transmitted over the network in plaintext, and five of them are involved over the course of a single authentication. Understanding these keys, and which parties are in possession of which ones, is crucial to grasping Kerberos as a whole. Throughout this article, I will denote the five keys using Greek letters:

α - The client's secret key, pre-shared with the Authentication Server at configuration. It consists of a hash of the client's password.

β - The session key, generated by the Authentication Server, shared with the client, used to generate a proof-of-authentication called a Ticket-Granting ticket.

γ - The secret key shared between the Authentication Server and Ticket-Granting Server. The client never knows this.

δ- A secret key pre-shared between the Ticket-Granting Server and the Service Server. The client never knows this.

ε - The client-to-server session key. Generated by the Ticket-Granting Server as part of the client-to-server ticket, shared with the client, and shared by the client with the Service Server.

Notice how any two parties share a secret key, except for the client and the Service Server.

Tickets

A ticket is essentially an encrypted collection of information about the client (including its MAC address and a timestamp of the request), generated and granted by one service, and used by the client to prove its authenticity to another service. Though the client can never read the contents of a ticket, it can be used to prove authenticity to a server that shares knowledge with whoever generated the ticket. In a typical Kerberos authentication, two tickets are used:

1. The Ticket-Granting Ticket (TGT). The TGT is granted by the Authentication Server, and conveys the trust gained by the AS after authenticating the client via their shared α key. It is encrypted using the γ key and used by the client to prove authenticity to the Ticket-Granting Server, which can then in turn grant a Client-To-Server Ticket that the client can use to make requests to the Service Server.

2. The Client-To-Server Ticket. The CTST is granted by the Ticket-Granting Server, and encrypted using the δ key. The client uses it to request services from Service Server.

The Authentication Process

Because this is all quite arcane, it helps to observe how it works step by step.

1. When the user logs in to the Authentication Server (AS), their password is hashed using the α key and sent to the AS for authentication. This key was shared with the AS when the client was being configured to the network. Pre-sharing can be done in secure or insecure ways, but that process is outside the scope of the Kerberos protocol. In a way, the security of Kerberos depends on the security of the pre-sharing, and if an attacker knows the client's password, Kerberos authentication isn't much help. Technically, even this first step is outside the scope of Kerberos communication – it's just normal password authentication between trusting parties.

2. Once the client is logged in, it sends an unencrypted message to the AS with its client ID (the host's username, basically) along with the endpoint service it is trying to gain access to. This kicks off the Kerberos communication proper.

3. With this information at hand, the AS sends back the session key (β) encrypted with the shared α key. The client can now decrypt the session key and use it to communicate with the Ticket-Granting Server (TGS). The AS also shares the all-important Ticket-Granting Ticket, containing identifying information about the client, plus a copy of the β key, all encrypted using the γ key. The client cannot “open up” this ticket to read it, but the TGS can!

Now, the client is done with the AS and moves on to the Ticket-Granting Server. Note that because the AS and TGS are both just parts of KDS, they aren't really separate. They both have access to all the same information and computational resources. They have different functions, but can't “keep secrets” from one another.

4. To the TGS, the client sends the Ticket-Granting Ticket to prove it authenticated with the AS, along with the name of the service it is requesting a service ticket for. It also sends a copy of its name, plus a timestamp, encrypted with the session (β) key. This is called an authenticator message, and it protects against replay attacks, wherein an attacker intercepts a ticket and re-sends it at a later time. Kerberos likes timely messages, and won't authenticate if the timing is off.

5. The TGS decrypts the TGT using the γ key, thereby learning the β key, which it uses to decrypt the authenticator message. Then it cross-references the client information in the ticket with the information in the authenticator message.

6. If everything matches, the TGS generates a new key: the Client-To-Server Session Key (ε). This is very much like the β key, except it's used for communication between the client and the Service Server instead of the client and the KDS. The TGS includes a copy of this key in a new ticket (The Client-To-Server Ticket) that the client can use to request services from the Service Server. This ticket is encrypted using the δ key, pre-shared between the TGS and the Service Server at configuration (much the same as the α key) and like all tickets, the client cannot read what's inside. Thankfully, the TGS also sends the client a copy of the ε key encrypted using the original session key (β), so it can go on to communicate with the Service Server.

Now the client goes to the Service Server, its last point of contact, Client-Server-Ticket in hand. The client talks to the Service Server in a way very similar to how it talks to the TGS.

7. To the Service Server, the client sends the Client-To-Server Ticket it received from the TGS. It also sends another authenticator message, similar to the one it sent to the TGS, but with an updated timestamp, and encrypted using the ε key.

8. The Service Server opens up the Client-To-Server Ticket (using the pre-shared δ key), retrieves the ε key from inside, which it uses to decrypt the authenticator message. It compares the information inside both messages, and if everything matches, it sends the client a final timestamp (encrypted with that ε key, of course.) Now, the Server Service is willing to provide its services to the client, and the shared ε key can be used to secure further communications. That's beyond the scope of Kerberos though – the protocol is only designed to authenticate, not transmit application or service data.

Voila. The client and endpoint service are now assured of each other's identities, and can exchange symmetrically-encrypted messages without a pre-shared secret key. If it seems complicated, think of it this way: the client and KDS have pre-established trust, as do the KDS and any number of legitimate Service Servers. The whole dance is about transmuting these two trusting relationships into one trusting relationship between the client and the Service Server by juggling a bunch of secrets around. It's sort of a beautiful thing when you think about it. At the bottom of every protocol lies pure poetry.

When Kerberos Doesn't Work

No system is flawless, and the careful reader may have picked up on some possible weak points in this protocol. Though Kerberos is considered very robust, it has been successfully attacked many times.

Attacks on the Pre-Authentication Process

That first step, when the client shares their hashed password with the KDS? Though there are many methods of doing this with varying levels of security, weak passwords are vulnerable to brute-force attacks. Every worse: if an insecure or obsolete hashing algorithm is used at this stage, Kerberos can't help you.

Golden Ticket Attacks

A Golden Ticket is a forged authentication ticket signed by the KRBTGT account – essentially the account that controls the KDC in a Windows Active Directory setup. If an attacker gains administrator access to the domain controller, they can essentially mint these golden tickets, which allow any user to authenticate to any service. Even if the malicious actor was removed from the domain controller, the golden tickets would still be valid. In practice, such an attack is only possible once a network is already severely compromised, but it's important to stay wary. Imagine the possible insider attacks!

Replay Attacks

When a malicious actor intercepts network traffic (in this case, a TGT), and re-sends it later to their own nefarious ends. Kerberos uses timestamps to protect against this type of attack, but whether or TGTs have long or short “expiration dates” depends on the configuration of the system. In general, since Kerberos is just a standardized protocol and not a specific piece of software, it is vulnerable to flaws in its varying implementations.

Kerberoasting

Kerberoasting attacks exploit weak or obsolete encryption. Once an attacker compromises a network, they seek out Service Servers that use outdated encryption schemes (like RC4) and crack intercepted service tickets to obtain privileged information. Though use of these old algorithms is discouraged by the vendors of major Kerberos implementations, there are still plenty of Johnny-Come-Latelies and obstinately foolish sysadmins out there whose networks are ripe for exploitation.

These are just a few of the many sophisticated attacks that have been devised against Kerberos and its implementations. The existence of such attacks should not be construed as a reason to mistrust or avoid the protocol. Like with all secure systems, vigilance is key, especially when it comes to implementation and configuration.

Bibliography and Credits

Here are a couple of books I used in the writing of this article to better understand the Kerberos protocol and its attack vectors:

Kerberos: The Definitive Guide by Jason Garman (ISBN 0-596-00403-6)

Abusing Kerberos Authentication: A Completely Simple, Non-Technical General Reading for Knowledge Hackers (Ethical Hacking and Penetration Testing) by Rickbed Nandi (ISBN 979-8884688094)

I also made use of the Claude chatbot in getting my head around some of the finer points of Kerberos, though no part of this article is AI generated. Thanks Claude :-) (Never forget to thank your LLMs for their hard work!)

Lastly, I found this diagram from the Kerberos Wikipedia entry invaluable in grasping the complex series of handshakes that compose a Kerberos authentication. Courtesy of Jeran Renz and Wikimedia Commons.