15.3 Kerberos – Introduction to Cryptography with Coding Theory, 3rd Edition

15.3 Kerberos

Kerberos (named for the three-headed dog that guarded the entrance to Hades) is a real-world implementation of a symmetric cryptography protocol whose purpose is to provide strong levels of authentication and security in key exchange between users in a network. Here we use the term users loosely, as a user might be an individual, or it might be a program requesting communication with another program. Kerberos grew out of a larger development project at MIT known as Project Athena. The purpose of Athena was to provide a huge network of computer workstations for the undergraduate student body at MIT, allowing students to access their files easily from anywhere on the network. As one might guess, such a development quickly raised questions about network security. In particular, communication across a public network such as Athena is very insecure. It is easily possible to observe data flowing across a network and look for interesting bits of information such as passwords and other types of information that one would wish to remain private. Kerberos was developed in order to address such security issues. In the following, we present the basic Kerberos model and describe what it is and what it attempts to do. For more thorough descriptions, see [Schneier].

Kerberos is based on a client/server architecture. A client is either a user or some software that has some task that it seeks to accomplish. For example, a client might wish to send email, print documents, or mount devices. Servers are larger entities whose function is to provide services to the clients. As an example, on the Internet and World Wide Web there is a concept of a domain name server (DNS), which provides names or addresses to clients such as email programs or Internet browsers.

The basic Kerberos model has the following participants:

  • Cliff: a client

  • Serge: a server

  • Trent: a trusted authority

  • Grant: a ticket-granting server

The trusted authority is also known as an authentication server. To begin, Cliff and Serge have no secret key information shared between them, and it is the purpose of Kerberos to give each of them information securely. A result of the Kerberos protocol is that Serge will have verified Cliff’s identity (he wouldn’t want to have a conversation with a fake Cliff, would he?), and a session key will be established.

The protocol, depicted in Figure 15.1, begins with Cliff requesting a ticket for ticket-granting service from Trent. Since Trent is the powerful trusted authority, he has a database of password information for all the clients (for this reason, Trent is also sometimes referred to as the Kerberos server). Trent returns a ticket that is encrypted with the client’s secret password information. Cliff would now like to use the service that Serge provides, but before he can do this, he must be allowed to talk to Serge. Cliff presents his ticket to Grant, the ticket-granting server. Grant takes this ticket, and if everything is OK (recall that the ticket has some information identifying Cliff), then Grant gives a new ticket to Cliff that will allow Cliff to make use of Serge’s service (and only Serge’s service; this ticket will not be valid with Sarah, a different server). Cliff now has a service ticket, which he can present to Serge. He sends Serge the service ticket as well as an authentication credential. Serge checks the ticket with the authentication credential to make sure it is valid. If this final exchange checks out, then Serge will provide the service to Cliff.

Figure 15.1 Kerberos.

The Kerberos protocol is a formal version of protocols we use in everyday life, where different entities are involved in authorizing different steps in a process; for example, using an ATM to get cash, then buying a ticket for a ride at a fair.

We now look at Kerberos in more detail. Kerberos makes use of a symmetric encryption algorithm. In the original release of Kerberos Version V, Kerberos used DES operating in CBC mode; however, Version V was later updated to allow for more general symmetric encryption algorithms.

  1. Cliff to Trent: Cliff sends a message to Trent that contains his name and the name of the ticket-granting server that he will use (in this case Grant).

  2. Trent to Cliff: Trent looks up Cliff’s name in his database. If he finds it, he generates a session key KCG that will be used between Cliff and Grant. Trent also has a secret key KC with which he can communicate with Cliff, so he uses this to encrypt the Cliff–Grant session key:


    In addition, Trent creates a Ticket Granting Ticket (TGT), which will allow Cliff to authenticate himself to Grant. This ticket is encrypted using Grant’s personal key KG (which Trent also has):

    TGT=Grant's nameeKG(Cliff's name, Cliff's Address, Timestamp1, KCG).

    Here is used to denote concatenation. The ticket that Cliff receives is the concatenation of these two subtickets:

    Ticket =TTGT.
  3. Cliff to Grant: Cliff can extract KCG using the key KC, which he shares with Trent. Using KCG, Cliff can now communicate securely with Grant. Cliff now creates an authenticator, which will consist of his name, his address, and a timestamp. He encrypts this using KCG to get

    AuthCG = eKCG(Cliff's name, Cliff's address, Timestamp2).

    Cliff now sends AuthCG as well as TGT to Grant so that Grant can administer a service ticket.

  4. Grant to Cliff: Grant now has AuthCG and TGT. Part of TGT was encrypted using Grant’s secret key, so Grant can extract this portion and can decrypt it. Thus he can recover Cliff’s name, Cliff’s address, Timestamp1, as well as KCG. Grant can now use KCG to decrypt AuthCG in order to verify the authenticity of Cliff’s request. That is, dKCGAuthCG will provide another copy of Cliff’s name, Cliff’s address, and a different timestamp. If the two versions of Cliff’s name and address match, and if Timestamp1 and Timestamp2 are sufficiently close to each other, then Grant will declare Cliff valid. Now that Cliff is approved by Grant, Grant will generate a session key KCS for Cliff to communicate with Serge and will also return a service ticket. Grant has a secret key KS, which he shares with Serge. The service ticket is

    ServTicket =eKSCliff's name, Cliff's address, Timestamp3, ExpirationTime, KCS.

    Here ExpirationTime is a quantity that describes the length of validity for this service ticket. The session key is encrypted using a session key between Cliff and Grant:


    Grant sends ServTicket and eKCGKCS to Cliff.

  5. Cliff to Serge: Cliff is now ready to start making use of Serge’s services. He starts by decrypting eKCGKCS in order to get the session key KCS that he will use while communicating with Serge. He creates an authenticator to use with Serge:

    AuthCS =eKCSCliff's name, Cliff's address, Timestamp4.

    Cliff now sends Serge AuthCS as well as ServTicket. Serge can decrypt ServTicket and extract from this the session key KCS that he is to use with Cliff. Using this session key, he can decrypt AuthCS and verify that Cliff is who he says he is, and that Timestamp4 is within ExpirationTime of Timestamp3. If Timestamp4 is not within ExpirationTime of Timestamp3, then Cliff’s ticket is stale and Serge rejects his request for service. Otherwise, Cliff and Serge may make use of KCS to perform their exchange.

Some comments about the different versions of Kerberos is appropriate. There are two main versions of Kerberos that one will find discussed in the literature: Kerberos Version IV, which was developed originally as part of MIT’s Project Athena; and Kerberos Version V, which was originally published in 1993 and was intended to address limitations and weaknesses in Version IV. Kerberos Version V was subsequently revised in 2005. We now describe some of the differences between the two versions.

Both Version IV and Version V follow the basic model that we have presented. Kerberos Version IV was designed to work with the computer networks associated with Project Athena, and consequently Version V was enhanced to support authentication and key exchange on larger networks. In particular, Kerberos Version IV was limited in its use to Internet Protocol version 4 (IPV4) addresses to specify clients and servers, while Kerberos Version V expanded the use of network protocols to support multiple IP addresses and addresses associated with other types of network protocols, such as the longer addresses of Internet Protocol version 6 (IPV6).

In terms of the cryptography that Kerberos uses, Version IV only allowed the use of the Data Encryption Standard (DES) with a nonstandard mode of operation known as Propagating Cipher Block Chaining (PCBC). Due to concerns about the security of PCBC mode, it was removed in Version V. Instead, Version V allows for the use of more general symmetric encryption algorithms, such as the use of AES, and incorporated integrity checking mechanisms directly into its use of the normal CBC mode of operation.

The tickets used in Kerberos Version IV had strict limits to their duration. In Kerberos Version V, the representation for the tickets was expanded to include start and stop times for the certificates. This allows for tickets in Version V to be specified with arbitrary durations. Additionally, the functionality of tickets in Version V was expanded. In Version V, it is possible for servers to forward, renew, and postdate tickets, while in Version IV authentication forwarding is not allowed. Overall, the changes made to Version V were intended to make Kerberos more secure and more flexible, allowing it to operate in more types of networks, support a broader array of cipher algorithms, and allow for it to address a broader set of application requirements.