[Next] [Up] [Previous] [Index]


The Kerberos protocol, developed at the Massachussets Institute of Technology as part of Project Athena, is used to allow users to log in securely to computers which belong to a network.

This protocol assumes a network of computers, with one trusted computer or several verifying the identity of users to the computers to which they wish to log in, and supplying session keys so that the communications between the user and that computer can be encrypted.

Beginning a session with another computer under Kerberos requires the exchange of five messages:

It should be noted that while the timestamp on a ticket is intended to prevent replay attacks, it is valid for a somewhat extended period of time; the timestamp on an authenticator is only valid for a very brief amount of time, as authenticators are intended to be only used once.

In Kerberos version 4, when a ticket is sent to a user, it is also encrypted under the key known to the user at that stage: by the user's secret key in the second message, and by the session key for use with the security server in the fourth message. In version 5, this encipherment, not being seen as necessary for security, is omitted to save computer time. In version 4, the PCBC mode of DES is used for encryption; in version 5, CBC mode is used, and there is provision for use of block ciphers other than DES. Incidentally, PCBC mode was used without the transmission of an initialization vector: instead, the DES key, known to both parties, served as the initialization vector without being transmitted.

Also, in Version 5, the user's secret key is derived not only from the user's password, but from "salt", consisting of the user's location on the system and a timestamp added to the first message. This makes dictionary attacks on passwords somewhat more difficult, but they are still possible. For this reason, and because there might be applications where security is desired, but there is no secure initial contact for communicating a password secretly to the user or the server, there are several proposals to improve and extend Kerberos by adding steps involving the use of public-key cryptography to it.

The following diagram may make it clearer what is happening in Kerberos:

In the first line, the user machine, colored red, sends a message in the clear identifying itself (a red N) and the ticket-granting server it wants to talk to (its name being a blue N) to the Kerberos server.

The Kerberos server knows the permanent secret keys of all the users, shown by a red key beside it for the current user, and the permanent secret keys of all the ticket-granting servers, shown by a blue key beside it for the ticket-granting server requested.

It responds by providing the user with a session key for communicating with the ticket-granting server, shown as a purple key. This key was generated by the Kerberos server at random, so it knows that key also, shown by a purple key popping out of thin air beside the server. The purple key is in a red box, which means that it is encrypted with the user's secret key. The user also recieves a ticket, which is shown as another purple key, plus a red N, in a blue box: the red/blue session key, and the name of the user, encrypted in the ticket-granting server's key.

The user then presents the ticket to the ticket-granting server, along with an authenticator - a copy of its own name, and a timestamp, encrypted in the session key. As well, it sends a green N to the ticket-granting server, to identify the computer for which it wants a ticket. The ticket-granting server can unwrap the ticket, since the blue key is its own secret key, and finding the session key it can verify the authenticator. As well as knowing a secret key of its own, it knows the secret keys of the ordinary computers it serves, shown by a green key, the secret key of the computer requested in the example session.

The ticket-granting server then follows in the footsteps of the Kerberos server, generating a session key (this time shown as brown) for communications between the user and the computer the user had originally set out to use. This session key is given to the user enciphered in the purple session key given to the ticket-granting server and the user by the Kerberos server; it is also enclosed, with the user's name, in a ticket, which this time is in a green box, that is, enciphered in the permanent secret key of the computer the user wanted to use.

Finally, the user presents the ticket, and an authenticator, to the computational server, thus providing it with the brown key which will protect their productive interactive session.

Note that in the diagrams, the ticket is shown before the authenticator, since the recieving server needs to unwrap the ticket before it can verify the authenticator. Also, it might be noted that the use of a timestamp in the authenticator is what distinguishes and simplifies Kerberos; a more traditional protocol might have the server generate a random number, send it to the user, and the user then sends it back encrypted with the session key inside the ticket for authentication. The server can be requested to authenticate itself; in Kerberos, this is done by sending the timestamp plus one in the session key.

[Next] [Up] [Previous] [Index]

Table of Contents
Main Page