Port 88: Kerberos — The Three-Headed Guardian

Port 88 carries Kerberos traffic. Every time you log into a Windows domain controller, every time Active Directory verifies your identity, every time single sign-on grants you access to another service without asking for your password again, that authentication flows through port 88.

Your password never crosses the wire. That is the miracle of Kerberos.

What Kerberos Does

Kerberos is a network authentication protocol that lets you prove who you are to a service without sending your password over the network. Instead of passwords, it uses tickets, cryptographic tokens issued by a trusted third party called the Key Distribution Center (KDC).¹

The protocol has three principals, like the three heads of its namesake:

1. The Client — You, requesting access to something
2. The Server — The service you want to access
3. The Key Distribution Center — The trusted authority that vouches for both sides

When you log in, the KDC issues you a Ticket Granting Ticket (TGT). Think of it as a backstage pass. When you want to access a service, you present your TGT to the KDC's Ticket Granting Service, which issues you a service ticket for that specific resource. You present that ticket to the service, and if everything checks out, you are in.²

No password ever transmitted. No credentials to intercept. Just cryptographic proof, validated by a trusted third party.

The Protocol

The dance happens in three exchanges:

Authentication Service Exchange: Your client contacts the KDC's Authentication Server. You prove you know your password by decrypting a message encrypted with a key derived from it. If successful, you receive a TGT encrypted with the KDC's secret key, plus a session key for talking to the Ticket Granting Service.

Ticket Granting Service Exchange: When you need access to a service, you send your TGT and an authenticator (proving you are the rightful owner) to the TGS. It responds with a service ticket encrypted with the target service's secret key, plus a new session key for communicating with that service.

Client/Server Exchange: You present the service ticket to the server. The server decrypts it with its own secret key, verifies the authenticator, and grants access. Optionally, the server can authenticate itself back to you, providing mutual authentication.³

All of this happens over port 88, typically using UDP for speed, though TCP is required for larger tickets.⁴

The History

In 1983, students at MIT could graduate with a science or engineering degree without ever having touched a computer. Despite digital computers being on campus since 1947, access was restricted by research funding. Students waited in line at all hours. There was no email, no file sharing, no standard anything.⁵

Project Athena changed that. Funded by Digital Equipment Corporation and IBM at approximately $100 million, MIT built a distributed computing environment connecting over 600 networked workstations across campus. But distributing computing meant distributing trust. How do you authenticate 10,000 users across hundreds of machines on a network where anyone could eavesdrop?⁶

Steve Miller and Clifford Neuman designed the answer, building on the Needham-Schroeder symmetric-key protocol published by Xerox PARC researchers in 1978.⁷ They fixed a critical flaw in the original protocol by adding timestamps to prevent replay attacks, and they named it after Kerberos, the three-headed dog that guards the gates of Hades in Greek mythology.⁸

A prototype went into production in September 1986. By January 1987, Kerberos was Project Athena's sole means of authentication, protecting 5,000 users, 650 workstations, and 65 servers.⁹

Jennifer G. Steiner, B. Clifford Neuman, and Jeffrey I. Schiller published "Kerberos: An Authentication Service for Open Network Systems" at the USENIX Conference in February 1988, introducing the protocol to the world.¹⁰

Versions 1 through 3 stayed inside MIT. Version 4 was released publicly on January 24, 1989. Version 5, designed by John Kohl and Clifford Neuman to address limitations discovered in real-world deployment, was published as RFC 1510 in 1993 and updated as RFC 4120 in 2005.¹¹

The Mythology

The protocol's namesake comes from Greek mythology. Cerberus (Greek: Kerberos) was the monstrous three-headed hound that guarded the gates of the Underworld, preventing the dead from escaping back to the world of the living.¹²

Son of Typhon, the deadliest monster in Greek mythology, and Echidna, the "mother of all monsters," Cerberus was depicted with three heads, a serpent for a tail, and snakes protruding from his body. His three heads were sometimes said to represent past, present, and future, or birth, youth, and old age.¹³

The metaphor is perfect. Like Cerberus greeting souls entering Hades but devouring any who try to escape, Kerberos welcomes authenticated users into the network but denies entry to those who cannot prove their identity. The three heads mirror the three parties in the protocol: client, server, and KDC.

In his twelfth labor, Heracles descended to the Underworld and wrestled Cerberus into submission without weapons, the only hero to ever capture the beast and return him safely to his post.¹⁴ The attackers who target Kerberos today are attempting something similar.

Security Considerations

Kerberos was revolutionary, but no system survives contact with determined attackers unchanged.

Golden Ticket Attack: If an attacker compromises the KRBTGT account hash from Active Directory, they can forge Ticket Granting Tickets for any user, including domain administrators. These forged "golden tickets" are valid for ten years by default and grant unrestricted access to all domain resources without ever contacting the domain controller.¹⁵

Kerberoasting: Any domain-joined user can request service tickets for accounts with Service Principal Names. Part of these tickets is encrypted with the service account's password hash, enabling offline brute-force attacks. Weak service account passwords become the attack surface.¹⁶

Silver Ticket Attack: Attackers with the NTLM hash for a service account can forge service tickets for that specific service, bypassing the KDC entirely for lateral movement.¹⁷

Pass-the-Ticket: Stolen Kerberos tickets can be reused from other machines, allowing attackers to impersonate users without knowing their passwords.

Time Sensitivity: Kerberos relies on synchronized clocks. By default, tickets are rejected if the time skew exceeds five minutes. This is a security feature preventing replay attacks, but it means time synchronization failures can lock users out entirely.¹⁸

Mitigations include using long, complex passwords for service accounts (25+ characters), regularly rotating the KRBTGT password (twice, with a 12-24 hour interval to invalidate forged tickets), implementing least-privilege access, and deploying detection for anomalous Kerberos activity.¹⁹

Modern Usage

Starting with Windows 2000, Microsoft made Kerberos the default authentication method for Windows domains. Every Active Directory environment in the world authenticates users over port 88.²⁰ When you join a corporate network and your email just works, your file shares just appear, your applications just recognize you, that is Kerberos providing single sign-on.

In 2007, MIT formed the Kerberos Consortium to foster continued development. The protocol remains under active development, with implementations available for Unix, Linux, macOS, and Windows.²¹

Port 88 is so critical to enterprise networks that it is one of the first ports checked when troubleshooting domain authentication. If port 88 is blocked between a client and domain controller, nothing works.

Related Ports