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
- What is Kerberos?
- Why Kerberos? (or problems with open network
- HOW DOES "KERBEROS" WORK?
- "KERBEROS" IN DETAIL
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"
· 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
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
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
- I send a message to the KDC: "I, Nilesh, would like to talk to the
- 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
- 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
- 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"
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.