Port 543: Klogin — The Kerberos Login Protocol

Port 543 carries klogin traffic: Kerberized remote login. Every time a Unix administrator in the late 1980s logged into a remote machine using Kerberos authentication instead of trusting the network with their password, that connection flowed through this port.

What Klogin Does

Klogin is the Kerberos-authenticated version of the Berkeley rlogin protocol. Where rlogin sends your username and password across the network in plaintext, readable by anyone with a packet sniffer, klogin uses Kerberos tickets to prove your identity cryptographically. No password ever crosses the wire.¹

The protocol works like this: before connecting to port 543, your client obtains a service ticket from the Kerberos Key Distribution Center (KDC). This ticket is encrypted with a key that only the target server and the KDC share. When you connect, you present this ticket. The server decrypts it, verifies it came from the KDC, and knows you are who you claim to be. Mutual authentication without mutual exposure.

The Problem It Solved

In the early 1980s, the rlogin protocol was the standard way Unix administrators accessed remote machines. It was convenient, fast, and completely insecure. RFC 1282, which documented the protocol in 1991, acknowledged the problem directly: "The rlogin protocol (as commonly implemented) allows a user to set up a class of trusted users and/or hosts which will be allowed to log on as himself without the entry of a password. While extremely convenient, this represents a weakening of security that has been successfully exploited in previous attacks on the Internet."²

The vulnerability was fundamental. Rlogin sent credentials in cleartext. Every character of your password flew across the network unencrypted. Anyone on the same network segment could capture it. Worse, the trust model relied on IP addresses and .rhosts files, both trivially spoofable.

This was the world that demanded Kerberos.

The History

Project Athena: Where It All Began

On May 27, 1983, MIT launched Project Athena, a collaboration with IBM and Digital Equipment Corporation that would eventually cost $100 million.³ The goal was to create a campus-wide distributed computing environment where students and faculty could access any workstation and reach their files, their email, their work.

The problem was authentication. How do you prove identity across a network of thousands of workstations and servers? How do you do it without trusting the network itself?

Jerome Saltzer, the Technical Director of Project Athena, along with Steve Miller, Clifford Neuman, and Jeffrey Schiller, set out to solve this problem.⁴ They built on the theoretical foundation laid by Roger Needham and Michael Schroeder, who in 1978 had published a paper describing how to establish secure authentication using symmetric-key cryptography and a trusted third party.⁵

The Three-Headed Dog

They named their system Kerberos, after Cerberus, the three-headed dog of Greek mythology who guards the gates of Hades.⁶ The name was deliberate. Cerberus allowed the dead to enter the underworld but prevented the living from passing. Kerberos would allow authenticated users to access services while keeping imposters out.

The three heads represent the three parties in every Kerberos authentication: the client seeking access, the service being accessed, and the Key Distribution Center that vouches for both. No authentication happens without all three participating.

Development began in 1983. Versions 1 through 3 never left MIT, serving as research implementations. The first production deployment came in September 1986. By January 1987, Kerberos was Project Athena's sole authentication system, serving 5,000 users, 650 workstations, and 65 servers.⁷

Kerberos Version 4, the first public release, came on January 24, 1989. Version 5, designed by John Kohl and Clifford Neuman, was published as RFC 1510 in 1993 and later updated as RFC 4120 in 2005.⁸

Port 543 Gets Its Assignment

Klogin was assigned port 543 by IANA as part of the well-known ports registry. Its companion, kshell (Kerberos remote shell), received port 544. These assignments gave the Kerberized versions of the Berkeley r-commands their own dedicated channels, separate from the insecure originals.⁹

Port 543 for klogin. Port 544 for kshell. Port 2105 for eklogin, the encrypted variant. A family of ports dedicated to the proposition that you should be able to prove who you are without telling everyone your secrets.

How Kerberos Authentication Works

The Kerberos authentication process unfolds in stages:

Initial Authentication: When you first log in, your password never travels to the Key Distribution Center. Instead, your client uses your password to derive a key locally, then requests a Ticket Granting Ticket (TGT) from the Authentication Server (AS). The AS sends back a TGT encrypted with the KDC's secret key and a session key encrypted with your password-derived key. Only you can decrypt the session key. Only the KDC can issue valid TGTs.

Getting a Service Ticket: When you want to access a service like klogin, your client presents the TGT to the Ticket Granting Service (TGS) and asks for a ticket to that specific service. The TGS verifies your TGT and issues a service ticket encrypted with a key shared only between the TGS and the target service.

Accessing the Service: Your client presents the service ticket to port 543. The klogin server decrypts it using its secret key, verifies the timestamp and authenticator, and knows with cryptographic certainty that you are who you claim to be. No password was transmitted. No credential was exposed.

The tickets have lifetimes, typically 24 hours. After that, you must re-authenticate. This limits the window of vulnerability if a ticket is somehow compromised.

Security Considerations

Klogin was a massive improvement over rlogin, but it was a product of its time:

Encryption was optional: The base klogin protocol authenticated the connection but did not encrypt the session itself. Your commands and their output could still be observed. For encrypted sessions, administrators used eklogin on port 2105.

The KDC is a single point of failure: If the Key Distribution Center is compromised, every authentication decision it has ever made becomes suspect. An attacker who controls the KDC can issue valid tickets for any user.

Kerberos Version 4 had cryptographic limitations: It used DES exclusively, which was later shown to be too weak. Version 5 added support for stronger encryption algorithms.

SSH replaced it: In 1995, Tatu Ylönen created SSH after witnessing a password-sniffing attack at Helsinki University of Technology.¹⁰ SSH provided built-in encryption, stronger authentication options, and a simpler deployment model. Over the following decade, SSH largely replaced klogin, kshell, rlogin, rsh, and Telnet for remote access.

Current Relevance

Port 543 still exists in the IANA registry. Kerberos itself remains ubiquitous. Windows Active Directory uses Kerberos as its default authentication protocol. Single sign-on systems across enterprises depend on it. The concepts pioneered at Project Athena, ticket-based authentication, trusted third parties, cryptographic proof of identity, are foundational to modern network security.

But klogin specifically? It is a legacy protocol. SSH won the remote access war. You are unlikely to encounter port 543 in production today unless you are maintaining ancient Unix systems or studying the history of network authentication.

The Port 543 Family

Port 543 does not stand alone: