Learn Kerberos - Kerberos Architecture & Core Concepts

#Introduction

In episode 1 you learned why Kerberos exists: to answer traditional authentication problems with encrypted tickets, mutual authentication, and SSO. Now it's time to unpack how this protocol works — starting with who the players are, how identity is represented, and how trust is built among them.

This episode introduces the entire Kerberos vocabulary: the three-head architecture (client, KDC, service server), the concepts of realm and principal, tickets and TGT, long-term keys versus session keys, and the trust model with the KDC as the trusted third party. Think of this episode as a "concept map" — in episode 3 we'll start the engine and watch the authentication flow run step by step.

#The Three-Head Architecture

Kerberos works with three parties, just like its mythological name:

   +-----------+         +--------------------+         +---------------+
   |  CLIENT   |  <--->  |   KDC              |  <--->  |  SERVICE      |
   | (user)    |  ticket |  AS + TGS + DB     |  keys   |  SERVER       |
   +-----------+         +--------------------+         +---------------+

#Key Distribution Center (KDC)

The KDC is the heart of Kerberos — the third party trusted by everyone. It consists of three complementary components:

The KDC stores the long-term key of every principal. Because these keys are stored in one place, the KDC truly becomes the single source of truth — and for that same reason, it's the most attractive target for attackers, a topic we'll cover in episode 21 (Golden Ticket attacks).

#Client

The client is the user or service requesting access to a service. It holds a password that is derived into a long-term key — but this key is never sent over the network. The client communicates with the KDC to obtain tickets, then uses those tickets to access services.

#Service Server

The service server is the service providing the resource — for example, an SSH server, file server, or web server. It holds its own long-term key stored in a keytab, and can only open tickets issued specifically for it.

#Realm: The Administrative Boundary

A realm is the Kerberos administrative boundary — a sort of "kingdom" with its own KDC and principal database. Its naming convention is always uppercase, following the domain name. For example, the domain example.com usually uses the realm EXAMPLE.COM.

One realm is one scope of trust. Two different realms can trust each other through a cross-realm trust (episode 10), but within a single realm, all principals are managed by one KDC. This is the organizational unit you'll build in the episode 5 lab under the name EXAMPLE.COM.

#Principal: A Unique Identity

A principal is a unique identity within a realm — every authenticable entity has one. Its format is:

primary/instance@REALM

Note the service/host@REALM pattern: the instance (the part after the slash) distinguishes the same service on different hosts. Two services on different hosts won't have their tickets mixed up because their principals are different. This is a concept you'll keep encountering in episode 7 about service principals and keytabs.

#Keys & Symmetric Cryptography

Kerberos is entirely based on symmetric cryptography — one key for both encryption and decryption. There are two types of keys you need to distinguish:

• Long-term key (secret key) — a permanent key derived from a user's password, or randomly generated for services and stored in a keytab. This is what the KDC stores in its database.
• Session key — a temporary key created by the KDC for a specific communication session, valid briefly and discarded after use.

The long-term key is the "house key" that rarely changes; the session key is the "hotel room key" that's only valid during your stay. Modern supported encryption types: AES128 and AES256 (with HMAC-SHA1 and the SHA256/SHA384 variants). DES and 3DES are considered weak and not recommended — we'll cover the details in episode 11.

#Ticket, TGT, and Session Key

A ticket is an encrypted data block that serves as Kerberos's "access card." There are two types:

Every ticket contains the holder's identity, the target address, the validity period, and — most importantly — a session key copied in encrypted form. The ticket's recipient opens it with its own long-term key and extracts the session key for the subsequent conversation.

A keytab is a file storing a copy of a service's long-term key — like keeping a spare house key in a safe place. This file allows the service to authenticate without an interactive password prompt. We'll manage these in episode 7.

#Trust Model

Kerberos's security rests on a single assumption: the KDC is a trusted third party. All principals trust the KDC, and the KDC acts as the intermediary issuing proof of identity. This model is similar to a notary: the two parties don't know each other, but both trust the notary — and the notary issues a document recognized by both parties.

The trust relationship is built through a shared secret: every principal shares a long-term key only with its KDC. When the KDC issues a ticket encrypted with the service's key, the service knows the ticket is genuine because only the KDC (and the correct client) could have created it.

For different realms, there's transitive trust — if realm A trusts realm B and realm B trusts realm C, then A can reach C through B. This is facilitated by the special krbtgt/REALM1@REALM2 principal that acts as a "bridge" between realms, and it will be covered in depth in episode 10 on cross-realm authentication.

#Kerberos Terminology Table

Here's a summary of the terms you'll encounter repeatedly:

Keep this table — you'll come back to it every time you meet an unfamiliar term in later episodes. Tools like klist and kadmin.local will display these terms directly on screen.

#Conclusion

In this episode you've seen the complete map of Kerberos architecture: the three-head architecture (client, KDC with AS+TGS+database, and service server), realms as administrative boundaries with uppercase conventions, principals as unique identities, the difference between long-term keys and session keys, the two ticket types (TGT and service ticket), and the trust model with the KDC as the trusted third party.

Key points to take with you:

• Kerberos = client + KDC + service, and the KDC is the center of trust.
• Realms are always uppercase; principals follow the primary/instance@REALM format.
• TGT proves login, service tickets grant service access.
• Long-term keys are stored by the KDC, session keys are born with each session.
• Keytab is the service's key store that you'll manage in episode 7.

In the next episode, episode 3, we'll dissect the Kerberos authentication flow in depth — the three message exchanges (AS-REQ/AS-REP, TGS-REQ/TGS-REP, AP-REQ/AP-REP), the role of authenticators and timestamps, the replay cache, and SPNEGO as the wrapper in web applications. All the concepts in this episode will "come alive" when that flow runs. See you there!