Kerberos Visualization | TGT, Service Tickets and Session Keys

The idea: prove you know the password without sending it

Kerberos is the login system of Windows Active Directory and of many Unix networks. alice types her password once in the morning. After that she can reach file servers, web servers and databases all day, and none of them ever sees her password. The trick is a trusted third party, the KDC (Key Distribution Center), which shares one secret key with every user and every service and hands out tickets.

The client talks to the KDC twice and to the web server once. 1 AS-REQ and 2 AS-REP between the client and the AS give the client a TGT and SK1. 3 TGS-REQ and 4 TGS-REP between the client and the TGS give it a service ticket and SK2. 5 AP-REQ and 6 AP-REP between the client and the web server log it in. The KDC and the web server never talk to each other. — Three exchanges: log in once at the AS, buy a ticket per service at the TGS, show it to the service.

The canvas follows one login in the realm EXAMPLE.COM: the client on the left, the KDC (with its two parts, the AS and the TGS) in the middle, the web server HTTP/web.example.com on the right, and below them every message that crossed the network, as an eavesdropper, Eve, would copy it. Each coloured chip is a key. A message written as {…}K is encrypted with key K and can only be opened by someone who holds K. Kerberos uses only symmetric encryption (AES in practice): the same key locks and unlocks.

The keys and who holds them

Key	What it is	Who has it
Ka user key	`string2key(password, salt)`, a hash of alice's password	the KDC (stored); the client only while `kinit` runs
Ktgs TGS key	the key of the principal `krbtgt/EXAMPLE.COM`	only the KDC
Ks service key	the key of `HTTP/web.example.com`	the KDC and the web server's keytab
SK1 session key	random, made by the AS for one login	the client and (inside the TGT) the TGS
SK2 session key	random, made by the TGS for one service	the client and (inside the ticket) the web server

The first three are long-term keys, set up in advance. The last two are session keys: fresh for every login and every ticket, and only valid until the ticket expires. The KDC does not even keep them: it puts each session key inside a ticket sealed with a key that only the KDC or the service can open, and gets it back from there when the ticket returns.

AS exchange: logging in and getting a TGT

kinit alice asks for the password and turns it into Ka on the client. The AS-REQ names alice and the TGS, and as pre-authentication it carries the current time encrypted with Ka (PA-ENC-TIMESTAMP). The AS looks up alice's Ka, decrypts the timestamp and checks that it is within 5 minutes of its own clock. Only someone who knows the password could have made that ciphertext.

The AS-REP has two parts. The TGT (ticket-granting ticket) is {alice, SK1, end time}Ktgs: alice carries it but cannot read or change it. The second part, {SK1, nonce, end time}Ka, is for alice: her Ka opens it and gives her SK1. Then kinit forgets Ka (Demo: log in and reach the web server). With a wrong password the timestamp does not decrypt and the AS answers KDC_ERR_PREAUTH_FAILED (Demo: wrong password, pre-auth fails). Because no AS-REP is sent, an attacker does not even get a ciphertext under Ka to guess passwords against offline.

TGS exchange: a ticket for one service

To reach HTTP/web.example.com, the client sends the TGS-REQ: the service name, the TGT unchanged, and an authenticator {alice, time}SK1. The TGS opens the TGT with Ktgs, takes SK1 out of it, and uses SK1 to open the authenticator. If the names match and the time is fresh, the sender holds SK1, so it is alice. The TGS makes SK2 and answers with the service ticket {alice, SK2, end}Ks and {SK2}SK1 for alice. No password and no Ka are involved: this is what makes Kerberos single sign-on.

AP exchange: showing the ticket

The AP-REQ carries the service ticket and a new authenticator {alice, time}SK2. The web server opens the ticket with Ks from its keytab (/etc/krb5.keytab), takes SK2, opens the authenticator and checks the time. It never calls the KDC. With mutual authentication on, it returns the AP-REP {time}SK2; only a server holding Ks could have found SK2, so alice knows she reached the real server. The two now share SK2 and can use it to protect the rest of the session.

A table of the six messages, time running down, with the key that seals each part: AS-REQ timestamp under Ka; AS-REP TGT under Ktgs and the SK1 part under Ka; TGS-REQ TGT under Ktgs and authenticator under SK1; TGS-REP ticket under Ks and SK2 part under SK1; AP-REQ ticket under Ks and authenticator under SK2; AP-REP time under SK2. A row at the bottom says the password appears in none of them. — Every part of every message is sealed with a key that only its two rightful parties hold; the password is in none of them.

Time: clock skew, replays and expiry

An authenticator is just a name and a time, so anyone who copies it could send it again. Kerberos stops that with time:

Check	Default	Error	Demo
Timestamp within the allowed clock skew	`clockskew = 300` s	`KRB_AP_ERR_SKEW`	client clock 7 min fast
Authenticator not seen before (replay cache)	kept for the skew window	`KRB_AP_ERR_REPEAT`	Eve replays a captured AP-REQ
Ticket not past its end time	`ticket_lifetime = 10h`	`KRB_AP_ERR_TKT_EXPIRED`	tickets expire after 10 h

Eve can copy the AP-REQ and send it again within the 5 minutes, but the server's replay cache already holds that authenticator. To make a new one she would need SK2, and SK2 only ever travelled sealed under Ks or SK1. This is why every machine in a Kerberos realm must keep its clock in sync (NTP).

Kerberos, OAuth and public keys

Kerberos and OAuth 2.0 both hand out short-lived tokens so that services never see the password. They differ in where they fit:

	Kerberos	OAuth 2.0
Typical home	one organisation's network (Active Directory)	the web, across companies
Proof of identity	authenticator sealed with a session key	bearer access token (whoever holds it may use it)
Crypto	symmetric keys shared with the KDC	TLS plus signed tokens (often public-key JWTs)
Service checks the token	by opening it with its own key, no call to the KDC	by verifying a signature or asking the server

The KDC is a single point of trust: whoever steals the KDC's database (or just Ktgs) can make tickets for anyone. Public-key systems avoid a central key store; see Symmetric vs Asymmetric Encryption. Stored password hashes have the same weakness as Ka; see Salt vs Pepper.

What the page leaves out

Real messages are ASN.1 with flags (forwardable, renewable), nonces, address lists and checksums; tickets can be renewed up to renew_lifetime without the password.
Encryption types (aes256-cts-hmac-sha1-96 and others) and the salt and iteration count of string2key.
PKINIT (log in with a certificate or smart card), FAST armoring, cross-realm trust and referrals.
Active Directory details: the PAC with group memberships, SPNs, delegation and attacks such as Kerberoasting, pass-the-ticket and golden tickets.
GSS-API and SPNEGO, which carry the AP-REQ inside protocols such as HTTP (Authorization: Negotiate), SMB and LDAP.