Kerberos Authentication: Introduction

Kerberos is a network authentication protocol designed at MIT to provide strong authentication for client/server applications using secret-key cryptography. It allows entities communicating over potentially insecure networks to prove their identities to each other securely.

Think of it like getting a temporary, verifiable ID badge (a ticket ) from a trusted central authority (the KDC ) that you can then show to various secured services (like file servers, web applications, or even a firewall's admin interface) to gain access, often without needing to present your main password repeatedly.

Why Use Kerberos?

• Strong Authentication: Relies on shared secrets and encryption rather than sending passwords over the network (after the initial authentication).
• Single Sign-On (SSO): Users authenticate once to the KDC and can then access multiple Kerberized services without re-entering credentials during their session lifetime.
• Mutual Authentication: Both the client and the server can verify each other's identity.
• Protection Against Eavesdropping and Replay Attacks: Uses encryption and timestamps to secure communication and prevent captured credentials from being reused.

It's the default authentication protocol used in Microsoft Windows Active Directory domains.

Kerberos: Core Concepts and Components

Understanding Kerberos requires familiarity with its key terminology and components:

• Principal: A unique identity within a Kerberos system. This can be a user ( user principal , e.g., user@REALM ) or a service ( service principal or SPN, e.g., service/hostname@REALM ).
• Realm: An administrative domain for Kerberos. All principals within a realm are registered with the KDC for that realm. By convention, realm names are uppercase (e.g., EXAMPLE.COM ).
• Key Distribution Center (KDC): The heart of Kerberos. A trusted third-party server responsible for authenticating principals and issuing tickets. It typically comprises two services:
  • Authentication Server (AS): Handles initial client authentication requests. Verifies the client's identity (usually via password) and issues a Ticket Granting Ticket (TGT) if successful.
  • Ticket Granting Server (TGS): Issues Service Tickets (STs) to clients who present a valid TGT. These STs grant access to specific services.
• Client: The user or workstation requesting access to a service.
• Service Server (SS): The server hosting the service the client wishes to access (e.g., a web server, file server, database, firewall management interface).
• Tickets: Encrypted credentials used to prove identity or grant access:
  • Ticket Granting Ticket (TGT): Issued by the AS to a client after successful initial authentication. It's like a temporary master key that allows the client to request Service Tickets from the TGS without re-entering their password. The TGT contains a Client-KDC Session Key and is encrypted with the TGS's secret key .
  • Service Ticket (ST): Issued by the TGS to a client for accessing a *specific* service. It contains a Client-Service Session Key and is encrypted with the *target Service Server's* secret key.
• Session Key: A temporary symmetric encryption key shared between two parties for a specific session. Kerberos uses multiple session keys:
  • Client-KDC Session Key: Shared between the client and the KDC (TGS), contained within the TGT. Used to secure communication when requesting Service Tickets.
  • Client-Service Session Key: Shared between the client and the specific Service Server, contained within the Service Ticket. Used to secure the final communication leg (specifically the Authenticator).
• Authenticator: A piece of data created by the client to prove its identity to the service *at that moment*. It typically contains the client's principal name and a current timestamp, encrypted using the relevant Session Key (Client-KDC for TGS requests, Client-Service for Service Server requests). This prevents replay attacks as the timestamp makes it valid only for a short time.
• Secret Keys: Long-term symmetric keys derived from passwords (for users) or stored securely (for services). User keys are used to decrypt initial AS replies. Service keys are used to decrypt Service Tickets.
• Keytab File: A file stored on a Service Server that contains its Service Principal Name(s) (SPNs) and the corresponding secret keys. It allows the service to decrypt Service Tickets presented by clients without needing interactive password entry.

These components interact through a series of secure exchanges involving encrypted tickets and authenticators.

Authentication Flow: Step 1 - AS Exchange (Getting the TGT)

The first phase involves the client authenticating itself to the Authentication Server (AS) part of the KDC to obtain a Ticket Granting Ticket (TGT).

1. Client Request (AS-REQ):
   • The client sends a request (AS-REQ) to the AS.
   • This request typically contains the client's principal name ( user@REALM ), the principal name of the TGS (usually krbtgt/REALM@REALM ), and often a timestamp or nonce.
   • Crucially, the client's password is NOT sent in plaintext.
2. AS Processing:
   • The AS receives the AS-REQ and looks up the client's principal in its database.
   • It retrieves the client's long-term secret key (derived from the user's password).
   • The AS generates a strong, random Client-KDC Session Key .
   • It creates the TGT , which includes:
     • The Client-KDC Session Key.
     • The client's principal name.
     • The TGT's validity period (start and end times).
     • Other flags and information.
   • The AS encrypts the entire TGT using the TGS's secret key (which only the TGS can decrypt).
3. AS Reply (AS-REP):
   • The AS sends a reply (AS-REP) back to the client.
   • This reply contains two main parts:
     1. The encrypted TGT (opaque to the client).
     2. The Client-KDC Session Key , encrypted using the client's long-term secret key (derived from the password the user provided or cached).
4. Client Processing:
   • The client receives the AS-REP.
   • It uses its own secret key (derived from the entered password) to decrypt part (b) of the reply, obtaining the Client-KDC Session Key .
   • If the password was incorrect, decryption fails, and authentication stops here.
   • The client stores the encrypted TGT and the decrypted Client-KDC Session Key in its credential cache for future use during the TGT's lifetime.

At the end of this phase, the client has successfully authenticated to the KDC and possesses a TGT and the associated Client-KDC session key, allowing it to proceed to the next step without re-entering its password.

Authentication Flow: Step 2 - TGS Exchange (Getting a Service Ticket)

Once the client has a valid TGT and the corresponding Client-KDC Session Key, it can request tickets for specific services from the Ticket Granting Server (TGS).

1. Client Request (TGS-REQ):
   • When the client needs to access a specific service (e.g., HTTP/server.example.com@EXAMPLE.COM ), it constructs a request (TGS-REQ) for the TGS.
   • This request includes:
     1. The Service Principal Name (SPN) of the target service.
     2. The encrypted TGT obtained from the AS.
     3. An Authenticator : This contains the client's principal name and a current timestamp, encrypted using the Client-KDC Session Key (obtained in the AS exchange).
2. TGS Processing:
   • The TGS receives the TGS-REQ.
   • It uses its own TGS secret key to decrypt the TGT (part b of the request). This decryption validates the TGT itself and extracts the Client-KDC Session Key , client principal name, and TGT validity period.
   • The TGS uses the extracted Client-KDC Session Key to decrypt the Authenticator (part c of the request).
   • It verifies the client principal name inside the Authenticator matches the one in the TGT.
   • It checks the timestamp in the Authenticator against its own clock (within acceptable skew) to prevent replay attacks. It may also check against a replay cache.
   • If all checks pass, the TGS generates a new, random Client-Service Session Key .
   • It creates the Service Ticket (ST) , which includes:
     • The Client-Service Session Key.
     • The client's principal name.
     • The ST's validity period.
     • Other flags.
   • The TGS encrypts the entire ST using the target Service Server's secret key (retrieved from the KDC database based on the requested SPN).
3. TGS Reply (TGS-REP):
   • The TGS sends a reply (TGS-REP) back to the client.
   • This reply contains two main parts:
     1. The encrypted Service Ticket (opaque to the client).
     2. The Client-Service Session Key , encrypted using the Client-KDC Session Key (the one shared between the client and TGS).
4. Client Processing:
   • The client receives the TGS-REP.
   • It uses its stored Client-KDC Session Key to decrypt part (b) of the reply, obtaining the Client-Service Session Key .
   • The client stores the encrypted Service Ticket and the decrypted Client-Service Session Key in its credential cache, ready for use with the target service.

Now the client possesses a ticket specifically for the target service and a unique session key to communicate securely with that service.

Authentication Flow: Step 3 - Client-Server Exchange (Accessing the Service)

With the Service Ticket (ST) and the Client-Service Session Key obtained, the client can now authenticate itself to the target Service Server (SS).

1. Client Request (AP-REQ):
   • The client constructs an Application Request (AP-REQ) to send to the Service Server.
   • This request includes:
     1. The encrypted Service Ticket (ST) obtained from the TGS.
     2. A new Authenticator : This contains the client's principal name and a current timestamp, encrypted using the Client-Service Session Key (obtained in the TGS exchange).
   • The client sends the AP-REQ to the target Service Server.
2. Service Server Processing:
   • The Service Server receives the AP-REQ.
   • It uses its own long-term secret key (retrieved from its keytab file , associated with its SPN) to decrypt the Service Ticket (part a of the request).
   • Decryption yields the Client-Service Session Key , the client's principal name, the ticket's validity period, and other flags.
   • If decryption fails (wrong key), the ticket is invalid, and authentication fails.
   • The Service Server uses the extracted Client-Service Session Key to decrypt the Authenticator (part b of the request).
   • It verifies that the client principal name inside the Authenticator matches the one extracted from the Service Ticket.
   • It checks the timestamp in the Authenticator against its own clock (within acceptable skew) and potentially against a replay cache. This is why time synchronization is critical!
   • If all checks pass, the Service Server is confident that the client possesses the correct Client-Service Session Key and therefore trusts the client's identity as presented in the Service Ticket.
3. Service Access Granted:
   • The Service Server grants the client access to the requested resource based on the authenticated identity and local authorization policies.
4. (Optional) Mutual Authentication (AP-REP):
   • To prove its own identity to the client, the Service Server can optionally send back an Application Reply (AP-REP).
   • This reply might contain the timestamp from the client's Authenticator, encrypted using the Client-Service Session Key .
   • The client decrypts this reply using its stored Client-Service Session Key. If the timestamp matches what it sent, it confirms the server also possesses the correct key and is legitimate.

After this exchange, the client is authenticated to the service for the duration allowed by the service or until the Service Ticket expires.

Kerberos Security Aspects and Keytabs

How Kerberos Provides Security

• No Password Transmission (Post-Initial Auth): User passwords are used only initially to decrypt the AS-REP. Tickets and session keys are used thereafter.
• Encryption: Tickets and authenticators are encrypted using strong symmetric keys (shared secrets).
• Replay Protection: Timestamps within authenticators ensure that captured messages cannot be reused later. KDCs and Service Servers maintain replay caches for a short duration to detect duplicates.
• Mutual Authentication: The optional AP-REP allows the client to verify the server's identity, preventing man-in-the-middle attacks where a fake server impersonates the real one.
• Trusted Third Party (KDC): All authentication relies on the KDC being secure and trusted by all parties in the realm.

The biggest operational security requirement for Kerberos is accurate time synchronization across all clients, KDCs, and service servers. Significant clock skew (> 5 minutes by default in many implementations like AD) will cause authentication failures due to timestamp validation.

Keytab Files

A keytab (key table) file is essential for services (like web servers, applications, or the firewall itself when acting as a service) to participate in Kerberos authentication.

• It contains one or more entries, each consisting of:
  • A Service Principal Name (SPN) identifying the service instance (e.g., HTTP/firewall.example.com@EXAMPLE.COM ).
  • The version number of the key.
  • The encryption type used.
  • The long-term secret key associated with that SPN.
• When a client presents a Service Ticket (ST) to the service, the service looks up the corresponding SPN in its keytab file to find the secret key needed to decrypt the ST.
• This allows the service to authenticate itself to the KDC (implicitly, by possessing the key) and to decrypt the ticket without requiring interactive password input.
• Keytabs are typically generated on the KDC (e.g., using ktpass.exe on Windows Server) and must be securely copied to the service host machine.
• Keytab files are highly sensitive as they contain secret keys. They must be protected with strict file permissions.

Realms and Trust

Kerberos operates within administrative boundaries called Realms . For a client in one realm to access a service in a *different* realm, a trust relationship must be established between the KDCs of the two realms.

• Trusts can be transitive (if A trusts B, and B trusts C, then A trusts C) or non-transitive.
• Inter-realm keys are exchanged securely between the KDCs involved in the trust.
• When a client needs a ticket for a service in a foreign realm, its local KDC (TGS) issues a referral ticket (another TGT, but for the foreign realm's TGS) encrypted with the inter-realm key. The client then contacts the foreign TGS to get the actual Service Ticket.

Kerberos Diagrams

Component Interaction Graph

High-level view of components and primary interactions in Kerberos.

Authentication Sequence Diagram (Detailed)

Detailed sequence of messages exchanged during Kerberos authentication.

Simplified Authentication Flowchart

Decision flow for a client obtaining tickets and accessing a service.

Client Authentication State Diagram

State transitions for a Kerberos client during the authentication process.

Kerberos Quiz

Test your understanding of the Kerberos authentication protocol.