How the Kerberos Protocol Works

Kerberos is a system that uses electronic tickets to authenticate a user to a server. A ticket, which is good only for a single server and a single user during a certain period of time, is an encrypted message containing the name of the user and server, the user's network address, a time stamp, and a session key. Once the user gets this ticket, he or she can use it to access the server as many times as desired until the ticket expires. The user cannot decrypt the ticket but can only present it to the server. Nobody listening in on the network can read or modify the ticket as it passes through the network without detection or invalidation.

The Kerberos protocol involves two servers, the Kerberos Authentication Server and one or more TGSes (Ticket-Granting Servers). The steps involved in the Kerberos process are as follows.

1 To obtain a ticket to a particular target server, the user first requests from the Kerberos Authentication Server a ticket to the Kerberos TGS. This request takes the form of a message containing the user's name and the name of his or her TGS (there can be several).

2 The Authentication Server looks up the user in its database and then generates a session key to be used between the user and the TGS. Kerberos encrypts this session key using the user's secret key (a one-way hash of the user's password). Then it creates a TGT (ticket-granting ticket) for the user to present to the TGS and encrypts the TGT using the TGS's secret key (which is known only to the Authentication Server and the TGS). The Authentication Server sends both of these encrypted messages back to the user.

3 The user decrypts the first message and recovers the session key. Next, the user creates an authenticator consisting of his or her name and address and a time stamp, all encrypted with the session key just generated by the Kerberos Authentication Server.

The user then sends a request to the TGS for a ticket to a particular target server. This request contains the name of the server, the TGT received from Kerberos (which is already encrypted with the TGS's secret key), and the encrypted authenticator.

4 The TGS decrypts the TGT with its secret key and then uses the session key included in the TGT to decrypt the authenticator. It compares the information in the authenticator with the information in the ticket, the user's network address with the address the request was sent from, and the time stamp with the current time. If everything matches, it allows the request to proceed.

The TGS creates a new session key for the user and target server and incorporates this key into a valid ticket for the user to present to the server. This ticket also contains the user's name, network address, a time stamp, and an expiration time for the ticket--all encrypted with the target server's secret key--and the name of the server. The TGS also encrypts the new user-target session key using the session key shared by the user and the TGS. It sends both messages to the user.

5 The user decrypts the message and extracts the session key for use with the target server. The user is now ready to authenticate himself or herself to the server. He or she creates a new authenticator encrypted with the user-target session key that the TGS generated. To request access to the target server, the user sends along the ticket received from Kerberos (which is already encrypted with the target server's secret key) and the encrypted authenticator.

Because this authenticator contains plaintext encrypted with the session key, it proves that the sender knows the key. Just as important, encrypting the time of day prevents an eavesdropper who records both the ticket and the authenticator from replaying them later.

6 The target server decrypts and checks the ticket and the authenticator, also checking the user's address and the time stamp. If everything checks out, the server now knows the user is who he or she claims to be, and the two share an encryption key that they can use for secure communication. (Since only the user and the server share this key, they can assume that a recent message encrypted in that key originated with the other party.)

7 For those applications that require mutual authentication, the server sends the user a message consisting of the time stamp plus 1, encrypted with the session key. This serves as proof to the user that the server actually knew its secret key and was able to decrypt the ticket and the authenticator.

Editor's note: This text box was adapted from Applied Cryptography: Protocols, Algorithms, and Source Code in C by Bruce Schneier (Wiley, 1993).