The kerberSim Project
Presented to Stefan Robila
Jerry Frederick
12/13/2004
frederickj1@mail.montclair.edu
Introduction
The following is an overview of Kerberos, a network authentication protocol. A
range of topics is covered, including terminology, basic flow, changes in Kerberos 5 from
Kerberos 4, security attacks, and attack prevention. A web based Kerberos simulation
tool accompanies this document. For the purposes of this research it is referred to as
kerberSim.
History
Kerberos originated at the Massachusetts Institute of Technology (MIT) in the
early 1980s. As computer models began to evolve from central system/dumb terminal to
client/server researchers at MIT realized there were a whole new set of issues to resolve.
Network users were now able to cause mischief, since they now controlled at least a
portion of the computer power. Administrators would need a way to limit and track user
actions. An MIT research project was created – named Athena. One of the most
important issues they found was the passing of passwords across a network in plaintext.
The old model had a dedicated line and a single logon – there was no threat of attackers
listening in.
The Kerberos protocol was the result of the work on project Athena. The earliest
versions were limited to internal use at MIT, mainly for testing and interpretation of the
results of development (and testing). Kerberos 4 was the first officially distributed
release. It was made available to the public in 1989. Kerberos 5 is the most current
version available.
Terminology
When discussing the Kerberos protocol, there are many terms that are Kerberosspecific and are probably not well known. Some of these terms are commonly referred to
by their acronyms.
Realms
For each installation of Kerberos, there is an associated realm. A realm defines the scope
of administrative control. It can be thought of as similar to a network domain. In fact,
the naming convention for a Kerberos realm is the domain name converted to uppercase.
There can be multiple realms in a Kerberos implementation, with trusts set up between
the realms. However, the resources from one are not automatically available to the other.
For security purposes, it may be required to login to each realm separately. This
discussion of Kerberos is limited to a one realm model.
Principals
Principals are associated with all entities within a Kerberos installation. These entities
include users, computers, and services (running on application servers). These principals
are unique across the installation, and each is associated with a long term key. A
password may be a long term key. A principal is made up of a username (for users) or a
service name (for services), followed by an instance (optional), and the realm name. The
name portion of a service principal is the name of the service it represents. Kerberos also
has many of it’s own principals, the most important being krbtgt. The optional instance
part is used to create special principals, such as those for an administrative user. An
example of a principal without the instance is kUser1@KERBERSIM.COM.
Key Distribution Center
The Key Distribution Center, or KDC, is the main piece of the Kerberos puzzle. Each
Kerberos realm must have at least one KDC. When using multiple KDCs, it is
imperative that that they be kept synchronized. Because some of the Kerberos
authentication relies on timestamps, KDCs that are out of sync may deny access when the
credentials are legitimate. Three logical components make up the KDC – a database
containing all of the principals and their keys, the Authentication Server, and the Ticket
Granting Server. These three components are most often run together as a single process.
Authentication Server (AS)
The Authentication Server receives requests to log in to the realm. No password is sent
to the AS, as it retrieves password information from the KDC database containing users
and passwords. The AS is responsible for creating a Ticket Granting Ticket and sending
it back to the client for decryption. Authentication occurs when the client successfully
decrypts the message returned by the AS.
Ticket Granting Server (TGS)
The TGS provides tickets to the client that are used to access services. The TGS receives
two pieces of information in a request from a client – a ticket request including the
service principal’s name, and the TGT previously returned by the AS. The TGS also
knows about the TGT key and uses it to authenticate the TGT received. If authenticated,
the TGS returns a service ticket to the client.
Ticket
A ticket is a confirmation of a user’s identity. A ticket contains a lot of data, including a
session key (an encryption key unique for each session), the user’s principal, a service
principal, the ticket valid start time and expiration, and a list of IP addresses the ticket
may be used from. The KDC itself provides the session key and the ticket expiration.
Ticket expirations created by the KDC are typically ten hours to one day after the valid
start time. This way, users do not have to repeatedly log on during the course of a
working day, and lengthy attacks using compromised tickets are limited.
Credential Cache
Tickets are stored differently dependent upon the specific implementation. The default is
to store them in a file, however this is very insecure. Both Microsoft and Apple
implementations of Kerberos use a credential cache that is memory based. This forces
the credential cache to be destroyed when the login session has concluded. A file based
credential cache looks as follows:
Ticket cache: FILE:/test/kerberSim
Default principal: kUser1@KERBERSIM.COM
Valid starting
12/10/04 01:23:12
12/10/04 01:23:12
Expires
12/10/04 11:23:12
12/10/04 11:23:12
Service principal
krbtgt/KERBERSIM.COM@KERBERSIM.COM
host/test.kerbersim.com@KERBERSIM.COM
The first service ticket entry is associated with the special Kerberos service krbtgt. This
entry is created when the TGT is first issued by the Authentication Server.
Process Flow
A client requests authentication by sending a request to the AS. This request
contains the username of the client (in plaintext), a timestamp from the client’s machine,
and the principal name of the TGS. Conventionally, this principal name is “krbtgt”, as
seen earlier in discussion of the Credential Cache. Also, this principal always contains an
instance. As an example, the TGS principal for this kerberSim project would be
krbtgt.KERBERSIM.COM@KERBERSIM.COM.
The KDC receives this message and verifies the existence of the principal (the
requesting principal) and checks to see that the timestamp is within a certain proximity of
the KDC’s time. This is typically set to five minutes. It is better to alert the user early
when this occurs and fail authentication quickly, rather that have problems show up with
authentication later in the process.
At this point the Authentication Server generates a session key. This is a
randomly generated key. The client shares this key with the Ticket Granting Server. This
ensures security later on when the client makes ticket requests to the TGS. The KDC
sends a message back that contains a copy of this session key and the identity (which has
been verified) of the client. Since the client should have knowledge of the user’s longterm key, it can decrypt the return message to get the session key. This is the key shared
with the TGS. Upon completion of this process, the client now has a session key and a
TGT. The combination of the session key and the Ticket Granting Ticket allow the client
to get tickets from the TGS for services – without re-entering a password at any other
time. At this point the TGT is encrypted with the TGS server key. The client cannot read
what is inside the TGT, and it is stored in the Credential Cache.
To access a service, the client sends a message to the Ticket Granting Server. This
message contains a request for service, a copy of the TGT, and an authenticator. This
authenticator is used to prevent replay attacks, and consists of a timestamp that has been
encrypted with the session key acquired earlier. Every request is checked for uniqueness.
The authenticator is used to thwart attackers from copying a ticket and replaying it.
When a ticket request is received, a new session key is created, and is shared by
the client and the application server that will be providing the service. When the client’s
copy of this new key is encrypted with the old session key (obtained earlier from the
Authentication Server), it ensures that only the valid client can read it. When the client
tries to access a service on the application server, the service ticket (along with the
session key) are the means to prove the client has been authenticated for that service.
Kerberos does not regulate the privileges a principal has to access a particular
service. A valid ticket does not give automatic access to a service, it merely blesses the
user’s credentials. The process with which a client sends a service ticket to an
application server is different for each server. The application server has the
responsibility for defining how a service ticket is sent.
Some changes from Kerberos 4 to Kerberos 5
Kerberos 5 is an improvement of Kerberos 4. As computer processes evolved,
there came a need for more functionality.

Kerberos 4 is limited to single DES encryption – at that time brute force attacks
were not feasible. Modern computer schemes could perform successful brute
force attacks against DES.

Kerberos 5 not only supports single DES but other encryption methodologies as
well. This even allows different encryptions to be used for a ticket, reply message,
and session key.

Double encryption was removed from the replies sent by the AS and TGS. The
ticket was encrypted, then put into a message, and that was encrypted as well.
Performance improved by removing the extra encryption, and the pieces
themselves were still encrypted and secure.

The function used to encrypt a user’s password (string2key) was changed to
accommodate the new support of other encryption schemes. Salt was also added
when encrypting passwords. Salt is data added before encryption to make it
stronger against brute force attacks.

Brute force attacks against Kerberos 4 could be done on the side against a copy of
a Ticket Granting Ticket. Kerberos 5 provides a pre-authentication feature to
make this more difficult. The KDC can be configured to pre-authenticate, which
forces a user to prove his identity before the user can receive a ticket from the
KDC.

The naming convention is changed a little, using a slash instead of a period to
separate the principal name from the instance:
krbtgt/KERBERSIM.COM@KERBERSIM.COM
Security Issues
Kerberos is a not a silver bullet that kills all attacks upon it. Kerberos is still
vulnerable in many ways.
If an attacker gains administrative access to a KDC, it must be assumed that the
Kerberos database has been compromised. This database contains all the users and their
secrets for the Kerberos realm. If there is a chance an attacker has admin rights, it should
be treated as if they do, as the consequences could be disastrous. It is very important to
physically secure the KDC machines. Assume that unauthorized physical access to these
machines means administrative access. KDC machines should most certainly be kept in a
locked area with limited access.
There is no way to stop an attack if user or admin passwords are compromised.
Strong policies regarding password lifetimes, password history, and password
requirements are essential to minimize this risk.
Another method of attack may be for a hacker to steal a user’s password in a less
secure area of the overall system, one that may send passwords around in plain text. If the
user is using the same password in both areas, and the hacker cracks the password there,
the hacker can then easily authenticate himself to the KDC – using an existing valid
username and password combination.
Kerberos is susceptible to replay attacks. An attacker listener can grab a ticket and
use the stolen ticket and replay it. Kerberos tries to stop this by the use of the valid IP
addresses that are entered into a ticket. Although it doesn’t stop an attacker from using
the valid machine to send the attack, it does provide some measure of protection. Another
way Kerberos attempts to prevent this type of attack is by the use of the authenticator that
is added to a ticket request.
Security problems within software is a problem everywhere – Kerberos is no
exception. Regularly checking for updates and a timely installation of them is the best
way to solve these types of problems.
kerberSim Demo
The kerberSim demo is written using VBScript and an Active Server Pages file
(.asp). All code runs on the web server, so it does not truly simulate Kerberos in a
client/server sort of way.
XML objects are used to represent some of the main components of Kerberos,
namely the database of passwords (gxDatabase), Ticket Granting Ticket(gxTGT), Ticket
Granting Server (gxTGS), and Credential Cache (gxCache). Even though they are
created globally, sometimes they are shown as being sent by being passed as parameters.
First, the Initialize button is clicked. This just performs the initial loads of the
XML objects, setting up the demo. A kerberSim transaction begins with the click of the
Log In button on the ASP page. The event is caught and a calls the GetTGT function. The
objective is to get a TGT from the KDC. The nodes in gxDatabase are looped through
until a Principal is found with a name attribute that matches the one entered by the user.
This simulates what the Authentication Server does. When a match is found, it gets the
value of the key attribute. This contains the encrypted long term key for that user.
CreateTGT is then called, passing this key. CreateTGT creates a node containing a ticket
key and a session key. This node is added to gxTGT, and an entry is made to gxCache.
If the return from GetTGT is successful DecryptTGT is called, passing the
password entered by the user. The value for ticketKey is extracted from gxTGT.
Simulation of Kerberos decryption of the ticketKey consists of reversing the ticketKey
and then comparing it to the password. If they are equal, DecryptTGT returns success,
and a success message is returned to the web page. At this point the user has a valid
TGT, and an entry for the krbtgt principal has been added to the Credential Cache
(gxCache).
Next, the user clicks the Call Service button to request access to a service. The
principal name is grabbed from the Session object “Principal”. This was set earlier in the
logon process. AccessService is called, passing this principal and the TGT.
AccessService merely passes these parameters on to GetTicket. AccessService is really
obsolete – the logic evolved, and it really no longer is necessary, but there was no sense
in making last minute changes in the development process for something that really does
no harm. GetTicket gets the sessionKey out of gxTGT and passes that to DecryptTicket.
DecryptTicket gets the sessionKey from the TicketGrantingServer, reverses it, and
compares it to the passed in key retrieved from the Ticket Granting Ticket. If they are
equal, it returns success to GetTicket, and a service ticket entry is made to gxCache,
using the principal passed in. At this point, a success message is displayed to the user,
and they essentially have a valid ticket (although this demo does not have an object that
represents a ticket). This is the end of the demo – if the demo were further developed, the
next step would be to pass this ticket to a representation of a service running on an app
server.
A simplified representation of some of the Kerberos processes is shown in
kerberSim. Further development would surely include actually accessing a service, and
much clean up work – not much effort was put into standard coding practices, such as
deletion of objects after use. The focus was on getting the simulation to work properly,
not create production worthy code.
BIBLIOGRAPHY
Garman, Jason. (2003). Kerberos: The Definitive Guide. O’Reilly and Associates, Inc.
http://web.mit.edu/kerberos
http://www.stanford.edu/~torg/kerberos-overview.html
http://nii.isi.edu/publications/kerberos-neuman-tso.html
http://gost.isi.edu/brian/security/kerberos.html