Kerberos Architecture and Ticket Flow

Kerberos was developed at MIT as part of Project Athena in the 1980s to provide secure network authentication for a distributed computing environment. Named after the three-headed dog guarding the underworld, it provides mutual authentication between clients and services using a trusted third party: the Key Distribution Center.

The KDC has two logical components: the Authentication Service (AS) and the Ticket Granting Service (TGS). In Microsoft Active Directory, both run on the domain controller. The AS handles initial login and issues Ticket Granting Tickets (TGTs). The TGS issues service tickets for accessing specific services.

The client begins authentication by sending an AS-REQ to the Authentication Service. Modern Kerberos requires pre-authentication: the client encrypts a timestamp with its long-term key (derived from the password) to prove it knows the password. This prevents offline dictionary attacks against unprotected AS-REQ messages.

The AS verifies the pre-authentication data and responds with an AS-REP containing a Ticket Granting Ticket (TGT) encrypted with the krbtgt account's long-term key (which the client cannot decrypt) and a session key encrypted with the client's long-term key. The client decrypts only its portion to obtain the TGS session key.

When the client wants to access a service, it sends a TGS-REQ to the Ticket Granting Service, including the TGT (as proof of identity) and an authenticator encrypted with the TGS session key. The TGS decrypts the TGT with the krbtgt key to verify the client's identity.

The TGS responds with a service ticket encrypted with the target service's long-term key, plus a new session key encrypted for the client. The client cannot read the service ticket contents, only the portion encrypted for it. This service ticket proves the client's identity to the service.

The client sends an AP-REQ to the target service, including the service ticket and a new authenticator encrypted with the service session key. The service decrypts the service ticket using its own long-term key, verifies the authenticator, and authenticates the client. No password is ever sent to the service.

A Kerberos realm is an administrative domain managed by a single KDC. Cross-realm authentication is established through inter-realm keys shared between KDCs of different realms. When a client in Realm A accesses a service in Realm B, the KDC in Realm A issues a referral ticket that the client presents to Realm B's KDC.

Kerberos tickets have a configured lifetime (typically 10 hours for TGTs) after which they expire and new authentication is required. TGTs can also be configured as renewable, allowing the client to request a fresh TGT from the KDC without re-entering credentials, up to a maximum renewable lifetime.

Kerberos uses two types of keys. Long-term keys are derived from account passwords and used only to encrypt portions of authentication messages. Session keys are negotiated fresh for each authentication exchange and used for the actual communication session. Compromising a session key does not expose the long-term key.

Kerberos provides mutual authentication (both client and service are verified), replay protection (via timestamps and authenticators), and forward secrecy of individual sessions. The KDC never exposes long-term keys during normal operation. The main trust assumption is that the KDC itself is not compromised.

What is the purpose of a Ticket Granting Ticket (TGT) in Kerberos?

Kerberos uses a KDC with AS and TGS components. Login produces a TGT (AS-REQ/AS-REP). Service access requires exchanging the TGT for a service ticket (TGS-REQ/TGS-REP). The service ticket is presented to the target service (AP-REQ). Only the KDC and respective services can read tickets. Realms allow cross-domain authentication via inter-realm trust.