-- --

Kerberos: An Authentication Service for Open Network Systems

Jennifer G. Steiner

Project Athena
Massachusetts Institute of Technology
Cambridge, MA 02139
steiner@ATHENA.MIT.EDU

Clifford Neuman†

Department of Computer Science, FR-35

University of Washington
Seattle, WA 98195
bcn@CS.WASHINGTON.EDU

Jeffrey I. Schiller

Project Athena
Massachusetts Institute of Technology
Cambridge, MA 02139
jis@ATHENA.MIT.EDU

Introduction logging in), and the protocol for mutual authenti-

This paper gives an overview of Kerberos, cation of a potential consumer and a potential
an authentication system designed by Miller and producer of a network service.
Neuman1 for open network computing environ- Kerberos requires a database of informa-
ments, and describes our experience using it at tion about its clients; Section 5 describes the data-
MIT’s Project Athena.2 In the first section of the base, its management, and the protocol for its
paper, we explain why a new authentication modification. Section 6 describes the Kerberos
model is needed for open networks, and what its interface to its users, applications programmers,
requirements are. The second section lists the and administrators. In Section 7, we describe
components of the Kerberos software and how the Project Athena Kerberos fits into the rest
describes how they interact in providing the of the Athena environment. We also describe the
authentication service. In Section 3, we describe interaction of different Kerberos authentication
the Kerberos naming scheme. domains, or realms; in our case, the relation
Section 4 presents the building blocks of between the Project Athena Kerberos and the
Kerberos authentication − the ticket and the Kerberos running at MIT’s Laboratory for Com-
authenticator. This leads to a discussion of the puter Science.
two authentication protocols: the initial authenti- In Section 8, we mention open issues and
cation of a user to Kerberos (analogous to problems as yet unsolved. The last section gives

† Clifford Neuman was a member of the Project Athena staff during the design and initial implementation phase of Ker-
beros.

January 12, 1988

-- --

-2-

the current status of Kerberos at Project Athena. machine. However, there is always only one
In the appendix, we describe in detail how Ker- definitive copy of the Kerberos database. The
beros is applied to a network file service to machine which houses this database is called the
authenticate users who wish to gain access to master machine, or just the master. Other
remote file systems. machines may possess read-only copies of the
Conventions. Throughout this paper we Kerberos database, and these are called slaves.
use terms that may be ambiguous, new to the
reader, or used differently elsewhere. Below we 1. Motivation
state our use of those terms. In a non-networked personal computing
User, Client, Server. By user, we mean a environment, resources and information can be
human being who uses a program or service. A protected by physically securing the personal
client also uses something, but is not necessarily computer. In a timesharing computing environ-
a person; it can be a program. Often network ment, the operating system protects users from
applications consist of two parts; one program one another and controls resources. In order to
which runs on one machine and requests a remote determine what each user is able to read or
service, and another program which runs on the modify, it is necessary for the timesharing system
remote machine and performs that service. We to identify each user. This is accomplished when
call those the client side and server side of the the user logs in.
application, respectively. Often, a client will In a network of users requiring services
contact a server on behalf of a user. from many separate computers, there are three
Each entity that uses the Kerberos system, approaches one can take to access control: One
be it a user or a network server, is in one sense a can do nothing, relying on the machine to which
client, since it uses the Kerberos service. So to the user is logged in to prevent unauthorized
distinguish Kerberos clients from clients of other access; one can require the host to prove its iden-
services, we use the term principal to indicate tity, but trust the host’s word as to who the user
such an entity. Note that a Kerberos principal is; or one can require the user to prove her/his
can be either a user or a server. (We describe the identity for each required service.
naming of Kerberos principals in a later section.) In a closed environment where all the
Service vs. Server. We use service as an machines are under strict control, one can use the
abstract specification of some actions to be per- first approach. When the organization controls
formed. A process which performs those actions all the hosts communicating over the network,
is called a server . At a given time, there may be this is a reasonable approach.
several servers (usually running on different In a more open environment, one might
machines) performing a given service . For exam- selectively trust only those hosts under organiza-
ple, at Athena there is one BSD UNIX rlogin tional control. In this case, each host must be
server running on each of our timesharing required to prove its identity. The rlogin and rsh
machines. programs use this approach. In those protocols,
Key, Private Key, Password. Kerberos authentication is done by checking the Internet
uses private key encryption. Each Kerberos prin- address from which a connection has been esta-
cipal is assigned a large number, its private key, blished.
known only to that principal and Kerberos. In In the Athena environment, we must be
the case of a user, the private key is the result of a able to honor requests from hosts that are not
one-way function applied to the user’s password. under organizational control. Users have com-
We use key as shorthand for private key . plete control of their workstations: they can
Credentials. Unfortunately, this word has a reboot them, bring them up standalone, or even
special meaning for both the Sun Network File boot off their own tapes. As such, the third
System and the Kerberos system. We explicitly approach must be taken; the user must prove
state whether we mean NFS credentials or Ker- her/his identity for each desired service. The
beros credentials, otherwise the term is used in server must also prove its identity. It is not suffi-
the normal English language sense. cient to physically secure the host running a net-
work server; someone elsewhere on the network
Master and Slave. It is possible to run Ker-
may be masquerading as the given server.
beros authentication software on more than one
Our environment places several

January 12, 1988

-- --

-3-

requirements on an identification mechanism. Kent.4

First, it must be secure. Circumventing it must be
difficult enough that a potential attacker does not 2.1. What Does It Do?
find the authentication mechanism to be the weak Kerberos keeps a database of its clients and
link. Someone watching the network should not their private keys . The private key is a large
be able to obtain the information necessary to number known only to Kerberos and the client it
impersonate another user. Second, it must be reli- belongs to. In the case that the client is a user, it
able. Access to many services will depend on the is an encrypted password. Network services
authentication service. If it is not reliable, the requiring authentication register with Kerberos,
system of services as a whole will not be. Third, as do clients wishing to use those services. The
it should be transparent. Ideally, the user should private keys are negotiated at registration.
not be aware of authentication taking place.
Because Kerberos knows these private
Finally, it should be scalable. Many systems can
keys, it can create messages which convince one
communicate with Athena hosts. Not all of these
client that another is really who it claims to be.
will support our mechanism, but software should
not break if they did. Kerberos also generates temporary private keys,
called session keys , which are given to two
Kerberos is the result of our work to satisfy clients and no one else. A session key can be
the above requirements. When a user walks up to used to encrypt messages between two parties.
a workstation s/he ‘‘logs in’’. As far as the user
can tell, this initial identification is sufficient to Kerberos provides three distinct levels of
prove her/his identity to all the required network protection. The application programmer deter-
servers for the duration of the login session. The mines which is appropriate, according to the
security of Kerberos relies on the security of requirements of the application. For example,
several authentication servers, but not on the sys- some applications require only that authenticity
tem from which users log in, nor on the security be established at the initiation of a network con-
of the end servers that will be used. The authenti- nection, and can assume that further messages
from a given network address originate from the
cation server provides a properly authenticated
authenticated party. Our authenticated network
user with a way to prove her/his identity to
file system uses this level of security.
servers scattered across the network.
Other applications require authentication of
Authentication is a fundamental building
each message, but do not care whether the content
block for a secure networked environment. If, for
of the message is disclosed or not. For these,
example, a server knows for certain the identity
Kerberos provides safe messages. Yet a higher
of a client, it can decide whether to provide the
level of security is provided by private messages,
service, whether the user should be given special
where each message is not only authenticated, but
privileges, who should receive the bill for the ser-
also encrypted. Private messages are used, for
vice, and so forth. In other words, authorization
example, by the Kerberos server itself for send-
and accounting schemes can be built on top of the
ing passwords over the network.
authentication that Kerberos provides, resulting
in equivalent security to the lone personal com-
2.2. Software Components
puter or the timesharing system.
The Athena implementation comprises
2. What is Kerberos? several modules (see Figure 1). The Kerberos
applications library provides an interface for
Kerberos is a trusted third-party authentica-
application clients and application servers. It
tion service based on the model presented by
contains, among others, routines for creating or
Needham and Schroeder.3 It is trusted in the
sense that each of its clients believes Kerberos’ reading authentication requests, and the routines
judgement as to the identity of each of its other for creating safe or private messages.
clients to be accurate. Timestamps (large
numbers representing the current date and time)
have been added to the original model to aid in
the detection of replay. Replay occurs when a
message is stolen off the network and resent later.
For a more complete description of replay, and
other issues of authentication, see Voydock and

January 12, 1988

-- --

-4-

Kerberos applications library the database. The client side of the program may

encryption library be run on any machine on the network. The

database library server side, however, must run on the machine

database administration programs housing the Kerberos database in order to make

administration server changes to the database.

authentication server The authentication server (or Kerberos

db propagation software server), on the other hand, performs read-only

user programs operations on the Kerberos database, namely, the

applications authentication of principals, and generation of
Figure 1. Kerberos Software Components. session keys. Since this server does not modify
the Kerberos database, it may run on a machine
housing a read-only copy of the master Kerberos
Encryption in Kerberos is based on DES,
database.
the Data Encryption Standard.5 The encryption
library implements those routines. Several Database propagation software manages
methods of encryption are provided, with trade- replication of the Kerberos database. It is possi-
offs between speed and security. An extension to ble to have copies of the database on several dif-
the DES Cypher Block Chaining (CBC) mode, ferent machines, with a copy of the authentication
called the Propagating CBC mode, is also pro- server running on each machine. Each of these
vided. In CBC, an error is propagated only slave machines receives an update of the Ker-
through the current block of the cipher, whereas beros database from the master machine at given
in PCBC, the error is propagated throughout the intervals.
message. This renders the entire message useless Finally, there are end-user programs for
if an error occurs, rather than just a portion of it. logging in to Kerberos, changing a Kerberos
The encryption library is an independent module, password, and displaying or destroying Kerberos
and may be replaced with other DES implementa- tickets (tickets are explained later on).
tions or a different encryption library.
Another replaceable module is the database 3. Kerberos Names
management system. The current Athena imple- Part of authenticating an entity is naming it.
mentation of the database library uses ndbm, The process of authentication is the verification
although Ingres was originally used. Other data- that the client is the one named in a request.
base management libraries could be used as well. What does a name consist of? In Kerberos, both
The Kerberos database needs are straight- users and servers are named. As far as the
forward; a record is held for each principal, con- authentication server is concerned, they are
taining the name, private key, and expiration date equivalent. A name consists of a primary name,
of the principal, along with some administrative an instance, and a realm, expressed as
information. (The expiration date is the date after name.instance@realm (see Figure 2).
which an entry is no longer valid. It is usually set
to a few years into the future at registration.) bcn
Other user information, such as real name, treese.root
phone number, and so forth, is kept by another jis@LCS.MIT.EDU
server, the Hesiod nameserver.6 This way, sensi- rlogin.priam@ATHENA.MIT.EDU
tive information, namely passwords, can be han-
dled by Kerberos, using fairly high security Figure 2. Kerberos Names.
measures; while the non-sensitive information
kept by Hesiod is dealt with differently; it can, The primary name is the name of the user
for example, be sent unencrypted over the net- or the service. The instance is used to distinguish
work. among variations on the primary name. For
users, an instance may entail special privileges,
The Kerberos servers use the database
such as the ‘‘root’’ or ‘‘admin’’ instances. For
library, as do the tools for administering the data-
services in the Athena environment, the instance
base.
is usually the name of the machine on which the
The administration server (or KDBM server runs. For example, the rlogin service has
server) provides a read-write network interface to different instances on different hosts:

January 12, 1988

-- --

-5-

rlogin.priam is the rlogin server on the host server. A ticket also passes information that can
named priam. A Kerberos ticket is only good for be used to make sure that the person using the
a single named server. As such, a separate ticket ticket is the same person to which it was issued.
is required to gain access to different instances of The authenticator contains the additional informa-
the same service. The realm is the name of an tion which, when compared against that in the
administrative entity that maintains authentication ticket proves that the client presenting the ticket is
data. For example, different institutions may the same one to which the ticket was issued.
each have their own Kerberos machine, housing a A ticket is good for a single server and a
different database. They have different Kerberos single client. It contains the name of the server,
realms. (Realms are discussed further in section the name of the client, the Internet address of the
8.2.) client, a timestamp, a lifetime, and a random ses-
sion key. This information is encrypted using the
4. How It Works key of the server for which the ticket will be used.
This section describes the Kerberos authen- Once the ticket has been issued, it may be used
tication protocols. The following abbreviations multiple times by the named client to gain access
are used in the figures. to the named server, until the ticket expires. Note
that because the ticket is encrypted in the key of
c -> client the server, it is safe to allow the user to pass the
s -> server ticket on to the server without having to worry
addr -> client’s network address about the user modifying the ticket (see Figure 3).
life -> lifetime of ticket
tgs, TGS -> ticket-granting server
{s, c, addr, timestamp, life, Ks,c}Ks
Kerberos -> authentication server
KDBM -> administration server
Figure 3. A Kerberos Ticket.
Kx -> x’s private key
Kx,y -> session key for x and y Unlike the ticket, the authenticator can only
{abc}Kx -> abc encrypted in x’s key be used once. A new one must be generated each
Tx,y -> x’s ticket to use y time a client wants to use a service. This does not
Ax -> authenticator for x present a problem because the client is able to
WS -> workstation build the authenticator itself. An authenticator
contains the name of the client, the workstation’s
IP address, and the current workstation time. The
As mentioned above, the Kerberos authentication authenticator is encrypted in the session key that
model is based on the Needham and Schroeder is part of the ticket (see Figure 4).
key distribution protocol. When a user requests a
service, her/his identity must be established. To
do this, a ticket is presented to the server, along {c, addr, timestamp}Ks,c
with proof that the ticket was originally issued to
the user, not stolen. There are three phases to Figure 4. A Kerberos Authenticator.
authentication through Kerberos. In the first
phase, the user obtains credentials to be used to 4.2. Getting the Initial Ticket
request access to other services. In the second
When the user walks up to a workstation,
phase, the user requests authentication for a
only one piece of information can prove her/his
specific service. In the final phase, the user
identity: the user’s password. The initial
presents those credentials to the end server.
exchange with the authentication server is
designed to minimize the chance that the pass-
4.1. Credentials
word will be compromised, while at the same
There are two types of credentials used in time not allowing a user to properly authenticate
the Kerberos authentication model: tickets and her/himself without knowledge of that password.
authenticators. Both are based on private key The process of logging in appears to the user to
encryption, but they are encrypted using different be the same as logging in to a timesharing system.
keys. A ticket is used to securely pass the iden- Behind the scenes, though, it is quite different
tity of the person to whom the ticket was issued (see Figure 5).
between the authentication server and the end

January 12, 1988

-- --

-6-

4.3. Requesting a Service

c, tgs For the moment, let us pretend that the user

Client Kerberos already has a ticket for the desired server. In
order to gain access to the server, the application
builds an authenticator containing the client’s
name and IP address, and the current time. The
Client Kerberos authenticator is then encrypted in the session key
{Kc,tgs,{Tc,tgs} Ktgs}Kc that was received with the ticket for the server.
The client then sends the authenticator along with
the ticket to the server in a manner defined by the
Figure 5. Getting the Initial Ticket. individual application.
Once the authenticator and ticket have been
The user is prompted for her/his username.
received by the server, the server decrypts the
Once it has been entered, a request is sent to the
ticket, uses the session key included in the ticket
authentication server containing the user’s name
to decrypt the authenticator, compares the infor-
and the name of a special service known as the
mation in the ticket with that in the authenticator,
ticket-granting service .
the IP address from which the request was
The authentication server checks that it received, and the present time. If everything
knows about the client. If so, it generates a ran- matches, it allows the request to proceed (see Fig-
dom session key which will later be used between ure 6).
the client and the ticket-granting server. It then
creates a ticket for the ticket-granting server
which contains the client’s name, the name of the {Ac}Kc,s, {Tc,s}Ks
Client Server
ticket-granting server, the current time, a lifetime
for the ticket, the client’s IP address, and the ran-
dom session key just created. This is all Figure 6. Requesting a Service.
encrypted in a key known only to the ticket-
granting server and the authentication server. It is assumed that clocks are synchronized
The authentication server then sends the to within several minutes. If the time in the
ticket, along with a copy of the random session request is too far in the future or the past, the
key and some additional information, back to the server treats the request as an attempt to replay a
client. This response is encrypted in the client’s previous request. The server is also allowed to
private key, known only to Kerberos and the keep track of all past requests with timestamps
client, which is derived from the user’s password. that are still valid. In order to further foil replay
attacks, a request received with the same ticket
Once the response has been received by the and timestamp as one already received can be dis-
client, the user is asked for her/his password. The carded.
password is converted to a DES key and used to
decrypt the response from the authentication Finally, if the client specifies that it wants
server. The ticket and the session key, along with the server to prove its identity too, the server adds
some of the other information, are stored for one to the timestamp the client sent in the authen-
future use, and the user’s password and DES key ticator, encrypts the result in the session key, and
are erased from memory. sends the result back to the client (see Figure 7).

Once the exchange has been completed, the

workstation possesses information that it can use
Client Server
to prove the identity of its user for the lifetime of {timestamp + 1} Kc,s
the ticket-granting ticket. As long as the software
on the workstation had not been previously tam- Figure 7. Mutual Authentication.
pered with, no information exists that will allow
someone else to impersonate the user beyond the At the end of this exchange, the server is
life of the ticket. certain that, according to Kerberos, the client is
who it says it is. If mutual authentication occurs,
the client is also convinced that the server is
authentic. Moreover, the client and server share a

January 12, 1988

-- --

-7-

key which no one else knows, and can safely

assume that a reasonably recent message
encrypted in that key originated with the other
Kerberos TGS
party.
2 3
4.4. Getting Server Tickets 4
Recall that a ticket is only good for a single 1
server. As such, it is necessary to obtain a User/ 5
Server
separate ticket for each service the client wants to Client
use. Tickets for individual servers can be
obtained from the ticket-granting service. Since 1. Request for TGS ticket
the ticket-granting service is itself a service, it 2. Ticket for TGS
makes use of the service access protocol 3. Request for Server ticket
described in the previous section. 4. Ticket for Server
When a program requires a ticket that has 5. Request for service
not already been requested, it sends a request to
the ticket-granting server (see Figure 8). The Figure 9. Kerberos Authentication Protocols.
request contains the name of the server for which
a ticket is requested, along with the ticket-
5. The Kerberos Database
granting ticket and an authenticator built as
described in the previous section. Up to this point, we have discussed opera-
tions requiring read-only access to the Kerberos
database. These operations are performed by the
s,{Tc,tgs}Ktgs,{Ac}Kc,tgs
Client authentication service, which can run on both
TGS
master and slave machines (see Figure 10).

WS WS WS

Client TGS
{{Tc,s}Ks,Kc,s}Kc,tgs

Figure 8. Getting a Server Ticket.

The ticket-granting server then checks the

authenticator and ticket-granting ticket as
described above. If valid, the ticket-granting Slave Master
server generates a new random session key to be
used between the client and the new server. It
then builds a ticket for the new server containing Figure 10. Authentication Requests.
the client’s name, the server name, the current In this section, we discuss operations that
time, the client’s IP address and the new session require write access to the database. These
key it just generated. The lifetime of the new operations are performed by the administration
ticket is the minimum of the remaining life for the service, called the Kerberos Database Manage-
ticket-granting ticket and the default for the ser- ment Service (KDBM) . The current implementa-
vice. tion stipulates that changes may only be made to
The ticket-granting server then sends the the master Kerberos database; slave copies are
ticket, along with the session key and other infor- read-only. Therefore, the KDBM server may
mation, back to the client. This time, however, only run on the master Kerberos machine (see
the reply is encrypted in the session key that was Figure 11).
part of the ticket-granting ticket. This way, there
is no need for the user to enter her/his password
again. Figure 9 summarizes the authentication
protocols.

January 12, 1988

-- --

-8-

master Kerberos system). If the requester’s prin-

WS WS WS cipal name is found in this file, the request is per-
mitted, otherwise it is denied.
By convention, names with a NULL
instance (the default instance) do not appear in
the access control list file; instead, an admin
instance is used. Therefore, for a user to become
an administrator of Kerberos an admin instance
for that username must be created, and added to
the access control list. This convention allows an
Slave Master administrator to use a different password for Ker-
beros administration then s/he would use for nor-
mal login.
Figure 11. Administration Requests.
All requests to the KDBM program,
Note that, while authentication can still occur (on whether permitted or denied, are logged.
slaves), administration requests cannot be ser-
viced if the master machine is down. In our 5.2. The kadmin and kpasswd Programs
experience, this has not presented a problem, as
Administrators of Kerberos use the kadmin
administration requests are infrequent.
program to add principals to the database, or
The KDBM handles requests from users to change the passwords of existing principals. An
change their passwords. The client side of this administrator is required to enter the password for
program, which sends requests to the KDBM over their admin instance name when they invoke the
the network, is the kpasswd program. The kadmin program. This password is used to fetch a
KDBM also accepts requests from Kerberos ticket for the KDBM server (see Figure 12).
administrators, who may add principals to the
database, as well as change passwords for exist-
ing principals. The client side of the administra-
tion program, which also sends requests to the Kerberos KDBM
KDBM over the network, is the kadmin program. 2
3
5.1. The KDBM Server
1
The KDBM server accepts requests to add User/
principals to the database or change the pass- Admin
words for existing principals. This service is
unique in that the ticket-granting service will not
1. Request for KDBM ticket
issue tickets for it. Instead, the authentication ser-
2. Ticket for KDBM
vice itself must be used (the same service that is
3. kadmin or kpasswd request
used to get a ticket-granting ticket). The purpose
of this is to require the user to enter a password.
Figure 12. Kerberos Administration Protocol.
If this were not so, then if a user left her/his
workstation unattended, a passerby could walk up Users may change their Kerberos pass-
and change her/his password for them, something words using the kpasswd program. They are
which should be prevented. Likewise, if an required to enter their old password when they
administrator left her/his workstation unguarded, invoke the program. This password is used to
a passerby could change any password in the sys- fetch a ticket for the KDBM server.
tem.
When the KDBM server receives a request, 5.3. Database Replication
it authorizes it by comparing the authenticated Each Kerberos realm has a master Ker-
principal name of the requester of the change to beros machine, which houses the master copy of
the principal name of the target of the request. If the authentication database. It is possible
they are the same, the request is permitted. If (although not necessary) to have additional,
they are not the same, the KDBM server consults read-only copies of the database on slave
an access control list (stored in a file on the machines elsewhere in the system. The

January 12, 1988

-- --

-9-

advantages of having multiple copies of the data- 6. Kerberos From the Outside Looking In
base are those usually cited for replication: The section will describe Kerberos from
higher availability and better performance. If the the practical point of view, first as seen by the
master machine is down, authentication can still user, then from the application programmer’s
be achieved on one of the slave machines. The viewpoint, and finally, through the tasks of the
ability to perform authentication on any one of Kerberos administrator.
several machines reduces the probability of a
bottleneck at the master machine. 6.1. User’s Eye View
Keeping multiple copies of the database If all goes well, the user will hardly notice
introduces the problem of data consistency. We that Kerberos is present. In our UNIX implemen-
have found that very simple methods suffice for tation, the ticket-granting ticket is obtained from
dealing with inconsistency. The master database Kerberos as part of the login process. The
is dumped every hour. The database is sent, in its changing of a user’s Kerberos password is part of
entirety, to the slave machines, which then update the passwd program. And Kerberos tickets are
their own databases. A program on the master automatically destroyed when a user logs out.
host, called kprop, sends the update to a peer pro-
gram, called kpropd, running on each of the slave If the user’s login session lasts longer than
machines (see Figure 13). First kprop sends a the lifetime of the ticket-granting ticket (currently
checksum of the new database it is about to send. 8 hours), the user will notice Kerberos’ presence
The checksum is encrypted in the Kerberos mas- because the next time a Kerberos-authenticated
ter database key, which both the master and slave application is executed, it will fail. The Kerberos
Kerberos machines possess. The data is then ticket for it will have expired. At that point, the
transferred over the network to the kpropd on the user can run the kinit program to obtain a new
slave machine. The slave propagation server cal- ticket for the ticket-granting server. As when log-
culates a checksum of the data it has received, ging in, a password must be provided in order to
and if it matches the checksum sent by the master, get it. A user executing the klist command out of
the new information is used to update the slave’s curiosity may be surprised at all the tickets which
database. have silently been obtained on her/his behalf for
services which require Kerberos authentication.
Master
6.2. From the Programmer’s Viewpoint
A programmer writing a Kerberos applica-
kprop tion will often be adding authentication to an
already existing network application consisting of
a client and server side. We call this process
‘‘Kerberizing’’ a program. Kerberizing usually
kpropd kpropd kpropd involves making a call to the Kerberos library in
order to perform authentication at the initial
request for service. It may also involve calls to
Slave Slave Slave
the DES library to encrypt messages and data
which are subsequently sent between application
Figure 13. Database Propagation. client and application server.
The most commonly used library functions
All passwords in the Kerberos database are
are krb_mk_req on the client side, and
encrypted in the master database key Therefore,
krb_rd_req on the server side. The krb_mk_req
the information passed from master to slave over
routine takes as parameters the name, instance,
the network is not useful to an eavesdropper.
and realm of the target server, which will be
However, it is essential that only information
requested, and possibly a checksum of the data to
from the master host be accepted by the slaves,
be sent. The client then sends the message
and that tampering of data be detected, thus the
returned by the krb_mk_req call over the network
checksum.
to the server side of the application. When the
server receives this message, it makes a call to the
library routine krb_rd_req. The routine returns a
judgement about the authenticity of the sender’s

January 12, 1988

-- --

- 10 -

alleged identity. 7.1. Other Network Services’ Use of Kerberos

If the application requires that messages Several network applications have been
sent between client and server be secret, then modified to use Kerberos. The rlogin and rsh
library calls can be made to krb_mk_priv commands first try to authenticate using Ker-
(krb_rd_priv) to encrypt (decrypt) messages in beros. A user with valid Kerberos tickets can
the session key which both sides now share.7 rlogin to another Athena machine without having
to set up .rhosts files. If the Kerberos authentica-
6.3. The Kerberos Administrator’s Job tion fails, the programs fall back on their usual
The Kerberos administrator’s job begins methods of authorization, in this case, the .rhosts
with running a program to initialize the database. files.
Another program must be run to register essential We have modified the Post Office Protocol
principals in the database, such as the Kerberos to use Kerberos for authenticating users who
administrator’s name with an admin instance. wish to retrieve their electronic mail from the
The Kerberos authentication server and the ‘‘post office’’. A message delivery program,
administration server must be started up. If there called Zephyr, has been recently developed at
are slave databases, the administrator must Athena, and it uses Kerberos for authentication as
arrange that the programs to propagate database well.10
updates from master to slaves be kicked off The program for signing up new users,
periodically. called register, uses both the Service Manage-
After these initial steps have been taken, ment System (SMS)11 and Kerberos. From SMS,
the administrator manipulates the database over it determines whether the information entered by
the network, using the kadmin program. Through the would-be new Athena user, such as name and
that program, new principals can be added, and MIT identification number, is valid. It then
passwords can be changed. checks with Kerberos to see if the requested user-
In particular, when a new Kerberos appli- name is unique. If all goes well, a new entry is
cation is added to the system, the Kerberos made to the Kerberos database, containing the
administrator must take a few steps to get it work- username and password.
ing. The server must be registered in the data- For a detailed discussion of the use of Ker-
base, and assigned a private key (usually this is an beros to secure Sun’s Network File System,
automatically generated random key). Then, please refer to the appendix.
some data (including the server’s key) must be
extracted from the database and installed in a file 7.2. Interaction with Other Kerberi
on the server’s machine. The default file is It is expected that different administrative
/etc/srvtab. The krb_rd_req library routine organizations will want to use Kerberos for user
called by the server (see the previous section) authentication. It is also expected that in many
uses the information in that file to decrypt mes- cases, users in one organization will want to use
sages sent encrypted in the server’s private key. services in another. Kerberos supports multiple
The /etc/srvtab file authenticates the server as a administrative domains. The specification of
password typed at a terminal authenticates the names in Kerberos includes a field called the
user. realm. This field contains the name of the
The Kerberos administrator must also administrative domain within which the user is to
ensure that Kerberos machines are physically be authenticated.
secure, and would also be wise to maintain back- Services are usually registered in a single
ups of the Master database.8 realm and will only accept credentials issued by
an authentication server for that realm. A user is
7. The Bigger Picture usually registered in a single realm (the local
In this section, we describe how Kerberos realm), but it is possible for her/him to obtain
fits into the Athena environment, including its use credentials issued by another realm (the remote
by other network services and applications, and realm), on the strength of the authentication pro-
how it interacts with remote Kerberos realms. vided by the local realm. Credentials valid in a
For a more complete description of the Athena remote realm indicate the realm in which the user
environment, please see G. W. Treese.9 was originally authenticated. Services in the
remote realm can choose whether to honor those

January 12, 1988

-- --

- 11 -

credentials, depending on the degree of security acquire other network services on her/his behalf?
required and the level of trust in the realm that An example where this would be important is the
initially authenticated the user. use of a service that will gain access to protected
In order to perform cross-realm authentica- files directly from a fileserver. Another example
tion, it is necessary that the administrators of each of this problem is what we call authentication for-
pair of realms select a key to be shared between warding. If a user is logged into a workstation
their realms. A user in the local realm can then and logs in to a remote host, it would be nice if
request a ticket-granting ticket from the local the user had access to the same services available
authentication server for the ticket-granting server locally, while running a program on the remote
in the remote realm. When that ticket is used, the host. What makes this difficult is that the user
remote ticket-granting server recognizes that the might not trust the remote host, thus authentica-
request is not from its own realm, and it uses the tion forwarding is not desirable in all cases. We
previously exchanged key to decrypt the ticket- do not presently have a solution to this problem.
granting ticket. It then issues a ticket as it nor- Another problem, and one that is important
mally would, except that the realm field for the in the Athena environment, is how to guarantee
client contains the name of the realm in which the the integrity of the software running on a work-
client was originally authenticated. station. This is not so much of a problem on
This approach could be extended to allow private workstations since the user that will be
one to authenticate oneself through a series of using it has control over it. On public work-
realms until reaching the realm with the desired stations, however, someone might have come
service. In order to do this, though, it would be along and modified the login program to save the
necessary to record the entire path that was taken, user’s password. The only solution presently
and not just the name of the initial realm in which available in our environment is to make it diffi-
the user was authenticated. In such a situation, all cult for people to modify software running on the
that is known by the server is that A says that B public workstations. A better solution would
says that C says that the user is so-and-so. This require that the user’s key never leave a system
statement can only be trusted if everyone along that the user knows can be trusted. One way this
the path is also trusted. could be done would be if the user possessed a
smartcard capable of doing the encryptions
8. Issues and Open Problems required in the authentication protocol.
There are a number of issues and open
9. Status
problems associated with the Kerberos authenti-
cation mechanism. Among the issues are how to A prototype version of Kerberos went into
decide the correct lifetime for a ticket, how to production in September of 1986. Since January
allow proxies, and how to guarantee workstation of 1987, Kerberos has been Project Athena’s sole
integrity. means of authenticating its 5,000 users, 650
workstations, and 65 servers. In addition, Ker-
The ticket lifetime problem is a matter of
beros is now being used in place of .rhosts files
choosing the proper tradeoff between security and
for controlling access in several of Athena’s
convenience. If the life of a ticket is long, then if
timesharing systems.
a ticket and its associated session key are stolen
or misplaced, they can be used for a longer period
10. Acknowledgements
of time. Such information can be stolen if a user
forgets to log out of a public workstation. Alter- Kerberos was initially designed by Steve
natively, if a user has been authenticated on a sys- Miller and Clifford Neuman with suggestions
tem that allows multiple users, another user with from Jeff Schiller and Jerry Saltzer. Since that
access to root might be able to find the informa- time, numerous other people have been involved
tion needed to use stolen tickets. The problem with the project. Among them are Jim Aspnes,
with giving a ticket a short lifetime, however, is Bob Baldwin, John Barba, Richard Basch, Jim
that when it expires, the user will have to obtain a Bloom, Bill Bryant, Mark Colan, Rob French,
new one which requires the user to enter the pass- Dan Geer, John Kohl, John Kubiatowicz, Bob
word again. Mckie, Brian Murphy, John Ostlund Ken Rae-
burn, Chris Reed, Jon Rochlis, Mike Shanzer, Bill
An open problem is the proxy problem.
Sommerfeld, Ted T’so, Win Treese, and Stan
How can an authenticated user allow a server to
Zanarotti.

January 12, 1988

-- --

- 12 -

We are grateful to Dan Geer, Kathy

Lieben, Josh Lubarr, Ken Raeburn, Jerry Saltzer,
Ed Steiner, Robbert van Renesse, and Win Treese
whose suggestions much improved earlier drafts
of this paper.
The illustration on the title page is by Betsy
Bruemmer.

January 12, 1988

-- --

- 13 -

Appendix

Kerberos Application to SUN’s Network File System (NFS)

A key component of the Project Athena truly unfriendly user can break in by the very fact
workstation system is the interposing of the net- that s/he is sitting in the same physical location as
work between the user’s workstation and her/his the machine and has access to all console func-
private file storage (home directory). All private tions. Therefore we cannot truly trust our work-
storage resides on a set of computers (currently stations in the NFS interpretation of trust. To
VAX 11/750s) that are dedicated to this purpose. allow proper access controls in our environment
This allows us to offer services on publicly avail- we had to make some modifications to the base
able UNIX workstations. When a user logs in to NFS software, and integrate Kerberos into the
one of these publicly available workstations, scheme.
rather then validate her/his name and password
against a locally resident password file, we use Unmodified NFS
Kerberos to determine her/his authenticity. The In the implementation of NFS that we
login program prompts for a username (as on any started with (from the University of Wisconsin),
UNIX system). This username is used to fetch a authentication was provided in the form of a
Kerberos ticket-granting ticket. The login pro- piece of data included in each NFS request
gram uses the password to generate a DES key (called a ‘‘credential’’ in NFS terminology). This
for decrypting the ticket. If decryption is success- credential contains information about the unique
ful, the user’s home directory is located by con- user identifier (UID) of the requester and a list of
sulting the Hesiod naming service and mounted the group identifiers (GIDs) of the requester’s
through NFS. The login program then turns con- membership. This information is then used by the
trol over to the user’s shell, which then can run NFS server for access checking. The difference
the traditional per-user customization files between a trusted and a non-trusted workstation is
because the home directory is now ‘‘attached’’ to whether or not its credentials are accepted by the
the workstation. The Hesiod service is also used NFS server.12
to construct an entry in the local password file.
(This is for the benefit of programs that look up Modified NFS
information in /etc/passwd.)
In our environment, NFS servers must
From several options for delivery of remote accept credentials from a workstation if and only
file service, we chose SUN’s Network File Sys- if the credentials indicate the UID of the
tem. However this system fails to mesh with our workstation’s user, and no other.
needs in a crucial way. NFS assumes that all
One obvious solution would be to change
workstations fall into two categories (as viewed
the nature of credentials from mere indicators of
from a file server’s point of view): trusted and
UID and GIDs to full blown Kerberos authenti-
untrusted. Untrusted systems cannot access any
cated data. However a significant performance
files at all, trusted can. Trusted systems are com-
penalty would be paid if this solution were
pletely trusted. It is assumed that a trusted system
adopted. Credentials are exchanged on every
is managed by friendly management. Specifi-
NFS operation including all disk read and write
cally, it is possible from a trusted workstation to
activities. Including a Kerberos authentication on
masquerade as any valid user of the file service
each disk transaction would add a fair number of
system and thus gain access to just about every
full-blown encryptions (done in software) per
file on the system. (Only files owned by ‘‘root’’
transaction and, according to our envelope calcu-
are exempted.)
lations, would have delivered unacceptable per-
In our environment, the management of a formance. (It would also have required placing
workstation (in the traditional sense of UNIX sys- the Kerberos library routines in the kernel
tem management) is in the hands of the user address space.)
currently using it. We make no secret of the root
We needed a hybrid approach, described
password on our workstations, as we realize that a
below. The basic idea is to have the NFS server

January 12, 1988

-- --

- 14 -

map credentials received from client work- to the kernel as the valid mapping of the
stations, to a valid (and possibly different) <CLIENT−IP−ADDRESS, CLIENT−UID> tuple
credential on the server system. This mapping is for this request.
performed in the server’s kernel on each NFS At unmount time a request is sent to the
transaction and is setup at ‘‘mount’’ time by a mount daemon to remove the previously added
user-level process that engages in Kerberos- mapping from the kernel. It is also possible to
moderated authentication prior to establishing a send a request at logout time to invalidate all
valid kernel credential mapping. mapping for the current user on the server in
To implement this we added a new system question, thus cleaning up any remaining map-
call to the kernel (required only on server sys- pings that exist (though they shouldn’t) before the
tems, not on client systems) that provides for the workstation is made available for the next user.
control of the mapping function that maps incom-
ing credentials from client workstations to Security Implications of the Modified NFS
credentials valid for use on the server (if any). This implementation is not completely
The basic mapping function maps the tuple: secure. For starters, user data is still sent across
<CLIENT−IP−ADDRESS, UID−ON−CLIENT> the network in an unencrypted, and therefore
interceptable, form. The low-level, per-
to a valid NFS credential on the server system. transaction authentication is based on a
The CLIENT−IP−ADDRESS is extracted from <CLIENT−IP−ADDRESS, CLIENT−UID> pair
the NFS request packet and the provided unencrypted in the request packet. This
UID−ON−CLIENT is extracted from the creden- information could be forged and thus security
tial supplied by the client system. Note: all infor- compromised. However, it should be noted that
mation in the client-generated credential except only while a user is actively using her/his files
the UID−ON−CLIENT is discarded. (i.e., while logged in) are valid mappings in place
If no mapping exists, the server reacts in and therefore this form of attack is limited to
one of two ways, depending it is configured. In when the user in question is logged in. When a
our friendly configuration we default the unmap- user is not logged in, no amount of IP address for-
pable requests into the credentials for the user gery will permit unauthorized access to her/his
‘‘nobody’’ who has no privileged access and has files.
a unique UID. Unfriendly servers return an NFS
access error when no valid mapping can be found References
for an incoming NFS credential.
Our new system call is used to add and 1. S. P. Miller, B. C. Neuman, J. I. Schiller,
delete entries from the kernel resident map. It and J. H. Saltzer, Section E.2.1: Kerberos
also provides the ability to flush all entries that Authentication and Authorization System,
map to a specific UID on the server system, or M.I.T. Project Athena, Cambridge, Mas-
flush all entries from a given sachusetts (December 21, 1987).
CLIENT−IP−ADDRESS.
2. E. Balkovich, S. R. Lerman, and R. P. Par-
We modified the mount daemon (which melee, ‘‘Computing in Higher Education:
handles NFS mount requests on server systems) The Athena Experience,’’ Communications
to accept a new transaction type, the Kerberos of the ACM 28(11), pp. 1214-1224, ACM
authentication mapping request. Basically, as (November, 1985).
part of the mounting process, the client system
provides a Kerberos authenticator along with an 3. R. M. Needham and M. D. Schroeder,
indication of her/his UID−ON−CLIENT ‘‘Using Encryption for Authentication in
(encrypted in the Kerberos authenticator) on the Large Networks of Computers,’’ Communi-
workstation. The server’s mount daemon con- cations of the ACM 21(12), pp. 993-999
verts the Kerberos principal name into a local (December, 1978).
username. This username is then looked up in a 4. V. L. Voydock and S. T. Kent, ‘‘Security
special file to yield the user’s UID and GIDs list. Mechanisms in High-Level Network Proto-
For efficiency, this file is a ndbm database file cols,’’ Computing Surveys 15(2), ACM
with the username as the key. From this informa- (June 1983).
tion, an NFS credential is constructed and handed 5. National Bureau of Standards, ‘‘Data

January 12, 1988

-- --

- 15 -

Encryption Standard,’’ Federal Information

Processing Standards Publication 46,
Government Printing Office, Washington,
D.C. (1977).
6. S. P. Dyer, ‘‘Hesiod,’’ in Usenix Confer-
ence Proceedings (Winter, 1988).
7. W. J. Bryant, Kerberos Programmer’s
Tutorial, M.I.T. Project Athena (In prepara-
tion).
8. W. J. Bryant, Kerberos Administrator’s
Manual, M.I.T. Project Athena (In prepara-
tion).
9. G. W. Treese, ‘‘Berkeley Unix on 1000
Workstations: Athena Changes to
4.3BSD,’’ in Usenix Conference Proceed-
ings (Winter, 1988).
10. C. A. DellaFera, M. W. Eichin, R. S.
French, D. C. Jedlinsky, J. T. Kohl, and W.
E. Sommerfeld, ‘‘The Zephyr Notification
System,’’ in Usenix Conference Proceed-
ings (Winter, 1988).
11. M. A. Rosenstein, D. E. Geer, and P. J.
Levine, in Usenix Conference Proceedings
(Winter, 1988).
12. R. Sandberg, D. Goldberg, S. Kleiman, D.
Walsh, and B. Lyon, ‘‘Design and Imple-
mentation of the Sun Network Filesystem,’’
in Usenix Conference Proceedings (Sum-
mer, 1985).

January 12, 1988