Limitations of the Kerberos
Authentication System+
Steven M. Bellovin -- AT&T Bell Laboratories
Michael Merritt -- AT&T Bell Laboratories
ABSTRACT
The Kerberos authentication system, a part of MIT's Project Athena, has been
adopted by other organizations. Despite Kerberos's many strengths, it has a number of
limitations and some weaknesses. Some are due to specifics of the MIT environment;
others represent deficiencies in the protocol design. We discuss a number of such
problems, and present solutions to some of them. We also demonstrate how special-
purpose cryptographic hardware may be needed in some cases.
INTRODUCTION
The Kerberos authentication system[Stei88, Mill87,
Brya88] was introduced by MIT to meet the needs of
Project Athena. It has since been adopted by a
number of other organizations for their own pur-
poses, and is being discussed as a possible standard.
In our view, both these decisions may be premature.
Kerberos has a number of limitations and
weaknesses; a decision to adopt or reject it cannot
properly be made without considering these issues.
(A limitation is a feature that is not as general as one
might like, while a weakness could be exploited by
an attacker to defeat the authentication mechanism.)
Some improvements can be made within the current
design. Support for optional mechanisms would
extend Kerberos's applicability to environments radi-
cally different from MIT.
These problems fall into several categories.
Some stem from the Project Athena environment.
Kerberos was designed for that environment; if the
basic assumptions differ, the authentication system
may need to be changed as well. Other problems are
simply deficiencies in the protocol design. Some of
these are corrected in the proposed Version 5 of
Kerberos,[Kohl89] but not all. Even the solved prob-
lems merit discussion, since the code for Version 4
has been widely disseminated. Finally, some prob-
lems with Kerberos are not solvable without employ-
ing special-purpose hardware, no matter what the
design of the protocol. We will consider each of
these areas in turn.
We wish to stress that we are not suggesting
that Kerberos is useless. Quite the contrary --- an
attacker capable of carrying out any of the attacks
listed here could penetrate a typical network of UNIX
systems far more easily. Adding Kerberos to a net-
work will, under virtually all circumstances,
significantly increase its security; our criticisms focus
+A version of this paper was published in the October,
1990 issue of Computer Communications Review.
on the extent to which security is improved. Further,
we recommend changes to the protocols that substan-
tially increase security.
Beyond its specific utility in production, Ker-
beros serves a major function by focusing interest on
practical solutions to the network authentication
problem. The elegant protocol design and wide avai-
lability of the code has galvanized a wide audience.
Far from a condemnation, our critique is intended to
contribute to an understanding of Kerberos's proper-
ties and to influence its evolution into a tool of
greater power and utility.
Several of the problems we point out are men-
tioned in the original Kerberos paper or
elsewhere.[Davi90] For some of these, we present pro-
tocol improvements that solve, or at least ameliorate,
the problem; for others, we place them squarely in
the context of the intended Kerberos environment.
Version 5, Draft 3
Since this paper was written, a new draft of the
Version 5 protocol has been released, and a final
specification is promised.[Kohl90] Many of the prob-
lems we discuss herein have been corrected. Others
remain, and we have found a few new ones. The
ultimate resolution of these issues is unclear as we
go to press. Consequently, a brief analysis of
Draft 3 is presented in an appendix, rather than in
the main body of the document.
Focus on Security
Kerberos is a security system; thus, though we
address issues of functionality and efficiency, our
primary emphasis is on the security of Kerberos in a
general environment. This means that security-
critical assumptions must be few in number and
stated clearly. For the widest utility, the network
must be considered as completely open. Specifically,
the protocols should be secure even if the network is
USENIX -- Winter '91 -- Dallas, TX 1

Kerberos Limitations Bellovin & Merritt
under the complete control of an adversary. 1 This
means that defeating the protocol should require the
adversary to invert the encryption algorithm or to
subvert a principal specifically assumed to be
trustworthy. Only such a strong design goal can jus-
tify the expense of encryption. (No ``steel doors in
paper walls''.) We believe that Kerberos can meet
this ambitious goal with only minor modifications,
retaining its essential character.
Some of our suggestions bear a performance
penalty; others complicate the design of suggested
enhancements. As more organizations make use of
Kerberos, pressures to enhance or augment its func-
tionality and efficiency will increase. Security has
real costs, and the benefits are intangible. There
must be a continuing and explicit emphasis on secu-
rity as the overriding requirement.
Validation
It is not sufficient to design and implement a
security system. Such systems, though apparently
adequate when designed, may have serious flaws.
Consequently, systems must be subjected to the
strongest scrutiny possible. A consequence of this is
that they must be designed and implemented in a
manner that facilitates such scrutiny. Kerberos has a
number of problems in this area as well.
WHAT'S A KERBEROS?
Before discussing specific problem areas, it is
helpful to review Kerberos Version 4. Kerberos is
an authentication system; it provides evidence of a
principal's identity. A principal is generally either a
user or a particular service on some machine. A
principal consists of the three-tuple
< primaryname, instance , realm >.
If the principal is a user --- a genuine person --- the
primary name is the login identifier, and the instance
is either null or represents particular attributes of the
user, i.e., root . For a service, the service name is
used as the primary name and the machine name is
used as the instance, i.e., rlogin.myhost . The
realm is used to distinguish among different authen-
tication domains; thus, there need not be one giant
--- and universally trusted --- Kerberos database
serving an entire company.
1 The Project Athena Technical Plan[Mill87, section 2]
describes a simpler threat environment, where eavesdrop-
ping and host impersonation are of primary concern.
While this may be appropriate for MIT, it is by no means
generally true. Consider, for example, a situation where
general-purpose hosts also function as routers, and packet
modification or deletion become significant concerns.
Table 1: Notation
c client principal
s server principal
tgs ticket-granting server
K x private key of ``x''
K c,s session key for ``c'' and ``s''
{in fo}K x ``in fo'' encrypted in key K x
{T c,s }K s Encrypted ticket for ``c'' to use ``s''
{A c }K c,s Encrypted authenticator for ``c'' to
use ``s''
addr client's IP address
Kerberos principals may obtain tickets for ser-
vices from a special server known as the ticket-
granting server, or TGS. A ticket contains assorted
information identifying the principal, encrypted in
the private key of the service. (Notation is summar-
ized in Table 1.)
{T c,s }K s = {s , c , addr , timestamp , li fetime , K c,s }K s
Since only Kerberos and the service share the private
key K s , the ticket is known to be authentic. The
ticket contains a new private session key, K c,s ,
known to the client as well; this key may be used to
encrypt transactions during the session. 2
To guard against replay attacks, all tickets
presented are accompanied by an authenticator:
{A c }K c,s = {c , addr , timestamp}K c,s
This is a brief string encrypted in the session key
and containing a timestamp; if the time does not
match the current time within the (predetermined)
clock skew limits, the request is assumed to be
fraudulent.
For services where the client needs bidirectional
authentication, the server can reply with
{timestamp + 1}K c,s
This demonstrates that the server was able to read
timestamp from the authenticator, and hence that it
knew K c,s ; that in turn is only available in the ticket,
which is encrypted in the server's private key.
Tickets are obtained from the TGS by sending
a request
s , {T c,tgs }K tgs , {A c }K c,tgs
In other words, an ordinary ticket/authenticator pair
is used; the ticket is known as the ticket-granting
2 Technically speaking, K c,s is a multi-session key, since
it is used for all contacts with that server during the life of
the ticket.
2 USENIX -- Winter '91 -- Dallas, TX

Bellovin & Merritt Kerberos Limitations
ticket. The TGS responds with a ticket for server s
and a copy of K c,s , all encrypted with a private key
shared by the TGS and the principal:
{{T c,s }K s , K c,s }K c,tgs
The session key K c,s is a newly-chosen random key.
The key K c,tgs and the ticket-granting ticket
itself, are obtained at session-start time. The client
sends a message to Kerberos with a principal name;
Kerberos responds with
{K c,tgs , {T c,tgs }K tgs }K c
The client key K c is derived from a non-invertible
transform of the user's typed password. Thus, all
privileges depend ultimately on this one key.
Note that servers must possess private keys of
their own, in order to decrypt tickets. These keys
are stored in a secure location on the server's
machine.
THE KERBEROS ENVIRONMENT
The Project Athena computing environment
consists of a large number of more or less
anonymous workstations, and a smaller number of
large autonomous server machines. The servers pro-
vide volatile file storage, print spooling, mailboxes,
and perhaps some computing power; the worksta-
tions are used for most interaction and computing.
Generally, they possess local disks, but these disks
are effectively read-only; they contain no long-term
user data. Furthermore, they are not physically
secure; someone so inclined could remove, read, or
alter any portion of the disk without hindrance.
Within this environment the primary need is for
user-to-server authentication. That is, when a user
sits down at a workstation, that person needs access
to private files residing on a server. The workstation
itself has no such files, and hence has no need to
contact the server or even to identify itself.
This is in marked contrast to a typical UNIX
system's view of the world. Such systems do have
an identity, and they do own files. Assorted network
daemons transfer files in the background, clock dae-
mons perform management functions, electronic mail
and news arrives, etc. If such a machine relied on
servers to store its files, it would have to assert, and
possibly prove, an identity when talking to these
servers. The Project Athena workstations are neither
capable nor in need of such; they in effect function
as very smart terminals with substantial local com-
puting power, rather than as full computer systems. 3
What does this mean for Kerberos? Simply
this: Kerberos is designed to authenticate the end-
user --- the human being sitting at the keyboard ---
to some number of servers. It is not a peer-to-peer
system; it is not intended to be used by one
3 We regard this as a feature, not a bug.
computer's daemons when contacting another com-
puter. Attempting to use Kerberos in such a mode
can cause trouble. 4
We make this statement for several reasons.
First and foremost, typical computer systems do not
have a secure key storage area. In Kerberos, a plain-
text key must be used in the initial dialog to obtain a
ticket-granting ticket. But storing plaintext keys in a
machine is generally felt to be a bad idea;[Morr79] if a
Kerberos key that a machine uses for itself is
compromised, the intruder can likely impersonate
any user on that computer, by impersonating requests
vouched for by that machine (i.e., file mounts or
cron jobs). 5 Additionally, the session keys returned
by the TGS cannot be stored securely; of necessity,
they are stored in some area accessible to root .
Thus, if the intruder can crack the protection
mechanism on the local computer --- or, perhaps
more to the point, work around it for some limited
purposes --- all current session keys can be stolen.
This is less serious than a breach of the primary Ker-
beros key, of course, since session keys are limited
in lifetime and scope; nevertheless, one does not
wish these keys exposed.
This points out a second flaw when multi-user
computers employ Kerberos, either on their own
behalf or for their users: the cached keys are acces-
sible to attackers logged in at the same time. In a
workstation environment, only the current user has
access to system resources; there is little or no need
even to enable remote login to that workstation.
There are many reasons for this; a consequence,
though, is that the intruder simply cannot approach
the safe door to try to pick its lock. 6 Only when the
legitimate user leaves can the attacker attempt to find
the keys. But the keys are no longer available; Ker-
beros attempts to wipe out old keys at logoff time,
leaving the attacker to sift through the debris. With
a multi-user computer, on the other hand, an attacker
has concurrent access to the keys if there are flaws in
the host's security.
There are two other minor flaws in Kerberos
directly attributable to the environment. First, there
is some question about where keys should be cached.
Since all of the Project Athena machines have local
disks, the original code used /tmp . But this is
highly insecure on diskless workstations, where
/tmp exists on a file server; accordingly, a
modification was made to store keys in shared
memory. However, there is no guarantee that shared
memory is not paged; if this entails network traffic,
4 More precisely, Kerberos is not a host-to-host protocol.
In Version 5, it has been extended to support user-to-user
authentication.[Davi90]
5 Recall that we are assuming here that the machine ---
and hence its superuser --- needs an identity of its own.
6 On Project Athena machines, remote access to most
workstations is in fact disabled.
USENIX -- Winter '91 -- Dallas, TX 3

Kerberos Limitations Bellovin & Merritt
an intruder can capture these keys.
Finally, the Kerberos protocol binds tickets to
IP addresses. Such usage is problematic on on
multi-homed hosts (i.e., hosts with more than one IP
address). Since workstations rarely have multiple
addresses, this feature --- intended to enhance secu-
rity --- was not a problem at MIT. Multi-user hosts
often do have multiple addresses, however, and can-
not live with this limitation. This problem has been
fixed in Version 5.
PROTOCOL WEAKNESSES
Replay Attacks
The Kerberos protocol is not as resistant to
penetration as it should be. A number of weaknesses
are apparent; the most serious is its use of an authen-
ticator to prevent replay attacks.
The authenticator relies on use of a timestamp
to guard against reuse. This is problematic for
several reasons. The claim is made that no replays
are likely within the lifetime of the authenticator
(typically five minutes). This is reinforced by the
presence of the IP address in both the ticket and the
authenticator. We are not persuaded by this logic.
An intruder would not start by capturing a ticket and
authenticator, and then develop the software to use
them; rather, everything would be in place before the
ticket-capture was attempted. Let us consider two
examples.
Some years ago, Morris described an attack
based on the slow increment rate of the initial
sequence number counter in some TCP
implementations.[Morr85] He demonstrated that it was
possible, under certain circumstances, to spoof one
half of a preauthenticated TCP connection without
ever seeing any responses from the targeted host. In
a Kerberos environment, his attack would still work
if accompanied by a stolen live authenticator, but not
if a challenge/response protocol was used. Alterna-
tively, an intruder may simply watch for a ``mail-
checking'' session, wherein a user logs in briefly,
reads a few messages, and logs out. A number of
valuable tickets would be exposed by such a session,
notably the one used to mount the user's home direc-
tory. Note that the lifetime of the authenticators ---
5 minutes --- contributes considerably to this attack.
Further, the proposed Version 5 of Kerberos
anticipates alternative communication protocols in
which such replays may be trivial to implement. If
Kerberos is to be considered as a general-purpose
utility, it must make few security-critical assump-
tions about the underlying network, and those must
be explicit.
It has been suggested that the proper defense is
for the server to store all live authenticators; thus, an
attempt to reuse one can be detected.[Stei88] In fact,
the original design of Kerberos required such
caching, though this was never implemented. (While
that is a feature of the implementation rather than of
the protocol itself, a security feature is not very use-
ful if it is too hard to implement.)
For several reasons, we do not think that cach-
ing solves the problem. First, on UNIX systems it is
difficult for TCP-based[Post81] servers to store
authenticators. Servers generally operate by forking
a separate process to handle each incoming request.
The child processes do not share any memory with
the parent process, and thus have no convenient way
to inform it --- and hence any other child servers ---
of the value of the authenticator used. There are a
number of obvious solutions --- pipes, authenticator
servers, shared memory segments and the like --- but
all are awkward, and some even raise authentication
questions of their own. To date, we know of no
multi-threaded server implementation which caches
authenticators.
UDP-based[Post80] query servers can store the
authenticators more easily, as a single process gen-
erally handles all incoming requests; however, they
might have problems with legitimate retransmissions
of the client's request if the answer was lost. (UDP
does not provide guaranteed delivery; thus, all
retransmissions happen from application level, and
are visible to the application.) Legitimate requests
could be rejected, and a security alarm raised inap-
propriately. One possible solution would be for the
application to generate a new authenticator when
retransmitting a request; were it not for the other
weaknesses of the authenticator scheme, this would
be acceptable.
Secure Time Services
As noted, authenticators rely on machines'
clocks being roughly synchronized. If a host can be
misled about the correct time, a stale authenticator
can be replayed without any trouble at all. Since
some time synchronization protocols are
unauthenticated,[Post83, Mill88] and hosts are still using
these protocols despite the existence of better
ones,[Mill89] such attacks are not difficult.
The design philosophy of building an authenti-
cation service on top of a secure time service is itself
questionable. That is, it may not make sense to
build an authentication system assuming an already-
authenticated underlying system. Furthermore, while
spoofing an unauthenticated time service may be a
difficult programming task, it is not cryptographi-
cally difficult. 7 Using time-based protocols in a
secure fashion means thinking through all these
issues carefully and making the appropriate
7 In some environments, programming is not even neces-
sary. Low-powered fake WWV transmitters are not hard
to build, and, if properly located, could easily block out
the legitimate signal.
4 USENIX -- Winter '91 -- Dallas, TX

Bellovin & Merritt Kerberos Limitations
synchronization an explicit part of the protocol. As
Kerberos is proposed for more varied environments,
its dependence on a secure time service becomes
more problematic and must be stressed.
As an alternative, we propose the use of a
challenge/response authentication mechanism. As is
done today, the client would present a ticket, though
without an authenticator. The server would respond
with a nonce identifier encrypted with the session
key K c,s ; the client would respond with some func-
tion of that identifier, thereby proving that it
possesses the session key.
Such an implementation is not without its costs,
of course. An extra pair of messages must be
exchanged each time a ticket is used, which rules out
the possibility of authenticated datagrams. More
seriously, all servers must then retain state to com-
plete the authentication process. While not a prob-
lem for TCP-based servers, this may require substan-
tial modification to UDP-based query servers. (The
complexity of managing outstanding challenges may
be comparable to that needed to cache live authenti-
cators --- the trade-off is not between a stateful and a
stateless protocol, but in managing two kinds of
state.)
There is a signficant philosophical difference
between the two techniques, however. In the current
Kerberos implementation, with its assumptions about
the network environment, retained state is only
necessary to enhance security. The
challenge/response scheme, on the other hand,
guarantees security in a more general environment,
but requires retained state to function at all.
Instead of substituting challenge/response
throughout, a possible compromise is to extend the
protocol with a challenge/response option. This
option could be used, for example, to authenticate
the user in the initial ticket-granting ticket exchange
and to access a time service. 8 Subsequent client-
server interactions could use the current time-based
protocol. But synchronizing the servers remains a
problem; not synchronizing them will lead to denial
of service, and if they access the time service as a
client, they must somehow obtain and store a ticket
and key to authenticate it. (See above on storing
keys in servers.) Given these complexities and pos-
sible weaknesses, it would seem reasonable to allow
any service to insist on the challenge/response
option.
Summarizing, we emphasize that the security of
Kerberos depends critically on synchronized clocks.
In essence, the Kerberos protocols involve mutual
trust among four parties: the client, server, authenti-
cation server and time server.
8 This was suggested to us by Clifford Neuman.
Password-Guessing Attacks
A second major class of attack on the Kerberos
protocols involves an intruder recording login dialogs
in order to mount a password-guessing assault.
When a user requests T c,tgs (the ticket-granting
ticket), the answer is returned encrypted with K c , a
key derived by a publicly-known algorithm from the
user's password. A guess at the user's password can
be confirmed by calculating K c and using it to
decrypt the recorded answer. An intruder who has
recorded many such login dialogs has good odds of
finding several new passwords; empirically, users do
not pick good passwords unless forced to.[Morr79,
Gram84, Stol88]
We propose the use of exponential key
exchange[Diff76] to provide an additional layer of
encryption. Without describing the algorithm in
detail, it involves the two parties exchanging
numbers that each can use to compute a secret key.
An outsider, not knowing how the numbers were cal-
culated, cannot easily derive the key.
Such a use of exponential key exchange would
prevent a passive wiretapper from accumulating the
network equivalent of /etc/passwd . While
exponential key exchange is normally vulnerable to
active wiretaps, such attacks are comparatively rare,
especially if dedicated network routers are used.
Apart from licensing issues --- exponential key
exchange is protected by a U.S. patent --- using it
has its costs. LaMacchia and Odlyzko[LaMa] have
demonstrated that exchanging small numbers is quite
insecure, while using large ones is expensive in com-
putation time. Additionally, we have added extra
messages to the login dialog, and imposed the
requirement for considerable extra state in the server.
Given the trend towards hiding even encrypted pass-
words on UNIX systems, and given estimates that half
of all logins at MIT are used within a two-week
period, the investment may be justifiable. Perhaps
the best solution is to support this feature as a
domain-specific option.
Even exponential key exchange will not prevent
all password-guessing attacks. Depending on how
carefully the Kerberos logs are analyzed, an intruder
need not even eavesdrop. Requests for tickets are
not themselves encrypted; an attacker could simply
request ticket-granting tickets for many different
users. An enhancement to the server, to limit the
rate of requests from a single source, may be useful.
Alternatively, some portion of the initial ticket
request may be encrypted with K c , providing a
minimal authentication of the user to Kerberos, such
that true eavesdropping would be required to mount
this attack. (As we are preparing this manuscript,
just such a suggestion is being hotly debated on the
Kerberos mailing list. We originally overlooked an
alternative avenue for mounting a password-guessing
attack. Clients may be treated as services, and
USENIX -- Winter '91 -- Dallas, TX 5

Kerberos Limitations Bellovin & Merritt
tickets to the client, encrypted by K c , may be
obtained by any user. This capability has been sug-
gested as the basis for user-to-user authentication and
and enhanced mail services.[Salt90] But any such
scheme would seem to require repeated re-entry of
the user's password, an inconvenience we suspect
will not be tolerated. We would prefer to provide
the same functionality by having clients register
separate instances as services, with truly random
keys. Keys could be supplied to the client by the
keystore, described below.)
An alternative approach is a protocol described
by Lomas, Gong, Saltzer, and Needham.[Loma89]
They present a dialog with a server that does not
expose the user to password-guessing attacks. How-
ever, their protocol relies on public-key cryptogra-
phy, an approach explicitly rejected for Kerberos.
Spoofing Login
In a workstation environment, it is quite simple
for an intruder to replace the login command with
a version that records users' passwords before
employing them in the Kerberos dialog. Such an
attack negates one of Kerberos's primary advantages,
that passwords are never transmitted in cleartext over
a network. While this problem is not restricted to
Kerberos environments, the Kerberos protocol makes
it difficult to employ the standard countermeasure:
one-time passwords.
A typical one-time password scheme employs a
secret key shared between a server and some device
in the user's possession. The server picks a random
number and transmits it to the user. Both the server
and the user (with the aid of the device) encrypt this
number using the secret key; the result is transmitted
back to the server. If the two computed values
match, the user is assumed to possess the appropriate
key.
Kerberos makes no provision for such a
challenge/response dialog at login time. The server's
response to the login request is always encrypted
with K c , a key derived from the user's password.
Unless a ``smart card'' is employed that understands
the entire Kerberos protocol, this precludes any use
of one-time passwords.
An alternative (first suggested to us by T.H.
Foregger) requires that the server pick a random
number R, and use K c to encrypt R. This value
{R}K c , rather than K c , would be used to encrypt the
server's response. R would be transmitted in the
clear to the user. If a hand-held authenticator was in
use, the user would employ it to calculate {R}K c ;
otherwise, the login program would do it automatic-
ally.
Several objections may be raised to this
scheme. First, hand-held authenticators are often
thought to be inconvenient. This is true; however,
they offer a substantial increase in security in high-
threat environments. If they are not used, the cost of
our scheme is quite low, simply one extra encryption
on each end.
A second, more cogent, objection is that if the
client's workstation cannot be trusted with a user's
password, it cannot be trusted with session keys pro-
vided by Kerberos. This is, to some extent, a valid
criticism, though we believe that compromise of the
login password is much more serious than the cap-
ture of a few limited-lifetime session keys. This
problem cannot be solved without the use of
special-purpose hardware, a subject we shall return
to below.
Finally, it has been pointed out that a user can
always supply a known-clean boot device, or boot
via the network. The former we regard as improb-
able in practice unless removable media are
employed; the latter is insecure because the boot pro-
tocols are unauthenticated.
Inter-Session Chosen Plaintext Attacks
According to the description in the Version 5
draft,[Kohl89] servers using the KRB_PRIV format are
susceptible to a chosen plaintext attack. (A chosen-
plaintext attack is one where an attacker may choose
all or part of the plaintext and, typically, use the
resulting cipher text to attack the cipher. Here we
use the cipher text to attack the protocol. Mail and
file servers are examples of servers susceptible to
such attacks.) Specifically, the encrypted portion of
messages of this type have the form
X = (DATA , timestamp + direction , hostaddress , PAD)
Since cipher-block chaining[FIPS81, Davi89] has the
property that prefixes of encryptions are encryptions
of prefixes, if DATA has the form
(AUTHENTICATOR , CHECKSUM , REMAINDER)
then a prefix of the encryption of X with the session
key is the encryption of
(AUTHENTICATOR , CHECKSUM) ,
and can be used to spoof an entire session with the
server.
It may be argued that most servers are not sus-
ceptible to chosen plaintext attacks. Given that there
are easy counters to this attack, it seems foolish to
advocate a general format for private servers that
does not also protect against it.
It should be noted that the simple attack above
does not work against Kerberos Version 4, in which
the encrypted portion of the KRB_PRIV message is
of the form
(length(DATA) , DATA , msectime, hostaddress ,
timestamp + direction , PAD)
as the leading length(DATA) field disrupts the
prefix-based attack. We leave it to the reader to
6 USENIX -- Winter '91 -- Dallas, TX

Bellovin & Merritt Kerberos Limitations
discover a more complicated chosen ciphertext attack
against this format, even allowing for the fact that
Version 4 uses the nonstandard PCBC mode of
encryption. (Hint: assume the initial vector is fixed
and public.) However, it is interesting to note that
the order of concatenation of message fields can
have security-critical implications. We return to this
question in the later section on message encoding.
Exposure of Session Keys
The term ``session key'' is a misnomer in the Ker-
beros protocol. This key is contained in the service
ticket and is used in the multiple sessions between
the client and server that use that ticket. Thus, it is
more properly called a ``multi-session key''. Mak-
ing this point explicit leads naturally to the sugges-
tion that true session keys be negotiated as part of
the Kerberos protocol. This limits the exposure to
cryptanalysis[Kahn67, Beke82, Deav85] of the multi-
session key contained in the ticket, and precludes
attacks which substitute messages from one session
in another. (The chosen-plaintext attack of the previ-
ous section is one such example.) The session key
could be generated by the server or could be com-
puted as a session-specific function of the multi-
session key.
The Scope of Tickets
Kerberos tickets are limited in both time and
space. That is, tickets are usable only within the
realm of the ticket-granting server, and only for a
limited period of time. The first is necessary to the
design of Kerberos; the TGS would not have any
keys in common with servers in other realms. The
latter is a security measure; the longer a ticket is in
use, the greater the risk of it being stolen or
compromised.
A further restriction on tickets, in Version 4, is
that they cannot be forwarded. A user may obtain
tickets at login time, and use these to log in to some
other host; however, it is not possible to obtain
authenticated network services from that host unless
a new ticket-granting ticket is obtained. And that in
turn would require transmission of a password across
the network, in violation of fundamental principles
of Kerberos's design. 9
Version 5 incorporates provisions for ticket-
forwarding; however, this introduces the problem of
cascading trust. That is, a host A may be willing to
trust credentials from host B, and B may be willing
to trust host C, but A may not be willing to accept
tickets originally created on host C, which A believes
to be insecure. Kerberos has a flag bit to indicate
9 Actually, a special-purpose ticket-forwarder was built
for Version 4. However, the implementation was of
necessity awkward, and required participating hosts to run
an additional server.
that a ticket was forwarded, but does not include the
original source.
A second problem with forwarding is that the
concept only makes sense if tickets include the net-
work address of the principal. If the address is omit-
ted --- as is permitted in Version 5 --- a ticket may
be used from any host, without any further
modifications to the protocol. All that is necessary
to employ such a ticket is a secure mechanism for
copying the multi-session key to the new host. But
that can be accomplished by an encrypted file
transfer mechanism layered on top of existing facil-
ites; it does not require flag bits in the Kerberos
header.
Is it useful to include the network address in a
ticket? We think not. Given our assumption that
the network is under full control of the attacker, no
extra security is gained by relying on the network
address. In fact, the primary benefit of including it
appears to be preventing immediate reuse of authen-
ticators from a different host.
Even with the protection provided by network
addresses, replay attacks that involve faked addresses
are easy; again, see [Morr85]. Furthermore, an
attacker can always wait until the connection is set
up and authenticated, and then take it over, thus
obviating any security provided by the presence of
the address. Given these problems, and the cascad-
ing trust issue raised earlier, we suggest that ticket-
forwarding be deleted.
A new inter-realm authentication mechanism is
also introduced in Version 5. Briefly, if a user
wishes to access a service in another realm, that user
must first obtain a ticket-granting ticket for that
realm. This is done by making the ticket-granting
server in a realm the client of another realm's TGS.
It in turn may be a client of yet another realm's
TGS. A user's ticket request is signed by each TGS
and passed along; realms will normally be configured
in a hierarchical fashion, though ``tandem links'' are
permitted.
Unfortunately, this scheme, while appearing to
solve the problem, is deficient in several respects.
First, and most serious, there is no discussion of how
a TGS can determine which of its neighboring
realms should be the next hop. Moving up the tree,
towards the root, is an obvious answer for leaf
nodes; however, each parent node would need com-
plete knowledge of its entire subtree's realms in
order to determine how to pass the request down-
wards. There are obvious analogies here to
network-layer routing issues; note, though, that any
``realm routing protocol'' must include strong
authentication provisions.
Another answer is to say that static tables
should be used. This, too, has its security limita-
tions: should realm administrators rely on electronic
mail messages or telephone calls to set up their
USENIX -- Winter '91 -- Dallas, TX 7

Kerberos Limitations Bellovin & Merritt
routing tables? If such calls are not authenticated,
the security risks are obvious; if they are, the secu-
rity of a Kerberos realm is subordinated to the secu-
rity of a totally different authentication system.
There is also an evident link between inter-
realm authentication and the cascading-trust problem.
Kerberos Version 5 attempts to solve this by includ-
ing path information in the ticket request. However,
in the absence of a global name space, it is not clear
that this is useful. If a realm is not a neighbor, its
name may not carry any global signficance, whether
by malice or coincidence. Furthermore, to assess the
validity of a request, a server needs global
knowledge of the trustworthiness of all possible tran-
sit realms. In a large internet, such knowledge is
probably not possible.
KERBEROS HARDWARE DESIGN CRITERIA
A Host Encryption Unit
One of the major reasons we question the suita-
bility of Kerberos for multi-user hosts is the need for
plaintext key storage. What if the host were
equipped with an attached cryptographic unit? We
consider the design parameters for such a box.
The primary goal is to perform cryptographic
operations without exposing any keys to comprom-
ise. These operations must include validating tickets
presented by remote users, creating requests for both
ticket-granting tickets and application tickets, and
encrypting and decrypting conversations. Conse-
quently, there must be secure storage for an adequate
number of keys, and the operating system must be
able to select which key should be used for which
function.
The next question, of course, is how keys are
entered into the secure storage area. If tickets are
decrypted by the encryption box but transferred to
the host's memory for analysis, the embedded ses-
sion key is exposed. 10 Therefore, we conclude that
the encryption box itself must understand the Ker-
beros protocols; nothing less will guarantee the secu-
rity of the stored keys.
Entry of user keys is more problematic, since
they must travel through the host. Unless user ter-
minals are connected directly to the encryption unit,
there is little choice. Storing them off the host,
though, is a significant help, as the period of expo-
sure is then minimized. Host-owned keys --- service
keys, or the keys that root would use to do NFS
mounts --- should be loaded via a Kerberos-
authenticated service resident in the encryption unit.
10 This is not a hypothetical concern. A program to do
just that (for conventional passwords) was posted to net-
news as long ago as 1984. It operated by reading
/dev/kmem . The existence of this program was a princi-
pal factor motivating the current restrictive permission set-
tings on /dev/kmem .
We shall return to this point below.
We must now ensure that the protocol itself
does not provide a mechanism to obtain keys. Look-
ing at the message definitions, we see that only ses-
sion keys are ever sent, and these are always sent
encrypted. Furthermore, user machines never gen-
erate any such messages; they merely forward them.
Thus, the box need not have the ability to transmit a
key, thereby providing us with a very high level of
assurance that it will not do so.
If an encryption box is used for the Kerberos
server itself, the problem is somewhat more com-
plex. There are two places where keys are transmit-
ted. First, when a ticket is granted, the ticket itself
contains a session key, and a copy of that session
key is sent back encrypted in the client's ticket-
granting session key. Second, during the initial dia-
log with Kerberos, the ticket-granting session key
must be sent out, encrypted in the client's password
key. Note, though, that permanent keys are never
sent; again, this assures us that the encryption box
will not give away keys. Furthermore, since these
session keys are intended to be random, we can buy
ourselves a great deal of security by including a
hardware random number generator on-board.
We are not too concerned about having to load
client and server keys onto the board. This operation
is done only by the Kerberos master server, for
which strong physical security must be assumed in
any event. It is possible that such an encryption unit
can be made sufficiently tamper-resistant that even
workstations can use them; certainly, there are com-
mercial cryptographic devices that claim such
strengths.
One major objection to this entire scheme is
that ultimately, the encryption box is controlled by
the host computer. Thus, if root is compromised,
the host could instruct the box to create bogus tick-
ets. Such concerns are certainly valid. However, as
noted above, we consider such temporary breaches of
security to be far less serious than the compromise
of a key. Furthermore, using a separate unit allows
us to create untamperable logs, etc.
It is also desirable to prevent misuse of keys.
For example, we do not want the login key used to
decrypt the arbitrary block of text that just happens
to be the ticket-granting ticket. Accordingly, keys
should be tagged with their purpose. A login key
should be used only to decrypt the ticket-granting
ticket; the key associated with it should be used only
for obtaining service tickets, etc. Since the encryp-
tion box is performing all of the key management,
this is not a difficult problem.
The Key Storage Unit
8 USENIX -- Winter '91 -- Dallas, TX

Bellovin & Merritt Kerberos Limitations
A variety of technologies may be used to
implement encryption units, ranging from special
boards to dedicated microcomputers connected to
server hosts by physically-secure lines. If the latter
is used, there is the temptation to use its disk storage
to hold the service keys associated with the attached
host, but we feel that that is inadvisable. Any media
of that sort must be backed up, and the backups
must be carefully guarded. Such a high degree of
security may be impractical in some environments.
Instead, we suggest that keys be kept in volatile
memory, and downloaded from a secure keystore on
request, via an encryption-protected channel. Thus,
only one master key need be stored within the box;
this key could either be in non-volatile storage, or be
supplied by an operator when necessary.
More generally, the keystore is a secure, reli-
able repository for a limited amount of information.
A client of the keystore could package arbitrary data
to be retained by the keystore, and retrieved at a
later date. This data --- the service keys and tags, in
the case of an encryption unit, or even a conven-
tional Kerberos host --- would be uninterpreted by
the keystore. Storage and retrieval requests would
be authenticated by Kerberos tickets, of course.
Only encrypted transfer (KRB_PRIV) should be
employed, as insurance against disclosure of such
sensitive material.
As noted, the same keystore protocol could be
used to supply additional keys for new instances of
the same client. For example, a user pat could have
a separate instance pat.email, for receiving encrypted
electronic mail. The key for that instance would be
restricted to that user, of course.
Generally, transactions with the keystore are
initiated by the client. However, there is some ques-
tion about how to create the additional user keys, as
user workstations are not particularly good sources
of random keys. The best alternative is to provide a
(secure) random number service on the network.
When a new client instance is added, this service
would be consulted to generate the key; both Ker-
beros and the keystore would be told about the key.
SECURITY VALIDATION
Is Kerberos correct? By that we are asking if
there are bugs (or trapdoors!) in the design or
implementation of Kerberos, bugs that could be used
to penetrate a system that relies on Kerberos. Some
would say that by making the code widely available,
the implementors have enabled would-be penetrators
to gain a detailed knowledge of the system, thereby
simplifying their task considerably. We reject that
notion.
In the late nineteenth century, Kerckhoffs for-
mulated the basic principal under which the security
of cryptographic systems should be evaluated: all
details of the system design should be assumed to be
known by the adversary. Only cryptographic keys
specifically assumed to be secret should be unavail-
able to an attacker.[Kahn67, Kerc83] Given this basic
premise, the security of a cryptographic system is
evaluated based on concerted efforts at cryptanalysis.
Kerberos is designed primarily as an authentica-
tion system incorporating a traditional cryptosystem
(the Data Encryption Standard) as a component.
Never the less, the philosophy guiding Kerckhoffs'
evaluation criterion applies to the evaluation of the
security of Kerberos. The details of Kerberos's
design and implementation must be assumed known
to a prospective attacker, who may also be in league
with some subset of servers, clients, and (in the case
of hierarchically-configured realms) some authentica-
tion servers. Kerberos is secure if and only if it can
protect other clients and servers, beginning only with
the premise that these client and server keys are
secret, and that the encryption system is secure.
Moreover, in the absence of a central, trusted ``vali-
dation authority'', each prospective user of Kerberos
is responsible for judging its security. Of course, a
public discussion of system security and publication
of security evaluations will facilitate such judge-
ments.
By describing the Kerberos design in publica-
tions and making the source code publically avail-
able, the Kerberos designers and implementors at
Project Athena have made a commendable effort to
encourage just such a public system validation.
Obviously, this document is itself part of that pro-
cess. However, the system design and its implemen-
tation have undergone significant modification, in
part as a consequence of this public discussion. We
stress that each modification to the design and imple-
mentation results in a new system whose security
properties must be considered anew. (Examples of
such modifications are the incorporation of
hierarchically-organized servers and forwardable tick-
ets in Version 5.)
Hence, on-going modification of Kerberos
makes it a moving target for security validation
attempts. A detailed security analysis would thus be
premature. However, the proposed changes to Ker-
beros in the next few section are intended, not so
much to defeat specific attacks, as to facilitate the
validation process. In particular, these suggestions
are intended to make Kerberos more modular, in
design and implementation. Doing so should make
the security consequences of modifications more
apparant, and facilitate an incremental approach to
Kerberos security validation.
Message Encoding and Cut-and-Paste Attacks
The most simple analysis of the security of the Ker-
beros protocols should check that there is no possi-
bility of ambiguity between messages sent in dif-
ferent contexts. That is, a ticket should never be
USENIX -- Winter '91 -- Dallas, TX 9

Kerberos Limitations Bellovin & Merritt
interpretable as an authenticator, or vice versa. Such
an analysis depends on redundancy in the pre-
encryption binary encodings of each of the ticket and
authenticator information. Currently, that analysis
must be repeated with every modification to the pro-
tocol. This repetitive and often intricate analysis
would be unnecessary if standard encodings (such as
ASN.1)[ASN1, BER] were used. These encodings
should include the overall message type (such as
KRB_TGS_REP or KRB_PRIV). Together with rea-
sonable assumptions about the encryption layer (see
the next section), such an encoding scheme would
greatly simplify the protocol validation process, par-
ticularly as the protocol is modified or extended.
Some use of ASN.1 encodings has been
adopted for other reasons in Version 5. We rein-
force here that there are design principles other than
standards compatibility that motivate such a change.
The Encryption Layer
Version 4 of Kerberos uses the nonstandard PCBC
mode of encryption, propagating cipher block chain-
ing, in which plaintext block i + 1 is exclusive-or'ed
with both the plaintext and ciphertext of block i
before encryption. This mode was observed to have
poor propagation properties that permit message-
stream modification: specifically, if two blocks of
ciphertext are interchanged, only the corresponding
blocks are garbled on decryption. Version 5 replaces
PCBC mode with the standard CBC mode, cipher
block chaining, which exclusive-or's just the cipher-
text of block i with the plaintext of block i + 1 before
encryption. A checksum --- as of Draft 2, the exact
form had not been determined --- is used to detect
message modification. In order to ensure that dupli-
cate messages have different encryptions, random
initial ``confounders'' are added to some message
formats. In addition, Version 5 supports alternative
encryption algorithms as options.
Both the confounder and checksum mechanisms
are meant to augment the security of CBC encryp-
tion. They belong in a separate encryption layer, not
at the level of the Kerberos protocols themselves.
Further, the confounder mechanism should be
replaced by using the standard initial vector mechan-
ism of cipher-block chaining.[FIPS81, Davi89]
To prevent message-stream modification during
authenticated or private sessions, Version 5 uses a
timestamp field to prevent entire encrypted messages
from being replayed. This is another concern more
properly delegated to the encryption layer, where
chaining across the packets of the entire session is
the more standard mechanism. (Such chaining
avoids both the dependence on a clock and the need
to cache recent timestamps.)
Separating the Kerberos protocols from the
details of encryption would facilitate both validation
of the security of the Kerberos protocols, and
implementations and validations involving alternative
cryptosystems. Too much focus on mechanism,
while endemic to cryptographic protocol design,
leads away from the need to state the basic proper-
ties required of the encryption layer. We would sug-
gest the following adversarial analysis as the starting
point for such a specification: allow an adversary to
submit, one after the other, any number of messages
for encryption under an unknown key K. The adver-
sary also has the ability to take prefixes and suffixes
of known messages, exclusive-or known messages,
and encrypt or decrypt with known keys. At the end
of this process, the adversary should not be able to
produce any encrypted messages other than those
specifically submitted for encryption. Such an
analysis would preclude encryption schemes suscep-
tible to simple chosen-plaintext attacks, as described
in a previous section.
Given the intractability of reasoning about
DES, or of proving complexity properties of any
cryptosystem with bounded key size, such analyses
will be no guarantee of overall security. But they
can be used to preclude the existence of trivial cut-
and-paste attacks.[DeMi83, Moor88]
RECOMMENDED CHANGES TO THE
KERBEROS PROTOCOL
Below, we list our recommended changes to the Ker-
beros protocol. Our ranking is governed by our esti-
mate of the likelihood and consequences of the
attack, balanced against the difficulty of implement-
ing the modification.
a. A challenge/response protocol should be
offered as an optional alternative to time-
based authentication.
b. Use a standard message encoding, such as
ASN.1, which includes identification of the
message type within the encrypted data.
c. Alter the basic login protocol to allow for
handheld authenticators, in which {R}K C , for
a random R, is used to encrypt the server's
reply to the user, in place of the key K C
obtained from the user password. This allows
the login procedure to prompt the user with R,
who obtains {R}K C from the handheld device
and returns that value instead of the password
itself.
d. Mechanisms such as random initial vectors (in
place of confounders), block chaining and
message authentication codes should be left to
a separate encryption layer, whose
information-hiding requirements are clearly
explicated. Specific mechanisms based on
DES should be validated and implemented.
e. The client/server protocol should be modified
so that the multi-session key is used to nego-
tiate a true session key, which is then used to
protect the remainder of the session.
f. Support for special-purpose hardware should
10 USENIX -- Winter '91 -- Dallas, TX

Bellovin & Merritt Kerberos Limitations
be added, such as the keystore. More impor-
tantly, future enhancements to the Kerberos
protocol should be designed under the
assumption that a host, particularly a multi-
user host, may be using encryption and key-
storage hardware.
g. To protect against trivial password-guessing
attacks, the protocol should not distribute tick-
ets for users (encrypted with the password-
based key), and the initial exchange should
authenticate the user to the Kerberos server.
h. Support for optional extensions should be
included. In particular, an option to protect
against password-guessing attacks via eaves-
dropping may be a desirable feature.
ACKNOWLEDGEMENTS
We would like to thank D. Davis and T.H.
Foregger for their comments on an early draft. We'd
especially like to thank C. Neuman for his detailed
reviews of many versions of the paper, and his wil-
lingness to discuss the issues with us. W. Griffeth
helped us with preparation of the appendix on
Draft 3. Finally, we'd like to thank the Project
Athena and Kerberos development staff for their ini-
tial design and implementation of Kerberos, their
solicitation of comments, and their responsiveness to
our criticisms.
APPENDIX: VERSION 5 DRAFT 3
Draft 3 has gone a long way towards alleviating
our concerns. Many problems have been fixed, and
provisions have been made for compatible enhance-
ments to resolve other outstanding issues. These are
being refined in ongoing discussion. Still, some
issues remain unresolved or unaddressed. In addi-
tion, we raise new issues related to older areas of the
specification.
In a few places, we mention changes that may
be made in future revisions of the specification; the
reader is cautioned that these represent our under-
standing, and only our understanding, of a continuing
process.
With one exception, this summary omits areas
where the authors' intent was clear or was clarified
in private communications. That exception --- a way
to misuse weak checksums to subvert bidirectional
authentication --- we include to demonstrate the deli-
cacy inherent in the design and specification of
authentication protocols.
Draft 3 and Our Recommended Changes
We begin by reviewing our recommended changes in
light of Draft 3 and subsequent discussions with its
authors.
a. The KRB_AS_REQ/KRB_AS_REP and
KRB_TGS_REQ/KRB_TGS_REP exchanges
now provide challenge/response authentication
of the server to the client via a nonce field,
instead of depending on the workstation time.
For application servers, the e - data field in
the KRB_AP_ERR_METHOD error message
can be used by the server to signal the client
to use a challenge/response alternative to the
time-based kerberos authentication.
b. All encrypted data is labeled with the message
type prior to encryption, via full integration of
the ASN.1 standard. Although there were
many reasons for this decision, we applaud its
beneficial impact on security.
c. An optional padata field will probably be
added to the KRB_AS_REP to allow for
handheld authenticator protocol extensions.
d. As discussed, mechanisms such as random ini-
tial vectors (in place of confounders), block
chaining and message authentication codes are
now left to a separate encryption layer, with a
much clearer discussion of requirements and
of specific mechanisms based on DES.
e. Optional fields will probably be added to the
AP_REQ and AP_REP messages to support
the negotiation of true session keys.
f. Addition of optional fields (such as padata)
should facilitate extensions that exploit
special-purpose hardware.
g. The initial exchange still does not authenticate
the user to the Kerberos server. Thus, the
Kerberos equivalent of /etc/passwd must
be treated as public, and passwords must be
chosen and administered with password-
guessing attacks in mind. However, the
padata field facilitates optional implementa-
tion of such preauthentication mechanisms.
h. As above, several optional fields facilitate
extensions such as exponential-key exchange
to protect against password-guessing via
eavesdropping.
The following sections discuss some of the revisions
in Draft 3 in more detail, and raise some new issues.
Login Dialog
The login dialog has been enhanced to include
an additional authentication data field. This can be
used to support hand-held authenticators, pre-
encryption of the original request, and future exten-
sions. This is a significant enhancement, but we
regret that support for hand-held authenticators and
pre-encryption is not yet a part of the standard.
In particular, the optional field in the request
message can support some sort of pre-encryption.
For example, the nonce field can be sent both in the
clear and encrypted in the user's login key, thereby
demonstrating that the client is legitimate, and pre-
cluding remote collection of tickets encrypted with
the user's key. As discussed in the main body of
this paper, we feel such a mechanism should be
mandatory, not optional. Password-cracking
USENIX -- Winter '91 -- Dallas, TX 11

Kerberos Limitations Bellovin & Merritt
programs require just this sort of data; there is no
need to provide grist for their mill.
As currently released, a challenge-response dia-
log cannot be implemented by the Draft 3 reply for-
mat. While the request message possesses the
optional extra field, the reply does not, and hence
cannot carry the encrypted key. Adding this field
would also permit compatible support of exponential
key exchange, wherein each party must send a ran-
dom exponential. We understand that the optional
field will probably be added to the reply.
The Encryption and Checksum Layers
There is now a separate, well-defined encryp-
tion layer, with specified properties. Among these
are that the encryption module be capable of detect-
ing any tampering with the message. The only sup-
ported method, in this version, is a CRC-32 check-
sum sealed within the encrypted portion of the mes-
sage.
The encryption layer also reaps the benefit of
the ASN.1 encoding. Since the encoding includes a
length field, it is no longer possible for an attacker to
truncate a message, and present the shortened form
as a valid encrypted message. If a decision were
ever made to replace ASN.1 (say, with something
more efficient), this property would need to be
preserved.
The confounder has now been moved to the
encryption layer, but there is still some confusion of
function with the IV used by CBC-mode encryption.
As commonly used, an IV is a confounder (see, for
example, [Voyd83]); to hold it constant during a ses-
sion negates its purpose and thus requires the addi-
tional confounder. We suggest that the IV be used
as intended, and be incremented or otherwise altered
after each message. Initial values for it should be
exchanged during (or derived from) the authentica-
tion handshake. Apart from simplifying the
definition of the encryption function, this scheme
would also allow detection of message deletions by
interested applications.
It could be argued that requiring the IV to be
handled at a higher layer violates the layering we
have espoused. However, an IV is as much an attri-
bute of a cryptosystem as is a key. It would be rea-
sonable to encapsulate the definition of the IV into
the definition of the key object passed down to the
encryption layer.
The properties required of checksums are not as
well-defined. Three types are specified: CRC-32,
MD4 and MD4 encrypted with DES.[Rive90] How-
ever, no mention is made of their attributes, save that
some are labeled ``cryptographic''. This is a crucial
omission, as discussed below. A better classification
is whether or not a checksum is ``collision-proof'',
that is, whether or not an attacker can construct a
new message with the same checksum. The CRC-32
checksum is not collision-proof, while MD4 is
believed to be. Note that encrypting a checksum
provides very little protection; if the checksum is not
collision-proof and the data is public, an adversary
can compute the value and replace the data with
another message with the same checksum value.
(Several such attacks are indicated below.)
Weak Checksums and Cut-and-Paste Attacks
One of the major changes in Draft 3 was the
removal of encryption protection from the additional
tickets and authorization data that may be enclosed
with certain requests. These fields are protected by a
checksum sealed in the encrypted authenticator sent
with the request. Assume that the checksum algo-
rithm used is CRC-32. (This is permitted by a literal
reading of Draft 3, though we have learned that this
was not the intent of the authors.) With this
assumption, the existence of the ENC-TKT-IN-
SKEY option leads to a major security breach, and
in particular to the complete negation of bidirectional
authentication.
As usual, the client, possessing a valid ticket-
granting ticket, sends off a request for a new ticket
for some service S. The enemy intercepts this
request and modifies it. First, the ENC-TKT-IN-
SKEY bit is set. This specifies that the ticket, nor-
mally encrypted in S's key, should be encrypted in
the session key of the enclosed ticket-granting ticket.
Second, the attacker's own ticket-granting ticket is
enclosed. Obviously, the attacker knows its session
key. Finally, the additional authorization data field
is filled in with whatever information is needed to
make the CRC match the original version.
Consider what happens. The ticket-granting
service, seeing a valid request, sends back a ticket.
This ticket, encrypted in the enemy's key, will not
be intelligible to the real service, but of course, it
will not get that far. The legitimate client cannot tell
that the ticket is misencrypted; tickets are, almost by
definition, encrypted in a key known only to the
server and Kerberos. When the service is requested,
the enemy intercepts the request and unseals the
ticket. The client may request bidirectional authenti-
cation; however, since the attacker has decrypted the
ticket, the session key for that service request is
available. Consequently, the bidirectional authentica-
tion dialog may be spoofed without trouble.
A number of different factors interacted to
make this attack possible. One is obvious: the
ticket request was protected by what turned out to be
a weak checksum. If a collision-proof checksum
were used, the attack would be infeasible; the enemy
could not have generated the additional authorization
data field necessary to make the new request's
checksum match the original. But there are
subtleties here. First, if the additional tickets used
12 USENIX -- Winter '91 -- Dallas, TX

Bellovin & Merritt Kerberos Limitations
by ENC-TKT-IN-SKEY were encrypted (again), they
would have been adequately protected by the very
same CRC-32 checksum that was abused in the
attack. However, because of the encryption, the
enemy would be unable to either discern or match
the checksum. In other words, the context is critical;
merely refraining from re-encrypting some encrypted
data, while using the same checksum to protect it,
has led to a security breach. (Note: we have been
told that the designers intended to require that the
cname in the additional ticket match the name of the
server for which the new ticket is being requested.
This requirement would still permit the intended use
of the option, but would foil the attack we describe.
Apparently, the requirement was inadvertently omit-
ted from Draft 3.)
A similar attack may be possible using the
REUSE-SKEY option. This option was designed for
multicast key distribution; with a weak checksum, an
attacker can abuse it to generate a service ticket
whose key is known. The REUSE-SKEY option
also permits a related, albeit less serious, attack. If
two tickets, T1 and T2, share the same key, the
attacker can intercept a request for one service, and
redirect it to the other. Since the two tickets share
the same key, the authenticator will be accepted.
Just how damaging this possibility is depends on
what sorts of services might want to share the same
key. If, say, a file server and a backup server were
invoked this way, an attacker might redirect some
requests to destroy archival copies of files being
edited. A solution to this particular attack is to
include either the service name, a collision-proof
checksum of the ticket, or both, in the authenticator.
To be sure, Draft 3 explicitly warns against using
tickets with DUPLICATE-SKEY set for authentica-
tion. Servers that obey this restriction are not
vulnerable to this attack. Also, we have been told
that the REUSE-SKEY option will probably be omit-
ted in future revisions of the protocol.
A last attack of this sort can occur if the
attacker substitutes a different ticket for the legiti-
mate one in key distribution replies from Kerberos.
The encrypted part of such a message does not con-
tain any checksum to validate that the message was
not tampered with in transit. While this appears to
be more a denial-of-service attack than a penetration,
it would be useful for the client to know this
immediately.
Two issues underly this list of potential attacks.
As discussed, weak checksums (encrypted but not
collision-proof, and over public data) allow an adver-
sary to paste together legitimate-looking messages.
Message integrity via strong checksums and/or
encryption should be extended to as many protocol
messages (and as many fields) as possible.
Second, the REUSE-SKEY and ENC-TKT-IN-
SKEY options ``overload'' the basic protocol, in that
tickets may now share session keys or be encrypted
in keys other than the service. It is possible that
there are other ways an attack could exploit the
ensuing ambiguities. These options are intended for
very constrained uses, not general authentication;
they should not be so intimately integrated into the
basic authentication protocol. The same purposes
would be served by adding separate message types
that cannot be misinterpreted as tickets, and using
keys that are derived from but are not identical to
those used in the basic protocol.
Even then, an analysis of the final standard is
needed, to assure that a minor extension has not
negated a security-critical assumption. (E.g., the
basic Kerberos protocol assumes that no two tickets
share a session key, and that tickets are always
encrypted with the server's key.)
KRB_SAFE and KRB_PRIV Messages
The KRB_SAFE and KRB_PRIV messages
employ the session key distributed with the ticket for
integrity-checking and privacy, respectively. Draft 3
dictates that both use time-of-day values to guard
against replay, which may be problematic.
Currently, the resolution of the timestamp is limited
to 1 millisecond, which is far too coarse for many
applications. (This and other timestamps in the pro-
tocol will probably be changed to microsecond reso-
lution.)
A second problem area is the need for a cache
of recently-used timestamps. Obviously, if such
messages are used for things like file system
requests, the size of the cache could rapidly become
unmanageable. Furthermore, if two authenticated or
encrypted sessions run concurrently, the cache must
be shared between them, or messages from one ses-
sion can be replayed into the other.
Both problems can be solved if the idea of a
timestamp is abandoned in favor of sequence
numbers. A random initial sequence number can be
transmitted with the authenticator and/or in the
KRB_AP_REP message; after each authenticated
message is sent, it would, of course, be incremented.
The cache is then a simple last-message counter.
This mechanism also provides the ability to detect
deleted messages, by watching for gaps in sequence
number utilization. And, since each session would
have its own initial sequence number, it would not
be possible for an attacker to perform cross-stream
replays, and concurrent access to a common cache is
not necessary. (This advantage would be gained
even with timestamps if true session keys were
used.) It is likely that in a future revision, sequence
numbers will be provided as an alternative to the use
of timestamps.
USENIX -- Winter '91 -- Dallas, TX 13

Kerberos Limitations Bellovin & Merritt
Authenticators
Draft 3 still calls for the use of authenticators
to guard against ticket replay. However, there is
now a provision for the server to specify that addi-
tional authentication is required, and an optional data
field for this has been added to the KRB_ERROR
reply message. This can be used to implement
challenge/response schemes.
The authenticator should have some other fields
added to it, some of them optional. As noted earlier,
it must contain a collision-proof checksum linking it
to the ticket, and an optional initial sequence
number. The latter would be used by any applica-
tions that might wish to exchange encrypted or
authenticated messages.
The authenticator is also the right place to
negotiate a true session key. We propose adding a
new field for it to both the authenticator and the
KRB_AP_REP message. The actual session key
could be formed by an exclusive-or of the multises-
sion key associated with the ticket, a randomly-
generated field in the authenticator, and a similar
field in the reply message. Note that this retains a
measure of compatibility with the current scheme: if
the two optional fields are not present, the multi-
session key will be used as the actual session key.
Negotiation of true session keys, initial
sequence numbers, and confounders or IV's could be
combined in one standard mechanism, perhaps sub-
sumed as encryption-specific subfields of the session
key fields.
Inter-Realm Authentication
Inter-realm authentication is still problematic.
Granted that static configuration files can tell a Ker-
beros server who its parent is, and even the identities
of all of its children, there is still no scalable
mechanism to learn of grandchildren or more distant
descendants.
To be sure, it is apparently the intention of the
authors that the Internet's domain name space be
used to denote realms, and --- implicitly --- the
hierarchy of servers. It is far from clear to us that
the two hierarchies coincide. Furthermore, such
usage is not required. No alternative routing
mechanism has been suggested.
Additionally, there are several pieces of the
protocol that are unclear or simply do not work with
inter-realm tickets. For example, ENC-TKT-IN-
SKEY and REUSE-KEY require the ticket-granting
server to decrypt a ticket. It cannot do this if the
ticket had been issued by another realm. Presum-
ably, of course, the request could be sent to the other
realm's ticket-granting server, but it may not possess
the necessary key to generate the new ticket.
NEW RECOMMENDED CHANGES
Below, we include a new list of recommended
changes, beyond those we have indicated are likely
to be adopted. The first two are repeated from our
earlier list, and are now (or will be) implementable
as options; we repeat them here to stress our belief
that they should be a mandatory part of the protocol.
a. Alter the basic login protocol to allow for
challenge/response handheld authenticators.
b. The initial exchange should authenticate the
user to the Kerberos server, to complicate
password-guessing attacks.
c. Strong checksums, encryption, and additional
fields should be used to assure integrity of the
basic Kerberos messages. (For example, tick-
ets should be tied more closely to the contexts
in which they are used, by including service
names in the ticket, and the encrypted part of
KRB_AS_REP and KRB_TGS_REP should
contain collision-proof checksums of the tick-
ets.)
d. Protocol extensions not related to basic
authentication (the ENC-TKT-IN-SKEY and
REUSE-SKEY options) should be omitted or
use distinct message and ticket formats.
References
FIPS81. ``DES Modes of Operation,'' Federal
Information Processing Standards Publication
81 (December 1980). National Bureau of Stan-
dards, U.S. Department of Commerce
ASN1. ``Information Processing Systems --- Open
Systems Interconnection --- Specification of
Abstract Syntax Notation One (ASN.1),'' Inter-
national Standard 8824 (1987). International
Organization for Standardization and Interna-
tional Electrotechnical Committee
BER. ``Information Processing Systems --- Open
Systems Interconnection --- Specification of
Basic Encoding Rules for Abstract Syntax
Notation One (ASN.1),'' International Standard
8825 (1987). International Organization for
Standardization and International Electrotechni-
cal Committee
Beke82. H. Beker and F. Piper, Cipher Systems,
John Wiley & Sons (1982).
Brya88. B. Bryant, Designing an Authentication
System: A Dialogue in Four Scenes, Draft
February 8, 1988.
Davi89. D.W. Davies and W.L. Price, Security for
Computer Networks, John Wiley & Sons
(1989). Second Edition
Davi90. D. Davis and R. Swick, Workstation Ser-
vices and Kerberos Authentication at Project
Athena, MIT Laboratory for Computer Science
Technical Memorandum 424 (February 1990).
Deav85. C.A. Deavours and L. Kruh, Machine
14 USENIX -- Winter '91 -- Dallas, TX

Bellovin & Merritt Kerberos Limitations
Cryptography and Modern Cryptanalysis,
Artech House (1985).
DeMi83. R. DeMillo and M. Merritt, ``Protocols
for Data Security,'' Computer 16(2) pp. 39-50
(February 1983).
Diff76. W. Diffie and M.E. Hellman, ``New Direc-
tions in Cryptography,'' IEEE Transactions on
Information Theory 6 pp. 644-654 (November,
1976).
Gram84. F.T. Grampp and R.H. Morris, ``Operat-
ing System Security,'' AT&T Bell Laboratories
Technical Journal 63(8, Part 2) pp. 1649-1672
A&T, (October, 1984).
Kahn67. D. Kahn, Codebreakers: The Story of
Secret Writing, Macmillan (1967).
Kerc83. A. Kerckhoffs, La Cryptographie Mili-
taire, Libraire Militaire de L. Baudoin & Cie.,
Paris (1883).
Kohl89. J. Kohl, B. Clifford Neuman, and J.
Steiner, The Kerberos Network Authentication
Service, MIT Project Athena (November 6,
1989). Version 5, Draft 2
Kohl90. J. Kohl, B. Clifford Neuman, and J.
Steiner, The Kerberos Network Authentication
Service, MIT Project Athena (October 8, 1990).
Version 5, Draft 3
LaMa. B.A. LaMacchia and A.M. Odlyzko, Com-
putation of Discrete Logarithms in Prime
Fields, (Manuscript in preparation)
Loma89. T.M.A. Lomas, L. Gong, J.H. Saltzer,
and R.M. Needham, ``Reducing Risks from
Poorly Chosen Keys,'' Operating Systems
Review 23(5) pp. 14-18 ACM, (December
1989).
Mill87. S.P. Miller, B.C. Neuman, J.I. Schiller,
and J.H. Saltzer, ``Kerberos Authentication and
Authorization System,'' in Project Athena
Technical Plan, (December 1987). Section
E.2.1
Mill88. D.L. Mills, ``Network Time Protocol,''
RFC 1059 (July 1988).
Mill89. D.L. Mills, ``Network Time Protocol,''
RFC 1119 (September 1989).
Moor88. J.H. Moore, ``Protocol Failures in Cryp-
tosystems,'' Proc. IEEE 76(5) pp. 594-602
(May 1988).
Morr79. R. Morris and K. Thompson., ``UNIX
Password Security,'' Communications of the
ACM 22(11) p. 594 (November 1979).
Morr85. R.T. Morris, ``A Weakness in the 4.2BSD
TCP/IP Software,'' Computing Science Techni-
cal Report No. 117, AT&T Bell Laboratories,
Murray Hill, New Jersey (February 1985).
Post80. J.B. Postel, ``User Datagram Protocol.,''
RFC 768 (August 28, 1980).
Post81. J.B. Postel, ``Transmission Control Proto-
col.,'' RFC 793 (September 1981).
Post83. J.B. Postel and K. Harrenstien, ``Time Pro-
tocol.,'' RFC 868 (May 1983).
Rive90. R.L. Rivest, ``MD4 message digest algo-
rithm,'' RFC 1186 (October 1990).
Salt90. J.H. Saltzer, private communication June
19, 1990.
Stei88. J. Steiner, C. Neuman, and J.I. Schiller,
``Kerberos: An Authentication Service for Open
Network Systems,'' in Proc. Winter USENIX
Conference, , Dallas (1988).
Stol88. C. Stoll, ``Stalking the Wiley Hacker,''
Communications of the ACM 31(5) p. 484 (May
1988).
Voyd83. V.L. Voydock and S.T. Kent, ``Security
Mechanisms in High-Level Network Proto-
cols,'' ACM Computer Surveys 15(2) pp. 135-
171 (June, 1983).
Steven M. Bellovin received a
B.A. degree from Columbia
University, and an M.S. and
Ph.D. in Computer Science
from the University of North
Carolina at Chapel Hill. While
a graduate student, he wrote the
original version of pathalias
and helped create netnews.
However, the former is not an
indictable offense, and the
statute of limitations on the latter has expired.
Nevertheless, he is still atoning for both actions. He
has been at AT&T Bell Laboratories since 1982,
where he does research in networks, security, and
why the two don't get along. He may be reached
electronically as smb@ulysses.att.com; those
who prefer to murder trees may send scraps of paper
to Room 3C-536B, AT&T Bell Laboratories, 600
Mountain Avenue, Murray Hill, NJ 07974, U.S.A.
Michael Merritt received a B.S.
from Yale University, and an
M.S. and Ph.D. in Information
and Computer Science from the
Georgia Institute of Technol-
ogy. His dissertation, "Crypto-
graphic Protocols", developed
techniques for exploring secu-
rity properties of distributed
algorithms. He has been at
AT&T Bell Laboratories since
1983, where he does research in distributed systems
and security. His email address is
mischu@research.att.com; paper to Room
3D-458, AT&T Bell Laboratories, 600 Mountain
Avenue, Murray Hill, NJ 07974, U.S.A.
USENIX -- Winter '91 -- Dallas, TX 15

16 USENIX -- Winter '91 -- Dallas, TX