Abstract:

This document tries to explain the basics of the Kerberos authentication system for open networks along with the motivations for its development. It describes the Kerberos system as developed in the MIT as a part of the ATHENA project.

TABLE OF CONTENTS

• INTRODUCTION
• What is Kerberos?
• Why Kerberos? (or problems with open network systems)
  
• HOW DOES "KERBEROS" WORK?
• "KERBEROS" IN DETAIL

Introduction

What is Kerberos?
Kerberos is the name of the three-headed dog that is said to guard the gates of hell, according to Greek mythology. In our world of computing, Kerberos is the name of a trusted third party authentication service developed at the MIT.

Why Kerberos? (Or problems with open network systems)
In non-networked (read personal) computing environments, information and resource security is assured by physically securing the computer. In time-shared environments, the resources are protected and access rights controlled by the operating system. Access rights are assigned to users, and, all that the operating system has to do is, to identify the user. This is done when the user logs in. However, in open network systems, where users may require services from many different computers, the problem is of a different kind. Requests must be honored from outside hosts, (hosts not under organizational control) and, the problem lies in the authentication of these hosts.

The system must satisfy the following constraints:
· It must be secure. A hacker should not find the authentication system as the weak link. Someone watching the network should not be able to "Hijack" the session.
· It must be reliable. As access to many services depend on the authentication service, if it is not reliable, then the system as a whole will not be reliable.
· It should be transparent. The user should not be aware of the numerous protocols and security measures being implemented with each service request.
· It should be scalable. It should be possible to expand the range of services depending on this third party authentication.

The Kerberos authentication service attempts to meet all of the above constraints. As far as the user is concerned, all that s/he does is log on as usual. This initial identification is sufficient proof of the user"s identity. The security of Kerberos lies in the security of several authentication servers but not on the system from which users log in, nor on the security of the end servers that will be used. Kerberos provides a way for properly authenticated users to prove their credentials to remote servers scattered across the network.

How does "Kerberos" work?

Kerberos is a trusted third-party authentication service. It is trusted in the sense that each of its clients trusts Kerberos" judgement as to the identity of the other. Before proceeding with the details of the authentication system, the notations that will be used throughout will be introduced. By "user" we imply the human being who uses a program or requests a service. By "client" we mean the program that the "user" is running that may request a service from another machine. This other machine that provides the service is known as the "server".

Kerberos keeps a database of its clients and their private keys. This private key is a large number known only to Kerberos and the client it belongs to. In the case that the client is a user, this private key is an encrypted password. Network services wishing to use authentication register with Kerberos and so do users wishing to use those services. The private keys are negotiated during this registration procedure.

As Kerberos is aware of the private keys of its clients, it can create messages that assure one client that the other is really what it claims to be. In addition, once this authentication is done and the session is established between two parties, Kerberos creates session keys that are given only to the two clients and no one else. This session key is used to encrypt the messages between the two parties.

How do we authenticate ourselves in real life? Typically we use identity cards issued by a responsible authority that carries our photograph and other information about ourselves that is, taken together deemed non copiable. This means that the issuing authority has associated an "identity" to a physical entity namely ourself. This identity card may contain restrictions on what we are allowed to do; for instance the person may be required to wear corrective lenses and so on. Some restrictions are implicit: one may not drink before a particular age. Finally the identification has a limited lifetime and this is represented by the expiry date on the card.

But this proof of identity is contingent upon a number of details. First, the card may not be tampered with. Second, the person performing the authentication must accept and recognize the authority issuing the card. If for example, a card which I obtain from my neighbor that states my identity, will not be acceptable proof of identity by any authority for the simple reason that my neighbor is not recognized by the authority currently authenticating me. Other concerns include the condition that the card is not stolen, or that the person being authenticated hasn"t changed in appearance and so on.

Kerberos works basically in the same way. When a user on a network is attempting to use a network service; the service requires assurance that the client is actually who s/he says s/he is. To this end, the user presents the service with an ID card issued by Kerberos. This ID is known as the "ticket" which is issued by the Kerberos "Key Distribution Service" (KDC). The service then examines the ticket to verify the identity of the user, and, if everything checks out, the user is accepted. This ticket must be such; it unequivocally identifies the user. In addition, there must be safeguards against the ticket being stolen and used later by an unauthorized person.

"Kerberos" in Detail

As mentioned earlier, Kerberos requires both the client and the server to have their keys registered with the KDC. The user"s key is derived from the password. The key for the service is randomly selected, as no user is required or available to type in the password. Let us assume for the purpose of explanation that I would like to talk to the ftp server in my organization this is what I would do:

• I send a message to the KDC: "I, Nilesh, would like to talk to the ftp server"
  
  
• When the KDC receives this message, it makes two copies of a brand new key known as the session key which will be used in the direct exchange between the ftp server and myself
  
  
• The KDC puts one of the session key in a "box" (an encrypted message in this case… this makes the explanation simpler) along with a message containing the ftp server"s name and locks it with my private key. Recall that the "box" is in reality just an encrypted message and the session key is a randomly generated large number. If this "box" returned to me with only the session key I would be unsure of whether it actually came from the KDC. But by locking the "box" (i.e. encrypting the message) with my own private key, I am assured that the "box" and its contents came from the KDC and hence can be trusted. And since the message contains the ftp server"s name, I can be doubly assured that the decryption of my message to the KDC was successful.
  
  
• The KDC puts the second copy of the session key into a second "box" along with a message that contains my name and locks it with the ftp server"s private key.
  
  
• The KDC then return both the boxes to me.
  
  
• I unlock my "box" with my private key and extract the session key. The second "box" cannot be opened by me since I do not have the ftp server"s private key.
  
  
• I put a message with the current time into a new "box" and lock it with the session key and send this and the second "box" I received to the ftp server.
  
  
• The ftp server opens the "box" locked with its own private key and extracts the session key and the message with my name from it and uses the session key to unlock the other "box" and extract the message with the current time on it. This will demonstrate my identity to the server. The time stamp, is the current time included in the "box" that I send to the ftp server to prevent someone from copying the "box" no.2 and sending it again thus using it to impersonate the user later. (Incidentally this is known as a "replay attack"). Because clocks do not always work in perfect synchronism a leeway of 5 minutes between the timestamp and the current time on the ftp server (both ways… i.e. 5 minutes early or 5 minutes later) is usually given. To prevent the possibility of someone reusing this ticket within this leeway time, the service maintains a list of recently sent "boxes" thus if two boxes are sent by the same person or IP address, the request received later is rejected as a replay attack! In Kerberos terms, the "box" no 2 is called as the "ticket" and the "box" no 3 is known as the "Authenticator". The authenticator typically contains more information than mentioned. For example there is a checksum, to verify that the message sent was correctly received without any modification or error. There may also be another encryption key for privacy in future communications. Once the service is able to decrypt my message, it is assured that I am who I claim to be and, the session is started.

Sometimes the user may want to be sure of the identity of the service (for example in online transactions… I certainly would like to be sure I am dealing with a genuine dealer). To do so, the service takes the time stamp sent by the user, adds a one to it, puts it into another "box" locks it with the session key and returns it to the user. (Clearly mutual authentication has to with modifying the contents of "box" 3 rather than simply returning the "box" itself).

The exchange as described above is used every time a user needs to contact a service and each time the user has to enter the password (to unlock "box" 1 for the session key). This would become a little tedious… imagine having to type your password in every time you had to check your email from the mail server. One way around this is to cache the key derived from the password. But this is dangerous, since with this key, an attacker could impersonate the user at any time until the password is next changed.

Kerberos has an elegant solution to this problem; it splits the functionality of the KDC into two parts: the authentication server (AS) and the Ticket Granting Sever (TGS). The TGS is logically different from the AS, although, usually both reside on the same machine. The AS is used solely for issuing tickets for the TGS. The user must enter a password and then s/he receives in exchange a Ticket Granting Ticket (TGT) and an associated session key. That completes the user interaction with the AS.

Thereafter, whenever the user wishes to get a ticket for a specific service, such as the mail or the ftp server for example, s/he uses the TGT to obtain the ticket for the service from the TGS. The user is not required to type in the password again, since the user and the KDC already share the session key that came with the TGT. Therefor the user simply constructs the Authenticator described earlier and hands the TGT and the authenticator to the TGS, encrypted of course by the session key. This will verify the user"s identity to the TGS and the TGS then grants him/her the ticket for the service.

The TGT is valid only for a fairly short period, of upto 8 hours. Afterward the TGT is not usable by anyone, including the user. The user has to login again. This is hardly an inconvenience, considering the enormous advantages that such a system offers.

All this seems like a lot of work, but the user does not see any of it. The only interaction s/he has with the Kerberos authentication system, is when s/he logs on. After this initial login, the TGT is granted and Kerberos protocols manage the task of negotiating with the TGS for other services. This is transparent; the user has no idea of the protocols being run in the background. In other words, for the user, this behaves like a regular system, but it saves the system administrators a lot of sleepless nights.