Kerberos, at its core, is a network authentication protocol that lets you prove who you are to a service without ever sending your password over the wire.
Let’s see it in action. Imagine alice wants to access the webserver on heavy.example.com.
First, alice gets a ticket from the Kerberos Key Distribution Center (KDC). The KDC is usually split into two parts: the Authentication Server (AS) and the Ticket Granting Server (TGS).
alice sends her username to the AS. The AS checks if alice exists. If she does, it sends back two things:
- An encrypted "session key" for
aliceand the TGS. This is encrypted withalice’s password hash. - A "ticket" for the TGS. This ticket contains
alice’s username, her network address, a timestamp, and a session key foraliceand the TGS. This ticket is encrypted with the TGS’s secret key.
alice’s machine (the client) receives these. It asks alice for her password. It then uses that password to decrypt the first part (the session key for alice and the TGS). If the decryption works, alice is authenticated to her own machine. If it fails, she gets a "Password incorrect" error.
Now, alice wants to access the webserver. She uses the session key she just got to authenticate herself to the TGS. She sends the TGS her ticket (which the TGS can decrypt with its own secret key) and an "authenticator." The authenticator contains alice’s username, a timestamp, and is encrypted with the session key she got from the AS.
The TGS decrypts the ticket, then uses the session key within it to decrypt the authenticator. If the timestamp is recent and the username matches, the TGS knows alice is who she says she is. The TGS then issues a "service ticket" for the webserver. This service ticket contains alice’s username, a session key for alice and the webserver, a timestamp, and is encrypted with the webserver’s secret key. The TGS also sends alice the session key for alice and the webserver, encrypted with the alice-to-TGS session key.
Finally, alice presents the service ticket to the webserver. She also sends an authenticator (username, timestamp, encrypted with the alice-to-webserver session key). The webserver decrypts the ticket using its own secret key, then uses the session key from the ticket to decrypt the authenticator. If successful, alice is authenticated to the webserver.
This whole process is designed to avoid sending alice’s password anywhere but to her own machine for the initial decryption. The "tickets" and "session keys" act as temporary credentials.
The problem Kerberos solves is enabling single sign-on (SSO) across multiple services in a distributed network without compromising security by repeatedly sending plaintext passwords. It’s a fundamental building block for many enterprise authentication systems, like Active Directory.
What most people don’t realize is that the "session keys" are just symmetric encryption keys, and the whole system relies on a trusted third party (the KDC) that has pre-shared secret keys with every principal (users and services) on the network. If the KDC’s secret key is compromised, the entire network’s authentication is broken.
The next step is understanding how to manage principals and keytabs, and what happens when clock skew becomes an issue.