Box 5.7
Kerberos

The Kerberos authentication system was developed at the Massachusetts Institute of Technology (MIT) in about 1985 as part of MIT’s Project Athena.¹ A Kerberos system consists of three parties: (1) a client, which attempts to authenticate itself to (2) a server and (3) a key distribution center (KDC), also known as a Kerberos server, which acts as an intermediary for the authentication.

Every Kerberos “principal” (either client or server) has a secret key known both by the principal and the KDC. Most Kerberos systems emulate a traditional password-based authentication system inasmuch as the human end user knows a secret password. However, unlike a traditional password-based authentication system, this password is never transmitted over a network and is therefore not easily stolen by eavesdropping. When used, this password is hashed into a secret key that is used to complete the Kerberos protocol.

When a client wishes to make use of a server, it queries the KDC for a “ticket” for the server. The ticket contains the identity of the client along with a time stamp and validity period. This ticket is encrypted by the KDC so that only the server can decrypt it. Among the information encrypted into the ticket is a randomly generated “session” key. The ticket and the session key are then provided to the client by way of a Ticket-Granting Ticket service.

The Ticket-Granting Ticket service is a Kerberos service in which the KDC is also the server. In general, a ticket for the Ticket-Granting Ticket service is obtained at log-in time. Additional tickets are then obtained for other services from the KDC as needed. These additional tickets, encrypted in the session key of the Ticket-Granting Ticket instead of the client’s password, are sent by the KDC to the client. This permits the Kerberos system to obtain as many tickets as are necessary without the client’s secret key (password) needing to be kept in memory on the client’s workstation (computer).

A client’s secret key, as mentioned earlier, is typically known to the client as a password, which is hashed into the key when needed. Servers store their secret key (needed to decrypt incoming tickets to obtain the stored session key) somewhere on the server, typically in a file.

Kerberos provides for clients to authenticate themselves to servers and for servers to be authenticated to clients. At the end of a successful authentication transaction, the session key created by the KDC and stored in the ticket is known to both the client and the server. This key can then be used to provide integrity protection for information sent between client and server and for the encryption (confidentiality) of information transfer as well.

Kerberos is an online system. The KDC is required to be involved in most transactions.² A ticket is typically issued with a lifetime measured in hours.³ Short ticket lifetime simplifies the revocation problem. If an entity’s key is compromised, all that needs to be done is to change that key in the KDC (and on the server if a server key is compromised). The use of symmetric algorithms means that Kerberos computations are much faster than the equivalent public key operations.

Kerberos still relies on the limited human storage capacity for passwords. It also relies on the user’s computer for computational ability, which means that it must be trusted by the user.

Recent work on the Kerberos protocol introduces the use of public key encryption into the initial Ticket Granting Ticket (log-in) transaction. This means that only clients’ public keys need to be stored by the KDC, reducing the amount of secret information that needs to be protected by the KDC.

---

¹For more information on Project Athena, see <http://Web.mit.edu/olh/Welcome/intro.html>.

²But this is not true for all transactions. Once a ticket is obtained by a client for a particular service, that ticket can be reused for multiple transactions without further involvement of the KDC.

³In version 4 Kerberos, the maximum ticket lifetime was 21 hours. Version 5 lifts this restriction, but it is still a good idea to limit ticket lifetime.