limitations of the kerberos authentication system†

8/6/2019 Limitations of the Kerberos Authentication System

1/16

Limitations of the KerberosAuthentication System

Steven M. Bellovin AT&T Bell LaboratoriesMichael Merritt AT&T Bell Laboratories

ABSTRACT

The Kerberos authentication system, a part of MITs Project Athena, has beenadopted by other organizations. Despite Kerbeross many strengths, it has a number oflimitations and some weaknesses. Some are due to specifics of the MIT environment;others represent deficiencies in the protocol design. We discuss a number of suchproblems, 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 ofProject 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 andweaknesses; a decision to adopt or reject it cannotproperly be made without considering these issues.(A limitation is a feature that is not as general as onemight like, while a weakness could be exploited byan attacker to defeat the authentication mechanism.)Some improvements can be made within the currentdesign. Support for optional mechanisms wouldextend Kerbeross 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 thebasic assumptions differ, the authentication systemmay need to be changed as well. Other problems aresimply deficiencies in the protocol design. Some ofthese are corrected in the proposed Version 5 ofKerberos,[Kohl89] but not all. Even the solved prob-lems merit discussion, since the code for Version 4has been widely disseminated. Finally, some prob-lems with Kerberos are not solvable without employ-ing special-purpose hardware, no matter what thedesign of the protocol. We will consider each ofthese areas in turn.

We wish to stress that we are not suggestingthat Kerberos is useless. Quite the contrary anattacker capable of carrying out any of the attackslisted here could penetrate a typical network of UNIXsystems 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 ofComputer 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 onpractical solutions to the network authenticationproblem. The elegant protocol design and wide avai-lability of the code has galvanized a wide audience.Far from a condemnation, our critique is intended tocontribute to an understanding of Kerbeross proper-ties and to influence its evolution into a tool ofgreater power and utility.

Several of the problems we point out are men-tioned in the original Kerberos paper orelsewhere.[Davi90] For some of these, we present pro-tocol improvements that solve, or at least ameliorate,the problem; for others, we place them squarely inthe context of the intended Kerberos environment.

Version 5, Draft 3

Since this paper was written, a new draft of theVersion 5 protocol has been released, and a finalspecification is promised.[Kohl90] Many of the prob-lems we discuss herein have been corrected. Othersremain, and we have found a few new ones. Theultimate resolution of these issues is unclear as wego to press. Consequently, a brief analysis ofDraft 3 is presented in an appendix, rather than inthe main body of the document.

Focus on Security

Kerberos is a security system; thus, though weaddress issues of functionality and efficiency, ourprimary emphasis is on the security of Kerberos in ageneral environment. This means that security-critical assumptions must be few in number andstated clearly. For the widest utility, the networkmust be considered as completely open. Specifically,the protocols should be secure even if the network is

USENIX Winter 91 Dallas, TX 1


2/16

Kerberos Limitations Bellovin & Merritt

under the complete control of an adversary.1 Thismeans that defeating the protocol should require theadversary to invert the encryption algorithm or tosubvert a principal specifically assumed to betrustworthy. Only such a strong design goal can jus-tify the expense of encryption. (No steel doors inpaper walls.) We believe that Kerberos can meetthis ambitious goal with only minor modifications,

retaining its essential character.Some of our suggestions bear a performance

penalty; others complicate the design of suggestedenhancements. As more organizations make use ofKerberos, pressures to enhance or augment its func-tionality and efficiency will increase. Security hasreal costs, and the benefits are intangible. Theremust be a continuing and explicit emphasis on secu-rity as the overriding requirement.

Validation

It is not sufficient to design and implement asecurity system. Such systems, though apparently

adequate when designed, may have serious flaws.Consequently, systems must be subjected to thestrongest scrutiny possible. A consequence of this isthat they must be designed and implemented in amanner that facilitates such scrutiny. Kerberos has anumber of problems in this area as well.

WHATS A KERBEROS?

Before discussing specific problem areas, it ishelpful to review Kerberos Version 4. Kerberos isan authentication system; it provides evidence of aprincipals identity. A principal is generally either auser or a particular service on some machine. Aprincipal consists of the three-tuple

.

If the principal is a user a genuine person theprimary name is the login identifier, and the instanceis either null or represents particular attributes of theuser, i.e., root . For a service, the service name isused as the primary name and the machine name isused as the instance, i.e., rlogin.myhost . Therealm is used to distinguish among different authen-tication domains; thus, there need not be one giant and universally trusted Kerberos databaseserving an entire company.

1The 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 meansgenerally true. Consider, for example, a situation wheregeneral-purpose hosts also function as routers, and packetmodification or deletion become significant concerns.

Table 1: Notation

c client principals server principaltgs ticket-granting server

Kx private key of xKc,s session key for c and s{in f o}Kx in f o encrypted in key Kx{Tc,s }Ks Encrypted ticket for c to use s{A c }Kc,s Encrypted authenticator for c to

use saddr clients 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 assortedinformation identifying the principal, encrypted inthe private key of the service. (Notation is summar-ized in Table 1.)

{Tc,s }Ks = {s, c, addr, timestamp, li f etime, Kc,s }Ks

Since only Kerberos and the service share the privatekey Ks, the ticket is known to be authentic. Theticket contains a new private session key, Kc,s ,known to the client as well; this key may be used toencrypt transactions during the session.2

To guard against replay attacks, all ticketspresented are accompanied by an authenticator:

{A c }Kc,s = {c, addr, timestamp}Kc,s

This is a brief string encrypted in the session keyand containing a timestamp; if the time does notmatch the current time within the (predetermined)clock skew limits, the request is assumed to befraudulent.

For services where the client needs bidirectionalauthentication, the server can reply with

{timestamp + 1}Kc,s

This demonstrates that the server was able to readtimestamp from the authenticator, and hence that itknew Kc,s; that in turn is only available in the ticket,which is encrypted in the servers private key.

Tickets are obtained from the TGS by sendinga request

s , {Tc,tgs }Ktgs , {A c }Kc,tgs

In other words, an ordinary ticket/authenticator pairis used; the ticket is known as the ticket-granting

2Technically speaking, Kc,s is a multi-session key, sinceit is used for all contacts with that server during the life ofthe ticket.

2 USENIX Winter 91 Dallas, TX


3/16

Bellovin & Merritt Kerberos Limitations

ticket. The TGS responds with a ticket for server sand a copy of Kc,s , all encrypted with a private keyshared by the TGS and the principal:

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

The session key Kc,s is a newly-chosen random key.

The key Kc,tgs and the ticket-granting ticketitself, are obtained at session-start time. The client

sends a message to Kerberos with a principal name;Kerberos responds with

{Kc,tgs ,{Tc,tgs }Ktgs }Kc

The client key Kc is derived from a non-invertibletransform of the users typed password. Thus, allprivileges depend ultimately on this one key.

Note that servers must possess private keys oftheir own, in order to decrypt tickets. These keysare stored in a secure location on the serversmachine.

THE KERBEROS ENVIRONMENT

The Project Athena computing environmentconsists of a large number of more or lessanonymous workstations, and a smaller number oflarge 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 disksare effectively read-only; they contain no long-termuser data. Furthermore, they are not physicallysecure; someone so inclined could remove, read, oralter any portion of the disk without hindrance.

Within this environment the primary need is foruser-to-server authentication. That is, when a user

sits down at a workstation, that person needs accessto private files residing on a server. The workstationitself has no such files, and hence has no need tocontact the server or even to identify itself.

This is in marked contrast to a typical UNIXsystems view of the world. Such systems do havean identity, and they do own files. Assorted networkdaemons transfer files in the background, clock dae-mons perform management functions, electronic mailand news arrives, etc. If such a machine relied onservers to store its files, it would have to assert, andpossibly prove, an identity when talking to theseservers. The Project Athena workstations are neithercapable 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? Simplythis: 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-peersystem; it is not intended to be used by one

3We regard this as a feature, not a bug.

computers daemons when contacting another com-puter. Attempting to use Kerberos in such a modecan cause trouble.4

We make this statement for several reasons.First and foremost, typical computer systems do nothave a secure key storage area. In Kerberos, a plain-text key must be used in the initial dialog to obtain aticket-granting ticket. But storing plaintext keys in a

machine is generally felt to be a bad idea;[Morr79] if aKerberos key that a machine uses for itself iscompromised, the intruder can likely impersonateany user on that computer, by impersonating requestsvouched for by that machine (i.e., file mounts orcron jobs).5 Additionally, the session keys returnedby the TGS cannot be stored securely; of necessity,they are stored in some area accessible to root .Thus, if the intruder can crack the protectionmechanism on the local computer or, perhapsmore to the point, work around it for some limitedpurposes 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 limitedin lifetime and scope; nevertheless, one does notwish these keys exposed.

This points out a second flaw when multi-usercomputers employ Kerberos, either on their ownbehalf or for their users: the cached keys are acces-sible to attackers logged in at the same time. In aworkstation environment, only the current user hasaccess to system resources; there is little or no needeven to enable remote login to that workstation.There are many reasons for this; a consequence,though, is that the intruder simply cannot approachthe safe door to try to pick its lock.6 Only when thelegitimate 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. Witha multi-user computer, on the other hand, an attackerhas concurrent access to the keys if there are flaws inthe hosts security.

There are two other minor flaws in Kerberosdirectly attributable to the environment. First, thereis some question about where keys should be cached.Since all of the Project Athena machines have localdisks, the original code used /tmp . But this ishighly insecure on diskless workstations, where/tmp exists on a file server; accordingly, amodification was made to store keys in shared

memory. However, there is no guarantee that sharedmemory is not paged; if this entails network traffic,

4More precisely, Kerberos is not a host-to-host protocol.In Version 5, it has been extended to support user-to-userauthentication. [Davi90]

5Recall that we are assuming here that the machine and hence its superuser needs an identity of its own.

6On Project Athena machines, remote access to mostworkstations is in fact disabled.



4/16


an intruder can capture these keys.

Finally, the Kerberos protocol binds tickets toIP addresses. Such usage is problematic on onmulti-homed hosts (i.e., hosts with more than one IPaddress). Since workstations rarely have multipleaddresses, this feature intended to enhance secu-rity was not a problem at MIT. Multi-user hostsoften do have multiple addresses, however, and can-

not live with this limitation. This problem has beenfixed in Version 5.

PROTOCOL WEAKNESSES

Replay Attacks

The Kerberos protocol is not as resistant topenetration as it should be. A number of weaknessesare apparent; the most serious is its use of an authen-ticator to prevent replay attacks.

The authenticator relies on use of a timestampto guard against reuse. This is problematic forseveral reasons. The claim is made that no replaysare likely within the lifetime of the authenticator

(typically five minutes). This is reinforced by thepresence of the IP address in both the ticket and theauthenticator. We are not persuaded by this logic.An intruder would not start by capturing a ticket andauthenticator, and then develop the software to usethem; rather, everything would be in place before theticket-capture was attempted. Let us consider twoexamples.

Some years ago, Morris described an attackbased on the slow increment rate of the initialsequence number counter in some TCPimplementations.[Morr85] He demonstrated that it waspossible, under certain circumstances, to spoof one

half of a preauthenticated TCP connection withoutever seeing any responses from the targeted host. Ina Kerberos environment, his attack would still workif accompanied by a stolen live authenticator, but notif 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 ofvaluable tickets would be exposed by such a session,notably the one used to mount the users home direc-tory. Note that the lifetime of the authenticators 5 minutes contributes considerably to this attack.

Further, the proposed Version 5 of Kerberosanticipates alternative communication protocols in

which such replays may be trivial to implement. IfKerberos is to be considered as a general-purposeutility, it must make few security-critical assump-tions about the underlying network, and those mustbe explicit.

It has been suggested that the proper defense isfor the server to store all live authenticators; thus, anattempt to reuse one can be detected.[Stei88] In fact,the original design of Kerberos required such

caching, though this was never implemented. (Whilethat is a feature of the implementation rather than ofthe 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 isdifficult for TCP-based[Post81] servers to storeauthenticators. Servers generally operate by forking

a separate process to handle each incoming request.The child processes do not share any memory withthe parent process, and thus have no convenient wayto inform it and hence any other child servers of the value of the authenticator used. There are anumber of obvious solutions pipes, authenticatorservers, shared memory segments and the like butall are awkward, and some even raise authenticationquestions of their own. To date, we know of nomulti-threaded server implementation which cachesauthenticators.

UDP-based[Post80] query servers can store theauthenticators more easily, as a single process gen-

erally handles all incoming requests; however, theymight have problems with legitimate retransmissionsof the clients request if the answer was lost. (UDPdoes not provide guaranteed delivery; thus, allretransmissions happen from application level, andare visible to the application.) Legitimate requestscould be rejected, and a security alarm raised inap-propriately. One possible solution would be for theapplication to generate a new authenticator whenretransmitting a request; were it not for the otherweaknesses of the authenticator scheme, this wouldbe acceptable.

Secure Time Services

As noted, authenticators rely on machinesclocks being roughly synchronized. If a host can bemisled about the correct time, a stale authenticatorcan be replayed without any trouble at all. Sincesome time synchronization protocols areunauthenticated,[Post83, Mill88] and hosts are still usingthese protocols despite the existence of betterones,[Mill89] such attacks are not difficult.

The design philosophy of building an authenti-cation service on top of a secure time service is itselfquestionable. That is, it may not make sense tobuild an authentication system assuming an already-authenticated underlying system. Furthermore, while

spoofing an unauthenticated time service may be adifficult programming task, it is not cryptographi-cally difficult.7 Using time-based protocols in asecure fashion means thinking through all theseissues carefully and making the appropriate

7In some environments, programming is not even neces-sary. Low-powered fake WWV transmitters are not hardto build, and, if properly located, could easily block outthe legitimate signal.



5/16


synchronization an explicit part of the protocol. AsKerberos is proposed for more varied environments,its dependence on a secure time service becomesmore problematic and must be stressed.

As an alternative, we propose the use of achallenge/response authentication mechanism. As isdone today, the client would present a ticket, thoughwithout an authenticator. The server would respond

with a nonce identifier encrypted with the sessionkey Kc,s; the client would respond with some func-tion of that identifier, thereby proving that itpossesses the session key.

Such an implementation is not without its costs,of course. An extra pair of messages must beexchanged each time a ticket is used, which rules outthe possibility of authenticated datagrams. Moreseriously, 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. (Thecomplexity of managing outstanding challenges may

be comparable to that needed to cache live authenti-cators the trade-off is not between a stateful and astateless protocol, but in managing two kinds ofstate.)

There is a signficant philosophical differencebetween the two techniques, however. In the currentKerberos implementation, with its assumptions aboutthe network environment, retained state is onlynecessary to enhance security. Thechallenge/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/responsethroughout, a possible compromise is to extend theprotocol with a challenge/response option. Thisoption could be used, for example, to authenticatethe user in the initial ticket-granting ticket exchangeand to access a time service.8 Subsequent client-server interactions could use the current time-basedprotocol. But synchronizing the servers remains aproblem; not synchronizing them will lead to denialof service, and if they access the time service as aclient, they must somehow obtain and store a ticketand key to authenticate it. (See above on storingkeys in servers.) Given these complexities and pos-sible weaknesses, it would seem reasonable to allowany service to insist on the challenge/responseoption.

Summarizing, we emphasize that the security ofKerberos depends critically on synchronized clocks.In essence, the Kerberos protocols involve mutualtrust among four parties: the client, server, authenti-cation server and time server.

8This was suggested to us by Clifford Neuman.

Password-Guessing Attacks

A second major class of attack on the Kerberosprotocols involves an intruder recording login dialogsin order to mount a password-guessing assault.When a user requests Tc,tgs (the ticket-grantingticket), the answer is returned encrypted with Kc , akey derived by a publicly-known algorithm from theusers password. A guess at the users password can

be confirmed by calculating Kc and using it todecrypt the recorded answer. An intruder who hasrecorded many such login dialogs has good odds offinding several new passwords; empirically, users donot pick good passwords unless forced to.[Morr79,Gram84, Stol88]

We propose the use of exponential keyexchange[Diff76] to provide an additional layer ofencryption. Without describing the algorithm indetail, it involves the two parties exchangingnumbers 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 wouldprevent a passive wiretapper from accumulating thenetwork equivalent of /etc/passwd . Whileexponential key exchange is normally vulnerable toactive wiretaps, such attacks are comparatively rare,especially if dedicated network routers are used.

Apart from licensing issues exponential keyexchange is protected by a U.S. patent using ithas its costs. LaMacchia and Odlyzko[LaMa] havedemonstrated that exchanging small numbers is quiteinsecure, while using large ones is expensive in com-putation time. Additionally, we have added extramessages to the login dialog, and imposed therequirement for considerable extra state in the server.

Given the trend towards hiding even encrypted pass-words on UNIX systems, and given estimates that halfof all logins at MIT are used within a two-weekperiod, the investment may be justifiable. Perhapsthe best solution is to support this feature as adomain-specific option.

Even exponential key exchange will not preventall password-guessing attacks. Depending on howcarefully the Kerberos logs are analyzed, an intruderneed not even eavesdrop. Requests for tickets arenot themselves encrypted; an attacker could simplyrequest ticket-granting tickets for many differentusers. 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 Kc , providing aminimal authentication of the user to Kerberos, suchthat true eavesdropping would be required to mountthis attack. (As we are preparing this manuscript, just such a suggestion is being hotly debated on theKerberos mailing list. We originally overlooked analternative avenue for mounting a password-guessingattack. Clients may be treated as services, and



6/16


tickets to the client, encrypted by Kc , may beobtained by any user. This capability has been sug-gested as the basis for user-to-user authentication andand enhanced mail services.[Salt90] But any suchscheme would seem to require repeated re-entry ofthe users password, an inconvenience we suspectwill not be tolerated. We would prefer to providethe same functionality by having clients register

separate instances as services, with truly randomkeys. Keys could be supplied to the client by thekeystore, described below.)

An alternative approach is a protocol describedby Lomas, Gong, Saltzer, and Needham.[Loma89]They present a dialog with a server that does notexpose 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 simplefor an intruder to replace the login command with

a version that records users passwords beforeemploying them in the Kerberos dialog. Such anattack negates one of Kerbeross primary advantages,that passwords are never transmitted in cleartext overa network. While this problem is not restricted toKerberos environments, the Kerberos protocol makesit difficult to employ the standard countermeasure:one-time passwords.

A typical one-time password scheme employs asecret key shared between a server and some devicein the users possession. The server picks a randomnumber and transmits it to the user. Both the serverand the user (with the aid of the device) encrypt thisnumber using the secret key; the result is transmitted

back to the server. If the two computed valuesmatch, the user is assumed to possess the appropriatekey.

Kerberos makes no provision for such achallenge/response dialog at login time. The serversresponse to the login request is always encryptedwith Kc, a key derived from the users password.Unless a smart card is employed that understandsthe entire Kerberos protocol, this precludes any useof one-time passwords.

An alternative (first suggested to us by T.H.Foregger) requires that the server pick a randomnumber R, and use Kc to encrypt R. This value

{R}Kc , rather than Kc , would be used to encrypt theservers response. R would be transmitted in theclear to the user. If a hand-held authenticator was inuse, the user would employ it to calculate {R}Kc;otherwise, the login program would do it automatic-ally.

Several objections may be raised to thisscheme. First, hand-held authenticators are oftenthought 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 ofour scheme is quite low, simply one extra encryptionon each end.

A second, more cogent, objection is that if theclients workstation cannot be trusted with a userspassword, 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 thelogin password is much more serious than the cap-ture of a few limited-lifetime session keys. Thisproblem cannot be solved without the use ofspecial-purpose hardware, a subject we shall returnto below.

Finally, it has been pointed out that a user canalways supply a known-clean boot device, or bootvia the network. The former we regard as improb-able in practice unless removable media areemployed; the latter is insecure because the boot pro-tocols are unauthenticated.

Inter-Session Chosen Plaintext AttacksAccording to the description in the Version 5draft,[Kohl89] servers using the KRB_PRIV format aresusceptible to a chosen plaintext attack. (A chosen-plaintext attack is one where an attacker may chooseall or part of the plaintext and, typically, use theresulting cipher text to attack the cipher. Here weuse the cipher text to attack the protocol. Mail andfile servers are examples of servers susceptible tosuch attacks.) Specifically, the encrypted portion ofmessages 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 encryptionsof prefixes, ifDATA has the form

(AUTHENTICATOR , CHECKSUM, REMAINDER)

then a prefix of the encryption of X with the sessionkey is the encryption of

(AUTHENTICATOR , CHECKSUM) ,

and can be used to spoof an entire session with theserver.

It may be argued that most servers are not sus-ceptible to chosen plaintext attacks. Given that thereare easy counters to this attack, it seems foolish toadvocate 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 whichthe encrypted portion of the KRB_PRIV message isof the form

(length(DATA) , DATA , msectime, hostaddress,timestamp + direction, PAD)

as the leading length(DATA) field disrupts theprefix-based attack. We leave it to the reader to



7/16


discover a more complicated chosen ciphertext attackagainst this format, even allowing for the fact thatVersion 4 uses the nonstandard PCBC mode ofencryption. (Hint: assume the initial vector is fixedand public.) However, it is interesting to note thatthe order of concatenation of message fields canhave security-critical implications. We return to thisquestion 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 serviceticket and is used in the multiple sessions betweenthe client and server that use that ticket. Thus, it ismore 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 ofthe Kerberos protocol. This limits the exposure tocryptanalysis[Kahn67, Beke82, Deav85] of the multi-session key contained in the ticket, and precludesattacks which substitute messages from one session

in another. (The chosen-plaintext attack of the previ-ous section is one such example.) The session keycould 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 andspace. That is, tickets are usable only within therealm of the ticket-granting server, and only for alimited period of time. The first is necessary to thedesign of Kerberos; the TGS would not have anykeys in common with servers in other realms. Thelatter is a security measure; the longer a ticket is in

use, the greater the risk of it being stolen orcompromised.

A further restriction on tickets, in Version 4, isthat they cannot be forwarded. A user may obtaintickets at login time, and use these to log in to someother host; however, it is not possible to obtainauthenticated network services from that host unlessa new ticket-granting ticket is obtained. And that inturn would require transmission of a password acrossthe network, in violation of fundamental principlesof Kerbeross 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 totrust credentials from host B, and B may be willingto trust host C, but A may not be willing to accepttickets originally created on host C, which A believesto be insecure. Kerberos has a flag bit to indicate

9Actually, a special-purpose ticket-forwarder was builtfor Version 4. However, the implementation was ofnecessity awkward, and required participating hosts to runan additional server.

that a ticket was forwarded, but does not include theoriginal source.

A second problem with forwarding is that theconcept 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 maybe used from any host, without any furthermodifications to the protocol. All that is necessary

to employ such a ticket is a secure mechanism forcopying the multi-session key to the new host. Butthat can be accomplished by an encrypted filetransfer mechanism layered on top of existing facil-ites; it does not require flag bits in the Kerberosheader.

Is it useful to include the network address in aticket? We think not. Given our assumption thatthe network is under full control of the attacker, noextra security is gained by relying on the networkaddress. In fact, the primary benefit of including itappears to be preventing immediate reuse of authen-ticators from a different host.

Even with the protection provided by networkaddresses, replay attacks that involve faked addressesare easy; again, see [Morr85]. Furthermore, anattacker can always wait until the connection is setup and authenticated, and then take it over, thusobviating any security provided by the presence ofthe 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 isalso introduced in Version 5. Briefly, if a userwishes to access a service in another realm, that usermust first obtain a ticket-granting ticket for thatrealm. This is done by making the ticket-grantingserver in a realm the client of another realms TGS.It in turn may be a client of yet another realmsTGS. A users ticket request is signed by each TGSand passed along; realms will normally be configuredin a hierarchical fashion, though tandem links arepermitted.

Unfortunately, this scheme, while appearing tosolve the problem, is deficient in several respects.First, and most serious, there is no discussion of howa TGS can determine which of its neighboringrealms should be the next hop. Moving up the tree,towards the root, is an obvious answer for leafnodes; however, each parent node would need com-

plete knowledge of its entire subtrees realms inorder to determine how to pass the request down-wards. There are obvious analogies here tonetwork-layer routing issues; note, though, that anyrealm routing protocol must include strongauthentication provisions.

Another answer is to say that static tablesshould be used. This, too, has its security limita-tions: should realm administrators rely on electronicmail messages or telephone calls to set up their



8/16


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 clearthat this is useful. If a realm is not a neighbor, itsname may not carry any global signficance, whetherby malice or coincidence. Furthermore, to assess thevalidity of a request, a server needs globalknowledge of the trustworthiness of all possible tran-sit realms. In a large internet, such knowledge isprobably 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 wereequipped with an attached cryptographic unit? Weconsider the design parameters for such a box.

The primary goal is to perform cryptographicoperations without exposing any keys to comprom-ise. These operations must include validating ticketspresented by remote users, creating requests for bothticket-granting tickets and application tickets, andencrypting and decrypting conversations. Conse-quently, there must be secure storage for an adequatenumber of keys, and the operating system must beable to select which key should be used for whichfunction.

The next question, of course, is how keys areentered into the secure storage area. If tickets aredecrypted by the encryption box but transferred tothe hosts memory for analysis, the embedded ses-sion key is exposed.10 Therefore, we conclude thatthe 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, sincethey 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 NFSmounts should be loaded via a Kerberos-authenticated service resident in the encryption unit.

10This 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 itselfdoes 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 sentencrypted. 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 ofassurance that it will not do so.

If an encryption box is used for the Kerberosserver 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 itselfcontains a session key, and a copy of that sessionkey is sent back encrypted in the clients ticket-granting session key. Second, during the initial dia-log with Kerberos, the ticket-granting session keymust be sent out, encrypted in the clients passwordkey. Note, though, that permanent keys are neversent; again, this assures us that the encryption box

will not give away keys. Furthermore, since thesesession keys are intended to be random, we can buyourselves a great deal of security by including ahardware random number generator on-board.

We are not too concerned about having to loadclient and server keys onto the board. This operationis done only by the Kerberos master server, forwhich strong physical security must be assumed inany event. It is possible that such an encryption unitcan be made sufficiently tamper-resistant that evenworkstations can use them; certainly, there are com-mercial cryptographic devices that claim suchstrengths.

One major objection to this entire scheme isthat ultimately, the encryption box is controlled bythe host computer. Thus, if root is compromised,the host could instruct the box to create bogus tick-ets. Such concerns are certainly valid. However, asnoted above, we consider such temporary breaches ofsecurity to be far less serious than the compromiseof a key. Furthermore, using a separate unit allowsus to create untamperable logs, etc.

It is also desirable to prevent misuse of keys.For example, we do not want the login key used todecrypt the arbitrary block of text that just happensto be the ticket-granting ticket. Accordingly, keysshould be tagged with their purpose. A login key

should be used only to decrypt the ticket-grantingticket; the key associated with it should be used onlyfor 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



9/16


A variety of technologies may be used toimplement encryption units, ranging from specialboards to dedicated microcomputers connected toserver hosts by physically-secure lines. If the latteris used, there is the temptation to use its disk storageto hold the service keys associated with the attachedhost, but we feel that that is inadvisable. Any mediaof that sort must be backed up, and the backups

must be carefully guarded. Such a high degree ofsecurity may be impractical in some environments.Instead, we suggest that keys be kept in volatilememory, and downloaded from a secure keystore onrequest, 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 besupplied 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 datato be retained by the keystore, and retrieved at alater date. This data the service keys and tags, inthe case of an encryption unit, or even a conven-tional Kerberos host would be uninterpreted bythe keystore. Storage and retrieval requests wouldbe authenticated by Kerberos tickets, of course.Only encrypted transfer (KRB_PRIV) should beemployed, as insurance against disclosure of suchsensitive material.

As noted, the same keystore protocol could beused to supply additional keys for new instances ofthe same client. For example, a user patcould havea separate instance pat.email, for receiving encryptedelectronic mail. The key for that instance would berestricted 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, asuser workstations are not particularly good sourcesof random keys. The best alternative is to provide a(secure) random number service on the network.When a new client instance is added, this servicewould 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 ifthere are bugs (or trapdoors!) in the design orimplementation of Kerberos, bugs that could be usedto penetrate a system that relies on Kerberos. Somewould say that by making the code widely available,the implementors have enabled would-be penetratorsto gain a detailed knowledge of the system, therebysimplifying their task considerably. We reject thatnotion.

In the late nineteenth century, Kerckhoffs for-mulated the basic principal under which the securityof cryptographic systems should be evaluated: alldetails of the system design should be assumed to be

known by the adversary. Only cryptographic keysspecifically assumed to be secret should be unavail-able to an attacker.[Kahn67, Kerc83] Given this basicpremise, the security of a cryptographic system isevaluated 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 Kerckhoffsevaluation criterion applies to the evaluation of thesecurity of Kerberos. The details of Kerberossdesign and implementation must be assumed knownto a prospective attacker, who may also be in leaguewith some subset of servers, clients, and (in the caseof hierarchically-configured realms) some authentica-tion servers. Kerberos is secure if and only if it canprotect other clients and servers, beginning only withthe premise that these client and server keys aresecret, and that the encryption system is secure.Moreover, in the absence of a central, trusted vali-dation authority, each prospective user of Kerberosis responsible for judging its security. Of course, apublic discussion of system security and publicationof 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 atProject Athena have made a commendable effort toencourage 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, inpart as a consequence of this public discussion. Westress that each modification to the design and imple-

mentation results in a new system whose securityproperties must be considered anew. (Examples ofsuch modifications are the incorporation ofhierarchically-organized servers and forwardable tick-ets in Version 5.)

Hence, on-going modification of Kerberosmakes it a moving target for security validationattempts. A detailed security analysis would thus bepremature. However, the proposed changes to Ker-beros in the next few section are intended, not somuch to defeat specific attacks, as to facilitate thevalidation process. In particular, these suggestionsare intended to make Kerberos more modular, indesign and implementation. Doing so should make

the security consequences of modifications moreapparant, and facilitate an incremental approach toKerberos 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



10/16


interpretable as an authenticator, or vice versa. Suchan analysis depends on redundancy in the pre-encryption binary encodings of each of the ticket andauthenticator information. Currently, that analysismust be repeated with every modification to the pro-tocol. This repetitive and often intricate analysiswould be unnecessary if standard encodings (such asASN.1)[ASN1, BER] were used. These encodings

should include the overall message type (such asKRB_TGS_REP or KRB_PRIV). Together with rea-sonable assumptions about the encryption layer (seethe next section), such an encoding scheme wouldgreatly simplify the protocol validation process, par-ticularly as the protocol is modified or extended.

Some use of ASN.1 encodings has beenadopted for other reasons in Version 5. We rein-force here that there are design principles other thanstandards 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-oredwith both the plaintext and ciphertext of block ibefore encryption. This mode was observed to havepoor propagation properties that permit message-stream modification: specifically, if two blocks ofciphertext are interchanged, only the correspondingblocks are garbled on decryption. Version 5 replacesPCBC mode with the standard CBC mode, cipherblock chaining, which exclusive-ors just the cipher-text of blocki with the plaintext of block i + 1 beforeencryption. A checksum as of Draft 2, the exactform had not been determined is used to detectmessage modification. In order to ensure that dupli-

cate messages have different encryptions, randominitial confounders are added to some messageformats. In addition, Version 5 supports alternativeencryption algorithms as options.

Both the confounder and checksum mechanismsare meant to augment the security of CBC encryp-tion. They belong in a separate encryption layer, notat the level of the Kerberos protocols themselves.Further, the confounder mechanism should bereplaced by using the standard initial vector mechan-ism of cipher-block chaining.[FIPS81, Davi89]

To prevent message-stream modification duringauthenticated or private sessions, Version 5 uses a

timestamp field to prevent entire encrypted messagesfrom being replayed. This is another concern moreproperly delegated to the encryption layer, wherechaining across the packets of the entire session isthe more standard mechanism. (Such chainingavoids both the dependence on a clock and the needto cache recent timestamps.)

Separating the Kerberos protocols from thedetails of encryption would facilitate both validationof the security of the Kerberos protocols, and

implementations and validations involving alternativecryptosystems. 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 startingpoint for such a specification: allow an adversary tosubmit, 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 suffixesof known messages, exclusive-or known messages,and encrypt or decrypt with known keys. At the endof this process, the adversary should not be able toproduce any encrypted messages other than thosespecifically submitted for encryption. Such ananalysis would preclude encryption schemes suscep-tible to simple chosen-plaintext attacks, as describedin a previous section.

Given the intractability of reasoning aboutDES, or of proving complexity properties of anycryptosystem with bounded key size, such analyseswill be no guarantee of overall security. But theycan be used to preclude the existence of trivial cut-and-paste attacks.[DeMi83, Moor88]

RECOMMENDED CHANGES TO THEKERBEROS 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 theattack, balanced against the difficulty of implement-ing the modification.

a. A challenge/response protocol should beoffered as an optional alternative to time-based authentication.

b. Use a standard message encoding, such asASN.1, which includes identification of themessage type within the encrypted data.

c. Alter the basic login protocol to allow forhandheld authenticators, in which {R}KC, fora random R, is used to encrypt the serversreply to the user, in place of the key KCobtained from the user password. This allowsthe login procedure to prompt the user with R,who obtains {R}KC from the handheld deviceand returns that value instead of the passworditself.

d. Mechanisms such as random initial vectors (inplace of confounders), block chaining and

message authentication codes should be left toa separate encryption layer, whoseinformation-hiding requirements are clearlyexplicated. Specific mechanisms based onDES should be validated and implemented.

e. The client/server protocol should be modifiedso that the multi-session key is used to nego-tiate a true session key, which is then used toprotect the remainder of the session.

f. Support for special-purpose hardware should



11/16


be added, such as the keystore. More impor-tantly, future enhancements to the Kerberosprotocol should be designed under theassumption that a host, particularly a multi-user host, may be using encryption and key-storage hardware.

g. To protect against trivial password-guessingattacks, the protocol should not distribute tick-

ets for users (encrypted with the password-based key), and the initial exchange shouldauthenticate the user to the Kerberos server.

h. Support for optional extensions should beincluded. In particular, an option to protectagainst 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. Wedespecially like to thank C. Neuman for his detailedreviews 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 onDraft 3. Finally, wed like to thank the ProjectAthena and Kerberos development staff for their ini-tial design and implementation of Kerberos, theirsolicitation of comments, and their responsiveness toour criticisms.

APPENDIX: VERSION 5 DRAFT 3

Draft 3 has gone a long way towards alleviatingour concerns. Many problems have been fixed, andprovisions have been made for compatible enhance-ments to resolve other outstanding issues. These arebeing refined in ongoing discussion. Still, some

issues remain unresolved or unaddressed. In addi-tion, we raise new issues related to older areas of thespecification.

In a few places, we mention changes that maybe made in future revisions of the specification; thereader is cautioned that these represent our under-standing, and only our understanding, of a continuingprocess.

With one exception, this summary omits areaswhere the authors intent was clear or was clarifiedin private communications. That exception a wayto misuse weak checksums to subvert bidirectionalauthentication we include to demonstrate the deli-cacy inherent in the design and specification ofauthentication protocols.

Draft 3 and Our Recommended Changes

We begin by reviewing our recommended changes inlight of Draft 3 and subsequent discussions with itsauthors.

a. The KRB_AS_REQ/KRB_AS_REP andKRB_TGS_REQ/KRB_TGS_REP exchangesnow 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 inthe KRB_AP_ERR_METHOD error messagecan be used by the server to signal the clientto use a challenge/response alternative to thetime-based kerberos authentication.

b. All encrypted data is labeled with the message

type prior to encryption, via full integration ofthe ASN.1 standard. Although there weremany reasons for this decision, we applaud itsbeneficial impact on security.

c. An optional padata field will probably beadded to the KRB_AS_REP to allow forhandheld authenticator protocol extensions.

d. As discussed, mechanisms such as random ini-tial vectors (in place of confounders), blockchaining and message authentication codes arenow left to a separate encryption layer, with amuch clearer discussion of requirements andof specific mechanisms based on DES.

e. Optional fields will probably be added to the

AP_REQ and AP_REP messages to supportthe negotiation of true session keys.

f. Addition of optional fields (such as padata)should facilitate extensions that exploitspecial-purpose hardware.

g. The initial exchange still does not authenticatethe user to the Kerberos server. Thus, theKerberos equivalent of /etc/passwd mustbe treated as public, and passwords must bechosen and administered with password-guessing attacks in mind. However, thepadata field facilitates optional implementa-tion of such preauthentication mechanisms.

h. As above, several optional fields facilitate

extensions such as exponential-key exchangeto protect against password-guessing viaeavesdropping.

The following sections discuss some of the revisionsin Draft 3 in more detail, and raise some new issues.

Login Dialog

The login dialog has been enhanced to includean additional authentication data field. This can beused to support hand-held authenticators, pre-encryption of the original request, and future exten-sions. This is a significant enhancement, but weregret 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 theclear and encrypted in the users login key, therebydemonstrating that the client is legitimate, and pre-cluding remote collection of tickets encrypted withthe users key. As discussed in the main body ofthis paper, we feel such a mechanism should bemandatory, not optional. Password-cracking



12/16


programs require just this sort of data; there is noneed 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 theoptional extra field, the reply does not, and hencecannot carry the encrypted key. Adding this fieldwould also permit compatible support of exponential

key exchange, wherein each party must send a ran-dom exponential. We understand that the optionalfield 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 theseare 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 alength field, it is no longer possible for an attacker totruncate a message, and present the shortened formas a valid encrypted message. If a decision wereever made to replace ASN.1 (say, with somethingmore efficient), this property would need to bepreserved.

The confounder has now been moved to theencryption layer, but there is still some confusion offunction with the IV used by CBC-mode encryption.As commonly used, an IV is a confounder (see, forexample, [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 usedas intended, and be incremented or otherwise alteredafter each message. Initial values for it should beexchanged during (or derived from) the authentica-tion handshake. Apart from simplifying thedefinition of the encryption function, this schemewould also allow detection of message deletions byinterested applications.

It could be argued that requiring the IV to behandled at a higher layer violates the layering wehave 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 intothe 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 thatsome are labeled cryptographic. This is a crucialomission, as discussed below. A better classificationis 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-32checksum is not collision-proof, while MD4 isbelieved to be. Note that encrypting a checksumprovides very little protection; if the checksum is notcollision-proof and the data is public, an adversarycan compute the value and replace the data withanother 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 theremoval of encryption protection from the additionaltickets and authorization data that may be enclosedwith certain requests. These fields are protected by achecksum sealed in the encrypted authenticator sentwith the request. Assume that the checksum algo-rithm used is CRC-32. (This is permitted by a literalreading of Draft 3, though we have learned that thiswas not the intent of the authors.) With thisassumption, the existence of the ENC-TKT-IN-SKEY option leads to a major security breach, and

in particular to the complete negation of bidirectionalauthentication.

As usual, the client, possessing a valid ticket-granting ticket, sends off a request for a new ticketfor some service S. The enemy intercepts thisrequest and modifies it. First, the ENC-TKT-IN-SKEY bit is set. This specifies that the ticket, nor-mally encrypted in Ss key, should be encrypted inthe session key of the enclosed ticket-granting ticket.Second, the attackers own ticket-granting ticket isenclosed. Obviously, the attacker knows its sessionkey. Finally, the additional authorization data fieldis filled in with whatever information is needed tomake the CRC match the original version.

Consider what happens. The ticket-grantingservice, seeing a valid request, sends back a ticket.This ticket, encrypted in the enemys key, will notbe intelligible to the real service, but of course, itwill not get that far. The legitimate client cannot tellthat the ticket is misencrypted; tickets are, almost bydefinition, encrypted in a key known only to theserver and Kerberos. When the service is requested,the enemy intercepts the request and unseals theticket. The client may request bidirectional authenti-cation; however, since the attacker has decrypted theticket, the session key for that service request isavailable. Consequently, the bidirectional authentica-tion dialog may be spoofed without trouble.

A number of different factors interacted tomake this attack possible. One is obvious: theticket request was protected by what turned out to bea weak checksum. If a collision-proof checksumwere used, the attack would be infeasible; the enemycould not have generated the additional authorizationdata field necessary to make the new requestschecksum match the original. But there aresubtleties here. First, if the additional tickets used



13/16


by ENC-TKT-IN-SKEY were encrypted (again), theywould have been adequately protected by the verysame CRC-32 checksum that was abused in theattack. However, because of the encryption, theenemy would be unable to either discern or matchthe checksum. In other words, the context is critical;merely refraining from re-encrypting some encrypteddata, while using the same checksum to protect it,

has led to a security breach. (Note: we have beentold that the designers intended to require that thecname in the additional ticket match the name of theserver for which the new ticket is being requested.This requirement would still permit the intended useof 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 theREUSE-SKEY option. This option was designed formulticast key distribution; with a weak checksum, anattacker can abuse it to generate a service ticketwhose key is known. The REUSE-SKEY optionalso permits a related, albeit less serious, attack. Iftwo tickets, T1 and T2, share the same key, theattacker can intercept a request for one service, andredirect it to the other. Since the two tickets sharethe same key, the authenticator will be accepted.Just how damaging this possibility is depends onwhat sorts of services might want to share the samekey. If, say, a file server and a backup server wereinvoked this way, an attacker might redirect somerequests to destroy archival copies of files beingedited. A solution to this particular attack is toinclude either the service name, a collision-proofchecksum of the ticket, or both, in the authenticator.To be sure, Draft 3 explicitly warns against usingtickets with DUPLICATE-SKEY set for authentica-tion. Servers that obey this restriction are notvulnerable to this attack. Also, we have been toldthat the REUSE-SKEY option will probably be omit-ted in future revisions of the protocol.

A last attack of this sort can occur if theattacker 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 wasnot tampered with in transit. While this appears tobe more a denial-of-service attack than a penetration,it would be useful for the client to know thisimmediately.

Two issues underly this list of potential attacks.As discussed, weak checksums (encrypted but notcollision-proof, and over public data) allow an adver-sary to paste together legitimate-looking messages.Message integrity via strong checksums and/orencryption should be extended to as many protocolmessages (and as many fields) as possible.

Second, the REUSE-SKEY and ENC-TKT-IN-SKEY options overload the basic protocol, in thattickets may now share session keys or be encryptedin keys other than the service. It is possible thatthere are other ways an attack could exploit theensuing ambiguities. These options are intended forvery constrained uses, not general authentication;they should not be so intimately integrated into the

basic authentication protocol. The same purposeswould be served by adding separate message typesthat cannot be misinterpreted as tickets, and usingkeys that are derived from but are not identical tothose used in the basic protocol.

Even then, an analysis of the final standard isneeded, to assure that a minor extension has notnegated a security-critical assumption. (E.g., thebasic Kerberos protocol assumes that no two ticketsshare a session key, and that tickets are alwaysencrypted with the servers key.)

KRB_SAFE and KRB_PRIV Messages

The KRB_

SAFE and KRB_

PRIV messagesemploy the session key distributed with the ticket forintegrity-checking and privacy, respectively. Draft 3dictates that both use time-of-day values to guardagainst replay, which may be problematic.Currently, the resolution of the timestamp is limitedto 1 millisecond, which is far too coarse for manyapplications. (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 cacheof recently-used timestamps. Obviously, if suchmessages are used for things like file systemrequests, the size of the cache could rapidly become

unmanageable. Furthermore, if two authenticated orencrypted sessions run concurrently, the cache mustbe shared between them, or messages from one ses-sion can be replayed into the other.

Both problems can be solved if the idea of atimestamp is abandoned in favor of sequencenumbers. A random initial sequence number can betransmitted with the authenticator and/or in theKRB_AP_REP message; after each authenticatedmessage is sent, it would, of course, be incremented.The cache is then a simple last-message counter.This mechanism also provides the ability to detectdeleted messages, by watching for gaps in sequence

number utilization. And, since each session wouldhave its own initial sequence number, it would notbe possible for an attacker to perform cross-streamreplays, and concurrent access to a common cache isnot necessary. (This advantage would be gainedeven with timestamps if true session keys wereused.) It is likely that in a future revision, sequencenumbers will be provided as an alternative to the useof timestamps.



14/16


Authenticators

Draft 3 still calls for the use of authenticatorsto guard against ticket replay. However, there isnow a provision for the server to specify that addi-tional authentication is required, and an optional datafield for this has been added to the KRB_ERRORreply message. This can be used to implementchallenge/response schemes.

The authenticator should have some other fieldsadded to it, some of them optional. As noted earlier,it must contain a collision-proof checksum linking itto the ticket, and an optional initial sequencenumber. The latter would be used by any applica-tions that might wish to exchange encrypted orauthenticated messages.

The authenticator is also the right place tonegotiate a true session key. We propose adding anew field for it to both the authenticator and theKRB_AP_REP message. The actual session keycould be formed by an exclusive-or of the multises-sion key associated with the ticket, a randomly-

generated field in the authenticator, and a similarfield in the reply message. Note that this retains ameasure of compatibility with the current scheme: ifthe two optional fields are not present, the multi-session key will be used as the actual session key.

Negotiation of true session keys, initialsequence numbers, and confounders or IVs could becombined in one standard mechanism, perhaps sub-sumed as encryption-specific subfields of the sessionkey 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 identitiesof all of its children, there is still no scalablemechanism to learn of grandchildren or more distantdescendants.

To be sure, it is apparently the intention of theauthors that the Internets domain name space beused to denote realms, and implicitly thehierarchy of servers. It is far from clear to us thatthe two hierarchies coincide. Furthermore, suchusage is not required. No alternative routingmechanism has been suggested.

Additionally, there are several pieces of theprotocol that are unclear or simply do not work withinter-realm tickets. For example, ENC-TKT-IN-SKEY and REUSE-KEY require the ticket-grantingserver to decrypt a ticket. It cannot do this if theticket had been issued by another realm. Presum-ably, of course, the request could be sent to the otherrealms ticket-granting server, but it may not possessthe necessary key to generate the new ticket.

NEW RECOMMENDED CHANGES

Below, we include a new list of recommendedchanges, beyond those we have indicated are likelyto be adopted. The first two are repeated from ourearlier list, and are now (or will be) implementableas options; we repeat them here to stress our beliefthat they should be a mandatory part of the protocol.

a. Alter the basic login protocol to allow forchallenge/response handheld authenticators.

b. The initial exchange should authenticate theuser to the Kerberos server, to complicatepassword-guessing attacks.

c. Strong checksums, encryption, and additionalfields should be used to assure integrity of thebasic Kerberos messages. (For example, tick-ets should be tied more closely to the contextsin which they are used, by including servicenames in the ticket, and the encrypted part ofKRB_AS_REP and KRB_TGS_REP shouldcontain collision-proof checksums of the tick-ets.)

d. Protocol extensions not related to basicauthentication (the ENC-TKT-IN-SKEY andREUSE-SKEY options) should be omitted oruse distinct message and ticket formats.

References

FIPS81. DES Modes of Operation, FederalInformation Processing Standards Publication81 (December 1980). National Bureau of Stan-dards, U.S. Department of Commerce

ASN1. Information Processing Systems OpenSystems Interconnection Specification ofAbstract Syntax Notation One (ASN.1), Inter-national Standard 8824 (1987). International

Organization for Standardization and Interna-tional Electrotechnical Committee

BER. Information Processing Systems OpenSystems Interconnection Specification ofBasic Encoding Rules for Abstract SyntaxNotation One (ASN.1), International Standard8825 (1987). International Organization forStandardization and International Electrotechni-cal Committee

Beke82. H. Beker and F. Piper, Cipher Systems,John Wiley & Sons (1982).

Brya88. B. Bryant, Designing an AuthenticationSystem: A Dialogue in Four Scenes, Draft

February 8, 1988.

Davi89. D.W. Davies and W.L. Price, Security forComputer Networks, John Wiley & Sons(1989). Second Edition

Davi90. D. Davis and R. Swick, Workstation Ser-vices and Kerberos Authentication at ProjectAthena, MIT Laboratory for Computer ScienceTechnical Memorandum 424 (February 1990).

Deav85. C.A. Deavours and L. Kruh, Machine



15/16


Cryptography and Modern Cryptanalysis,Artech House (1985).

DeMi83. R. DeMillo and M. Merritt, Protocolsfor 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 LaboratoriesTechnical Journal 63(8, Part 2) pp. 1649-1672A&T, (October, 1984).

Kahn67. D. Kahn, Codebreakers: The Story ofSecret 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 AuthenticationService, MIT Project Athena (October 8, 1990).Version 5, Draft 3

LaMa. B.A. LaMacchia and A.M. Odlyzko, Com- putation of Discrete Logarithms in PrimeFields, (Manuscript in preparation)

Loma89. T.M.A. Lomas, L. Gong, J.H. Saltzer,and R.M. Needham, Reducing Risks fromPoorly Chosen Keys, Operating SystemsReview 23(5) pp. 14-18 ACM, (December

1989).Mill87. S.P. Miller, B.C. Neuman, J.I. Schiller,

and J.H. Saltzer, Kerberos Authentication andAuthorization System, in Project AthenaTechnical Plan, (December 1987). SectionE.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., UNIXPassword Security, Communications of theACM22(11) p. 594 (November 1979).

Morr85. R.T. Morris, A Weakness in the 4.2BSDTCP/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 OpenNetwork Systems, in Proc. Winter USENIXConference, , Dallas (1988).

Stol88. C. Stoll, Stalking the Wiley Hacker,Communications of the ACM31(5) p. 484 (May1988).

Voyd83. V.L. Voydock and S.T. Kent, SecurityMechanisms in High-Level Network Proto-cols, ACM Computer Surveys 15(2) pp. 135-171 (June, 1983).

Steven M. Bellovin received aB.A. degree from ColumbiaUniversity, and an M.S. andPh.D. in Computer Sciencefrom the University of NorthCarolina at Chapel Hill. Whilea graduate student, he wrote theoriginal version of pathaliasand helped create netnews.However, the former is not anindictable offense, and thestatute of limitations on the latter has expired.Nevertheless, he is still atoning for both actions. Hehas been at AT&T Bell Laboratories since 1982,

where he does research in networks, security, andwhy the two dont get along. He may be reachedelectronically as [email protected] ; thosewho prefer to murder trees may send scraps of paperto Room 3C-536B, AT&T Bell Laboratories, 600Mountain Avenue, Murray Hill, NJ 07974, U.S.A.

Michael Merritt received a B.S.from Yale University, and anM.S. and Ph.D. in Informationand Computer Science from theGeorgia Institute of Technol-ogy. His dissertation, "Crypto-graphic Protocols", developed

techniques for exploring secu-rity properties of distributedalgorithms. He has been atAT&T Bell Laboratories since1983, where he does research in distributed systemsand security. His email address [email protected] ; paper to Room3D-458, AT&T Bell Laboratories, 600 MountainAvenue, Murray Hill, NJ 07974, U.S.A.



16/16


limitations of the kerberos authentication system†

Documents