Kerberos
Introduction
Kerberos is an authentication protocol, which
allows workstation users to access network
resources in a secure way. It has been created by
the Massachusetts Institute of Technology, where
it is now freely available. Strong cryptography is
used, so that communication is possible through
an insecure network connection like the internet.
The name Kerberos comes from the three-headed
dog guarding the entrance to Hades in Greek
Mythology. For keeping security at a maximum
level, the Kerberos concept involves three servers:



The Authentication Server (AS) provides the first session key and the ticket
needed for accessing the TGS. The user has to authenticate once per session.
The Ticket-Granting Server (TGS) generates the second session key and the
ticket for communication with Hades. The user has to get a ticket every time
he would like to access a new server.
Hades is the server our fictional user plans to access to get some secret
services hidden for all other users.
The whole procedure consists of sending encrypted packages to servers and getting
answers containing new encrypted information. These steps can seem very complex,
so we first introduce you to our naming system:
C:
T:
H:
S:
UH:
t:
user secret key
TGS secret key
Hades secret key
session key
session key for communication between the user and Hades
actual timestamp
A secret key or a session key K may be used to encrypt data D. Then, we write the
key like a function: K(D).
Logging in
To start a session, the user types his username on a workstation. The workstation
sends name and address to the Authentication Server. Then, the Authentication Server
generates a package containing:
 The TGS ticket that only may be decrypted by the TGS server (using T) and
that holds the username and the session key S
 The session key S which is only going to be known by the user and the TGS
This package is then encrypted using U and sent as an answer to the workstation.
Because of the encryption, only the user is able to read the information. Other
network users don’t know the users secret key.
By receiving the TGS ticket, the user is logged on permanently. He may now access
different servers for several times.
Getting a server ticket
The user now tells the workstation that he would like to access Hades. The
workstation sends a package to the TGS, containing the TGS ticket from AS, the
server name and an encrypted timestamp. The TGS learns what server the user wants
to access and it decrypts the TGS ticket. Having the information within the ticket, the
TGS is now able to verify if the right user has sent the package and if this user has the
permission to access Hades. If everything is all right, the TGS answers with the two
following tickets:
 The UH session key paired with the server name in an S encrypted package.
This key may only be used for communication between the user and Hades.
 The server ticket for accessing Hades, providing the UH session key for letting
Hades encrypt the answer. This ticket is encrypted with H, the key only Hades
and TGS know.
Talking to the server
Now the user has the final server ticket, he sends it to Hades, accompanied by a new
timestamp, this time encrypted with the UH session key.
These timestamps have different functions: first, there is often a time limitation for
information exchange with such high security servers. With a timestamp, the server
may verify if a ticket has been generated on time. Second, it is even more difficult for
intruders to produce fake packages. For example to get a ticket from the TGS, an
intruder could steal the TGS ticket and send it to the TGS by himself. But in this case,
he would have to attach an encrypted timestamp, so he would first have to know the
session key S.
After getting an answer from Hades, the user has the permission to communicate with
it, encrypting all messages using UH.
If the user decides to access another server, for example Zeus, he needs a new ticket
from the TGS server. So he has to send [T(username, S), Zeus, S(t)] to the TGS and
he receives a ticket containing the new session key UZ. The user may access servers
all over the network in a secure way, without needing to send the password through
the network. The password has to be typed only once for the login.
For there are many Kerberos systems in our electronic world, the user may even
decide to access a server in a distant Kerberos system. He then has to ask the local
TGS for a ticket to access the distant TGS. From now on, the user can get tickets for
servers in the distant system directly by contacting the their TGS.
The Kerberos database
The Kerberos database manages all usernames and passwords. This is why the
security of its database is very important to Kerberos. It is only possible to access the
database using the Kerberos Database Management Service (KDMS), which is only
running on the computer with the master database. KDMS has two main tasks:
 Adding new users
 Changing user passwords
Every service provided by the KDMS is added to a protocol. There may be copies of
the Kerberos database all over the network, which can still be consulted, if the master
database collapses. These copies also help preventing an authentication bottle-neck.
For updating the slave databases, the master database calculates a checksum and
sends it, encrypted with the master database key, to the slave databases. The update is
only accepted, if the checksum is correct. Such updates are repeated regularly.
Questions about the Kerberos text:
1.
2.
3.
4.
5.
Why has an encrypted timestamp to be sent to get a ticket for Hades?
Imagine that anyone could manage to copy the package the user sent to the TGS.
If he would send this package to the TGS himself, what would the TGS send
back?
Can you describe what a user has to do, if he wants to contact another server?
Has the user’s password to be sent over the network?
Who had to kidnap Kerberos in Greek Mythology?
Answers:
1.
2.
3.
4.
5.
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
The TGS will not send anything until the encrypted timestamp lies in a valid
area. Even if a non logged in user could copy the sent packet from the logged in
user, there is no way to replace the timestamp with a more recent one, because
the non logged in user do not know the session key S.
If the user wants to contact another server, he has to send a package to the TGS
with the name of this server. The TGS generates and returns the new session
key to the user.
No, the password is only used in the users workstation and this for only a
fraction of time.
Herkules