Kerberos: tickets, authenticators, and the three exchanges

The problem, stated so the protocol falls out of it

Put a few hundred workstations and a dozen servers on one network and you have a problem that no amount of file permissions solves. A workstation cannot be trusted to say truthfully who is using it. Any client can send any request to any server, so the risk is not that someone reads a file they should not — it is impersonation: a request that claims to come from Anwar and is honoured because nothing checked.

One obvious fix is to make every server authenticate every user. That works and nobody does it, because it means every server keeps a password database, every password change touches a dozen machines, and every server becomes a target worth attacking. So centralise it: put one authentication server (AS) on the network that knows every user's password, and let it vouch for people. Kerberos is what you get when you take that idea seriously and then patch every hole a competent attacker points at.

The derivation — each step is a threat and its answer

Patch 1 — do not send the password. The client must not transmit the password across the network, and the AS must not send a plaintext "this really is Anwar" message to a server, because an eavesdropper could capture and replay either. Instead the AS encrypts its reply under a key derived from the user's password. Only a client that can produce that password can read it. The password itself never leaves the workstation.

Patch 2 — do not ask for the password again. If the client must re-authenticate to the AS for each service it touches, the user is typing their password all morning; if instead the workstation caches the password to avoid that, one compromised workstation leaks a credential that never expires. So split the job: the AS issues, once, a reusable ticket-granting ticket (TGT), and a second server — the ticket-granting server (TGS) — trades that TGT for a ticket to whichever service is wanted.

Patch 3 — a reusable ticket is a replayable ticket. An opponent who captures a TGT can wait until the user has logged off, sit down at the workstation, or configure their own machine with the victim's network address, and present the captured ticket. So each ticket carries a timestamp and a lifetime: past the lifetime, it is refused. That bounds the damage but does not remove it, and the lifetime is a genuine trade — minutes means re-prompting for the password constantly, hours means a wide replay window.

Patch 4 — prove freshness, not just possession. Inside the window, capture-and-replay still works, because presenting a ticket only proves you have it. So the client also sends a small, single-use authenticator, encrypted under the session key that the AS placed inside the ticket. The TGS decrypts the ticket with the key it shares with the AS, recovers the session key, decrypts the authenticator with it, and then checks three things against each other: the name in the authenticator, the name in the ticket, and the network address the request actually arrived from.

The three exchanges, and how often each one happens

The frequencies are the structure, and they are the most likely thing to be drawn on an exam paper.

1. The AS exchange — once per user logon session. The client asks for a TGT; the AS returns the TGT plus a session key for the client and the TGS, encrypted under the password-derived key.
2. The TGS exchange — once per type of service. The client presents the TGT and a fresh authenticator; the TGS returns a service-granting ticket plus a new session key for the client and that server.
3. The application-server exchange — once per service session. The client presents the service ticket and another fresh authenticator; the server may reply to authenticate itself back.

Swapping the AS and the TGS is the standard error. The mnemonic is the frequency: the AS is the thing you touch when you log on, once; the TGS is the thing you touch when you want a new kind of service.

The one distinction the exam is really after

A ticket contains the user ID, the client's network address (AD_C), the server ID, a timestamp, a lifetime, and a second copy of the session key — all encrypted under the key shared between the ticket's issuer and the target server. The network address is easy to drop from the list and load-bearing when you do: it is what lets the recipient refuse a ticket presented from a machine other than the one it was issued to. It is reusable, it is tamper-proof because the client cannot read or alter it, and — this is the part people get wrong — it proves nobody's identity. A ticket is a mechanism for distributing a key. It says, in effect, "whoever can use this session key is Anwar."

An authenticator contains the user ID, the user's network address and a timestamp, encrypted under the session key. It is single-use and very short-lived, and it is the thing that actually proves the client's identity, by demonstrating possession of a key that only the legitimate holder of the ticket could have obtained. It says, "at this moment, I am the one using that session key."

Worked example — one login, traced end to end

Anwar logs in at 09:00 on workstation ws-14 and wants the print server prn1.

1. ws-14 sends the AS: Anwar, TGS, 09:00:02. No password, no secret.
2. The AS looks up Anwar's password, derives $K_a$ from it, and returns two things encrypted under $K_a$: the session key $K_{a,tgs}$, and a TGT — Anwar's ID, ws-14's address 10.4.1.14, the TGS's ID, 09:00:02, a lifetime of 8 hours, and a second copy of $K_{a,tgs}$ — the whole TGT encrypted under $K_{tgs}$, which only the TGS can open. ws-14 prompts for the password, derives $K_a$, decrypts, and discards the password.
3. ws-14 sends the TGS: the TGT, the name prn1, and an authenticator — Anwar, 10.4.1.14, 09:00:05 — encrypted under $K_{a,tgs}$.
4. The TGS opens the TGT with $K_{tgs}$, lifts $K_{a,tgs}$ out of it, opens the authenticator with that, checks Anwar-in-authenticator against Anwar-in-ticket against the source address 10.4.1.14, and returns a service ticket for prn1 plus a fresh session key $K_{a,prn1}$.
5. ws-14 sends prn1 the service ticket and a new authenticator — Anwar, 10.4.1.14, 09:00:07 — encrypted under $K_{a,prn1}$.
6. For mutual authentication, prn1 returns 09:00:08 — the authenticator's timestamp incremented by one — encrypted under $K_{a,prn1}$. Two properties do the work at once: only prn1 could have produced it, because only prn1 could have opened the ticket to learn $K_{a,prn1}$; and it cannot be a replay of an old reply, because the value is derived from a timestamp the client only just chose.

At 11:30 Anwar wants a second printer. Step 1 does not repeat — the TGT is still inside its 8-hour lifetime, so the session resumes at step 3.