Lecture 13: Network Protocols (Kerberos)

What this lecture covers

Following the previous lecture on TCP's weak, non-cryptographic security, this lecture introduces Kerberos, the first widely deployed protocol to use real cryptography for authenticating users and services across a network. Professor Zeldovich walks through MIT's own Athena/Kerberos design: a trusted Key Distribution Center (KDC) that shares a secret key with every user and service, and issues time-limited tickets so that a password never has to be sent over the network or kept in memory for long.

The lecture builds the protocol step by step: first the initial login exchange that gets a Ticket Granting Service (TGS) ticket, then how the TGS issues tickets for individual services, then how a client uses a ticket to talk to a service like a mail server. Along the way it highlights real design mistakes in Kerberos version 4 (conflating encryption with authentication, letting anyone offline-guess a password, reusing one key for both directions of a connection) and how Kerberos version 5 fixed them. After watching, you should be able to describe how a ticket and an authenticator work together, and why Kerberos was eventually replaced on the web by certificate-based systems (covered in the next lecture).

Key ideas

• Trust model: every principal (user or service) shares a secret key only with the KDC; the network itself is not trusted, but the KDC and each user's own workstation are.
• Ticket: an encrypted blob containing the client name, server name, client IP, timestamp, expiration, and a fresh shared key KCS, encrypted with the target service's key so only that service can read it.
• Authenticator: a short client-generated blob (client name, IP, timestamp) encrypted with the shared session key, used to prove the ticket's holder is the legitimate client and to resist replay.
• Two interfaces, one server: the Kerberos interface issues a TGS ticket using the user's long-term key KC; the TGS interface issues service tickets afterward, so KC (equivalent to the password) can be discarded from memory after login.
• Principals and naming: Kerberos maps string names ("principals") to keys but says nothing about authorization; each service decides what a given principal is allowed to do.
• Offline password guessing: because decrypting the initial reply is cheap, anyone could request a ticket for any username and try many passwords against the encrypted response offline; slower key-derivation functions and challenge-response schemes mitigate this.
• Reflection attacks: using the same key to encrypt both directions of a conversation lets an attacker bounce a client's own encrypted message back as if it came from the server; Kerberos 5 fixes this with separate keys per direction.
• Key compromise and recovery: if a service's key leaks, an attacker can decrypt its traffic and mint fake tickets for it, so recovering requires an out-of-band process to issue a new key, not just patching the service.

Walkthrough

The Kerberos trust model and architecture (1:01)

The lecture sets up the problem Kerberos was built to solve: authenticating users on workstations to many independent servers (file, mail, print) without trusting the network, as an alternative to IP-based schemes like rlogin. It introduces the KDC, which stores a shared key for every principal, and stresses that users must also trust their own workstation, since a compromised workstation can capture passwords or tickets directly.

Tickets, authenticators, and the initial login exchange (19:22)

This section defines the ticket and authenticator data structures and walks through the first protocol exchange: the client sends its name and the name of the service it wants (typically the TGS), and the KDC replies with a ticket encrypted for that service plus a fresh session key, the whole response encrypted with the client's key KC. The lecture explains why the shared key appears twice (once for the client, once wrapped inside the ticket for the service) and why splitting login into a Kerberos step and a TGS step lets the client discard KC quickly.

Weaknesses in Kerberos version 4 (23:27)

The lecture covers two real design flaws: offline password guessing, since anyone can request a ticket for any principal and try decrypting it with candidate passwords at high speed, and the assumption that successful decryption implies authenticity, when encryption alone does not guarantee a message wasn't tampered with. It also notes Kerberos 4's dependence on single DES, whose 56-bit keys are now cheap to brute-force.

Using the TGS to get service tickets (37:36)

Once a client has a TGS ticket, it can request tickets for other services without resupplying its password. The lecture details the fields in a ticket (client name, server name, client IP, timestamp, lifetime) and discusses why each one matters, including the now-outdated reliance on IP address as a defense against ticket theft, and why a stolen KCTGS is less damaging than a stolen KC because it is time-bounded.

Talking to a service, and the reflection attack (46:44)

The lecture shows a client presenting its ticket and an authenticator to a service such as a mail server, and the service decrypting the ticket with its own key to recover the shared session key. It then identifies the reflection attack that arises from using one key for both directions of traffic, and describes Kerberos 5's fix of negotiating separate keys per direction.

KDC availability, key compromise, and changing keys (56:53)

This part covers what happens if the KDC goes down (existing tickets keep working, since the KDC is off the critical path, and read-only replicas can serve logins), why the KDC is the highest-value target in the system, and why recovering from a compromised service requires generating a new key through an out-of-band process rather than just patching software. It also explains the two-step login process dial-up machines use to verify they really talked to the real KDC, unlike ordinary workstations.

Changing passwords and the value of Diffie-Hellman (1:10:05)

The lecture ends with the kpassword service, which only accepts tickets obtained directly from the Kerberos interface (not derived through the TGS), so a stolen ticket alone cannot be used to change a password. It closes with a subtle flaw: if an old password is ever disclosed, an attacker who recorded prior password-change traffic can decrypt a chain of subsequent password changes. Kerberos 5 fixes this using a brief sketch of Diffie-Hellman key exchange, which lets two parties agree on a fresh secret that cannot be derived just by observing their public exchange.

Before you watch

• Watch the previous lecture on TCP/IP security ("12. Network Security"), which motivates why network-level security needed real cryptography instead of guessable sequence numbers.
• Be comfortable with basic symmetric encryption (a shared key used to encrypt and decrypt).

Check your understanding

1. Why does splitting login into a Kerberos interface and a separate TGS interface reduce the risk of leaking a user's long-term key?
2. What information does a ticket contain, and why is it encrypted with the destination service's key rather than the client's key?
3. Explain the offline password-guessing weakness in the initial Kerberos exchange and one way to mitigate it.
4. Why is a reflection attack possible when the same key encrypts both directions of a connection, and how does Kerberos 5 prevent it?
5. Why does the kpassword service reject tickets obtained through the TGS interface?