Learn Kerberos - Kerberos Authentication Flow - Deep Dive

#Introduction

In episode 2 you learned the Kerberos architecture map: client, KDC (AS + TGS + database), service server, and the concepts of principal, realm, and ticket. Now it's time to start the engine. This episode dissects the Kerberos authentication flow — the journey that begins when you type kinit and ends with access to a service.

The flow consists of three sequential message exchanges: AS-REQ/AS-REP (initial authentication), TGS-REQ/TGS-REP (requesting a service ticket), and AP-REQ/AP-REP (accessing the service). Along the way we'll see how session keys are born, how authenticators prevent misuse, and how timestamps keep everything fresh. Let's start with the big picture.

#Overview: Three Message Exchanges

Client               KDC (AS/TGS)                 Service
  │ 1. AS-REQ (identity + timestamp)                  │
  ├──────────────────►                                │
  │ 2. AS-REP (TGT + TGS session key)                 │
  │◄──────────────────                                 │
  │ 3. TGS-REQ (TGT + service name)                   │
  ├──────────────────►                                │
  │ 4. TGS-REP (service ticket + session key)         │
  │◄──────────────────                                 │
  │ 5. AP-REQ (service ticket + authenticator)        │
  ├───────────────────────────────────────────────────►
  │ 6. AP-REP (optional: service identity proof)      │
  │◄───────────────────────────────────────────────────

#AS-REQ / AS-REP: Initial Authentication

Everything begins when you run kinit. Here's the first exchange:

1. The client sends AS-REQ to the Authentication Server. The message contains the principal's identity and preauthentication — usually a timestamp encrypted with the client's long-term key. This proves the client really knows its password, without sending the password over the network.

2. The AS verifies the timestamp with the client's key stored in the database. If it matches, the AS believes the client is the principal's owner.

3. The AS creates a new session key for the client and the TGS — call it K_c,tgs — then wraps it into two packages:

   • TGT, encrypted with the TGS key (K_tgs), containing the session key K_c,tgs and validity data.
   • The session key K_c,tgs, encrypted with the client's long-term key.

4. The client receives AS-REP, decrypts the session key with the key derived from its password. Now the client has a TGT and the TGS session key.

Note the important part: the password is never sent. What crosses the network is only an encrypted block that only the holder of the correct key can open.

#TGS-REQ / TGS-REP: Requesting a Service Ticket

The TGT alone isn't enough — the service will reject a TGT. The client must exchange the TGT for a service ticket specific to the target service:

1. The client sends TGS-REQ to the Ticket Granting Server containing the TGT, the target service name (SPN, e.g. host/client1.example.com), and an authenticator.

2. The TGS opens the TGT with the TGS key (K_tgs). The TGT's contents state that the client has logged in and contain the session key K_c,tgs.

3. The TGS validates the authenticator using the K_c,tgs extracted from the TGT. This proves the TGT holder is really the client (not a ticket thief), because only the client possesses K_c,tgs.

4. The TGS creates a new session key for the client and the service — call it K_c,s — then wraps it:

   • Service ticket, encrypted with the service key (K_s), containing K_c,s and the client's identity.
   • The session key K_c,s, encrypted with K_c,tgs.

5. The client receives TGS-REP, opens K_c,s with K_c,tgs. Now the client has a service ticket and the service session key.

The beauty of this design: the client never sees the service key, and the service never sees the TGS key. Each party only knows the part it's entitled to.

#AP-REQ / AP-REP: Accessing the Service

Now the client talks directly to the service:

1. The client sends AP-REQ to the service containing the service ticket and a new authenticator — a timestamp encrypted with the session key K_c,s.

2. The service opens the service ticket with its long-term key (K_s), extracting K_c,s and the client's identity.

3. The service validates the authenticator with K_c,s. Because the authenticator is encrypted with a session key only the client and service know, the service is confident the sender is the legitimate client.

4. AP-REP (optional) — for mutual authentication, the service sends back its own authenticator (a timestamp encrypted with K_c,s). The client opens it and is now confident it's talking to the real service, not an impostor.

5. From this point on, all communication between client and service is encrypted using the session key K_c,s.

#Authenticator, Timestamp, and Replay Cache

The authenticator is the unsung hero of Kerberos security. It's a small block containing the client's identity and a timestamp, encrypted with the current session key. The authenticator proves two things at once:

• The ticket holder genuinely possesses the session key (proof of possession).
• The request is fresh — not an old recording (proof of timeliness).

Because of that timestamp, clock synchronization becomes critical — a topic we'll cover thoroughly in episode 4. The service keeps already-received timestamps in a replay cache: if the same timestamp appears again (a sign of replay attack), the request is rejected immediately.

#Session Key and Forward Secrecy

Each exchange gives birth to a new session key that lives for only one session: K_c,tgs for client-TGS communication, then K_c,s for client-service communication. When the session ends, the key is discarded.

This property provides forward secrecy on a limited scale: if a session key leaks, an attacker can only read that session's conversation — not past conversations that used different keys, let alone all long-term credentials. Leaking one hotel key doesn't automatically open every room in the building.

#SPNEGO: The Wrapper in the Real World

In real applications — especially web — Kerberos rarely speaks directly. It's wrapped by SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism). SPNEGO is a negotiation mechanism on top of GSSAPI that lets the client and server agree on a shared authentication mechanism, and Kerberos is the mechanism most often chosen.

When a browser and server communicate over HTTP, the Authorization: Negotiate ... header carries the SPNEGO token — hidden inside it is the Kerberos AP-REQ. This is the foundation of web SSO that we'll dissect in episode 15 on SPNEGO/Negotiate.

#Guaranteed Security Properties

A summary of the security the flow above provides:

• Passwords never cross the network — only tickets and encrypted authenticators travel.
• Time-limited tickets — every ticket has a validity period, so nothing lasts forever like a password.
• Replay attacks are rejected — timestamp + replay cache make old packet copies useless.
• Mutual authentication — AP-REP ensures both client and service are verified.
• Session keys provide isolation — one leaked key doesn't open other sessions.

If you want to see this flow live, run KRB5_TRACE=1 kinit in your lab — Kerberos will print the cryptographic trace of every AS and TGS step, exactly as dissected above.

#Conclusion

This episode dissected the Kerberos authentication flow from kinit to service access: AS-REQ/AS-REP issues the TGT and the first session key, TGS-REQ/TGS-REP exchanges the TGT for a service ticket, and AP-REQ/AP-REP accesses the service with mutual authentication. Along the way, authenticators and timestamps keep every request authentic and fresh, the replay cache rejects replay attacks, and SPNEGO wraps everything for web applications.

Key points to take with you:

• Three exchanges: AS (login), TGS (exchange TGT), AP (access service).
• Authenticator = identity + timestamp, encrypted with the session key.
• Timestamp + replay cache are the bastion against replay attacks — and the reason time must be synchronized.
• SPNEGO wraps Kerberos for web applications (details in episode 15).

In the next episode, episode 4, we'll handle the two infrastructure prerequisites that most often break all these flows: DNS and time synchronization. We'll set up NTP with chrony, configure krb5.conf, create SRV records for KDC discovery, and troubleshoot the Clock skew too great error. Make sure your lab is ready — this episode is full of practice!