Kerberos (protocol) TEST

A practical, end-to-end walkthrough of the authentication protocol behind Active Directory, MIT Kerberos, and most enterprise SSO.

Why Kerberos Exists

Imagine 500 employees, 50 servers, and one attacker with a packet sniffer on the LAN. How do you prove who you are to every server, dozens of times a day, without ever sending your password across the wire?

That is the problem Kerberos solves — and it has been solving it since MIT’s Project Athena in the late 1980s. Today it is the authentication backbone of:

  • Microsoft Active Directory (every domain login)
  • Linux/Unix single sign-on (via MIT Kerberos or Heimdal)
  • Hadoop, Kafka, HDFS, SSH GSSAPI, NFSv4, SMB, PostgreSQL, and more

Its three big guarantees:

  1. No password ever crosses the network — not even encrypted.
  2. Mutual authentication — the server proves who it is, too.
  3. Time-boxed tickets — stolen credentials expire quickly (typically 10 hours).

The Cast of Characters

Component Role
Client The user (or service) trying to authenticate.
KDC — Key Distribution Center The trusted third party. Every principal shares a secret key with it.
   ├─ AS — Authentication Server Issues the initial Ticket-Granting Ticket (TGT).
   └─ TGS — Ticket-Granting Server Exchanges the TGT for per-service tickets.
Service The resource the client wants to access (file server, database, web app).
Realm An administrative domain, written in uppercase (EXAMPLE.COM).
Principal A named identity, like alice@EXAMPLE.COM or HTTP/web01.example.com@EXAMPLE.COM.

Two kinds of keys matter:

  • Long-term keys — derived from the user’s password (or stored in a keytab for services). Never leave their owner.
  • Session keys — short-lived symmetric keys the KDC mints on demand.

The Protocol Flow

Kerberos is a six-message exchange in three phases:

                    +------------------------------+
                    |            KDC               |
                    |   +---------+   +--------+   |
                    |   |   AS    |   |  TGS   |   |
                    |   +----+----+   +---+----+   |
                    +--------|------------|--------+
             (1) AS-REQ      |            |
        --------------------->            |
             (2) AS-REP                   |
        <---------------------            |
                                          |
             (3) TGS-REQ                  |
        -------------------------------->
             (4) TGS-REP
        <--------------------------------
   +----------+                              +------------+
   |  Client  |       (5) AP-REQ             |  Service   |
   |          |------------------------------>            |
   |          |       (6) AP-REP (optional)  |            |
   |          |<-----------------------------|            |
   +----------+                              +------------+

Phase 1 — Get a TGT (AS Exchange)

(1) AS-REQ — Client says: “Hi, I’m alice@EXAMPLE.COM, and I’d like a TGT.” The request includes a pre-authentication blob: the current timestamp encrypted with Alice’s password-derived key. This proves she knows the password without sending it.

(2) AS-REP — The AS looks up Alice’s key, decrypts the timestamp, and if it’s fresh, replies with:

  • A TGT, encrypted with the TGS’s secret key (so only the TGS can open it). Inside: Alice’s identity, a fresh session key K_c,tgs, and an expiration time.
  • A copy of K_c,tgs, encrypted with Alice’s key (so only Alice can open it).

At this point Alice’s workstation can throw away her password. The TGT is her “ID badge” for the next ~10 hours.

Phase 2 — Get a Service Ticket (TGS Exchange)

(3) TGS-REQ — Alice wants to talk to HTTP/web01.example.com. She sends:

  • The TGT (which she can’t read, but that’s fine).
  • An authenticator: her identity + timestamp, encrypted with K_c,tgs.
  • The name of the service she wants.

(4) TGS-REP — The TGS decrypts the TGT with its own key, extracts K_c,tgs, uses it to verify the authenticator, and replies with:

  • A service ticket, encrypted with the web server’s key.
  • A new session key K_c,web, encrypted with K_c,tgs.

Phase 3 — Talk to the Service (AP Exchange)

(5) AP-REQ — Alice sends the service ticket + a fresh authenticator (encrypted with K_c,web) to the web server.

(6) AP-REP (optional, when mutual auth is requested) — The web server decrypts the ticket, verifies the authenticator, and returns Alice’s timestamp + 1, encrypted with K_c,web. Now Alice knows the server is genuine too.

Alice is in. And for the next ~10 hours she can reach any Kerberized service by repeating just Phase 2 and 3 — no password prompts.

A Real Example: kinit on Linux

# 1. Get a TGT
$ kinit alice@EXAMPLE.COM
Password for alice@EXAMPLE.COM: ********

# 2. Inspect the ticket cache
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: alice@EXAMPLE.COM

Valid starting     Expires            Service principal
07/05/26 09:14:22  07/05/26 19:14:22  krbtgt/EXAMPLE.COM@EXAMPLE.COM
    renew until 07/12/26 09:14:22

# 3. Use it — SSH with GSSAPI, no password needed
$ ssh -o GSSAPIAuthentication=yes web01.example.com
Last login: ...
alice@web01:~$

# 4. A service ticket now appears in the cache
$ klist
...
07/05/26 09:15:03  07/05/26 19:14:22  host/web01.example.com@EXAMPLE.COM

# 5. When you’re done
$ kdestroy

For a service principal (e.g. a web server), the equivalent of the password is a keytab:

$ sudo klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------
   3 HTTP/web01.example.com@EXAMPLE.COM
   3 host/web01.example.com@EXAMPLE.COM

Why Timestamps Matter (and the 5-Minute Rule)

Every authenticator is timestamped. If a replay attacker captures an AP-REQ and re-sends it, the server rejects it because either:

  • The timestamp is outside the acceptable window (default ±5 minutes), or
  • The server has already cached that authenticator (replay cache).

This is why every Kerberos deployment insists on NTP across all hosts. A clock skew of more than 5 minutes and authentication silently breaks — the #1 support call in AD environments.

Security Considerations & Known Attacks

Kerberos is battle-tested, but it isn’t magic. Practitioners should know:

  • KDC is a single point of trust. Compromise the KDC’s database and every principal in the realm is compromised. Protect it like a crown jewel; run redundant KDCs for availability.
  • Golden Ticket attack — If an attacker steals the krbtgt account’s key hash, they can forge arbitrary TGTs (any user, any group, any lifetime). Detection is hard; rotation requires changing krbtgt twice.
  • Silver Ticket attack — Steal a service account’s key and forge tickets for that one service. Bypasses the KDC entirely, so it leaves no KDC logs.
  • Kerberoasting — Any authenticated user can request service tickets, which are encrypted with the service account’s key. If that key is derived from a weak password, it can be cracked offline. Mitigation: long, random passwords for service accounts; prefer AES over RC4.
  • AS-REP roasting — Accounts with pre-authentication disabled leak a hash crackable offline. Never disable pre-auth.
  • Pass-the-Ticket — Stolen ticket caches (or LSASS memory on Windows) can be reused on other machines until they expire.
  • Downgrade attacks — Force use of weaker ciphers (RC4-HMAC) when AES is available. Disable RC4 in modern deployments.

Kerberos vs. Alternatives — When to Use What

Protocol Best for Weakness vs. Kerberos
Kerberos Intra-domain SSO, high-trust LAN, service-to-service Requires KDC; hostile to NAT and roaming clients
OAuth 2.0 / OIDC Web + mobile + third-party APIs Token theft is easier; no built-in mutual auth
SAML Federated web SSO between organizations Verbose; XML signature pitfalls
mTLS Machine-to-machine, zero-trust networks Certificate management overhead

Kerberos remains the gold standard when you control the network and need low-latency, high-throughput authentication for many services.

Further Reading

  • RFC 4120 — The Kerberos Network Authentication Service (V5)
  • MIT Kerberos documentation — web.mit.edu/kerberos
  • Neuman & Ts’o (1994), Kerberos: An Authentication Service for Computer Networks — the classic paper
  • Microsoft’s Active Directory Attacks documentation for the offensive side

TL;DR

Kerberos exchanges your password once for a TGT, then swaps that TGT for short-lived, per-service tickets, all mediated by a trusted KDC. Nothing sensitive ever crosses the wire in the clear, every message is timestamped, and the whole thing hangs together on symmetric crypto and synchronized clocks. Master the six-message flow, keep your KDC healthy, run NTP, and rotate krbtgt regularly — and you have the same authentication backbone that runs most of the enterprise world.

Unknown's avatar

Published by mshaik

Leave a comment