Limitations of the Kerberos System² Steven M. Bellovin ± AT&T Bell Laboratories Michael Merritt ± AT&T Bell Laboratories

ABSTRACT The Kerberos authentication system, a part of MIT's , has been adopted by other organizations. Despite Kerberos's many strengths, it has a number of limitations and some weaknesses. Some are due to speci®cs of the MIT environment; others represent de®ciencies 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 on the extent to which security is improved. Further, we recommend changes to the protocols that substan- The Kerberos authentication system[Stei88, Mill87, tially increase security. Brya88] was introduced by MIT to meet the needs of Project Athena. It has since been adopted by a Beyond its speci®c utility in production, Ker- number of other organizations for their own pur- beros serves a major function by focusing interest on poses, and is being discussed as a possible standard. practical solutions to the network authentication In our view, both these decisions may be premature. problem. The elegant protocol design and wide avai- Kerberos has a number of limitations and lability of the code has galvanized a wide audience. weaknesses; a decision to adopt or reject it cannot Far from a condemnation, our critique is intended to properly be made without considering these issues. contribute to an understanding of Kerberos's proper- (A limitation is a feature that is not as general as one ties and to in¯uence its evolution into a tool of might like, while a weakness could be exploited by greater power and utility. an attacker to defeat the authentication mechanism.) Several of the problems we point out are men- Some improvements can be made within the current tioned in the original Kerberos paper or design. Support for optional mechanisms would elsewhere.[Davi90] For some of these, we present pro- extend Kerberos's applicability to environments radi- tocol improvements that solve, or at least ameliorate, cally different from MIT. the problem; for others, we place them squarely in These problems fall into several categories. the context of the intended Kerberos environment. Some stem from the Project Athena environment. Kerberos was designed for that environment; if the Version 5, Draft 3 basic assumptions differ, the authentication system Since this paper was written, a new draft of the may need to be changed as well. Other problems are Version 5 protocol has been released, and a ®nal simply de®ciencies in the protocol design. Some of speci®cation is promised.[Kohl90] Many of the prob- these are corrected in the proposed Version 5 of lems we discuss herein have been corrected. Others Kerberos,[Kohl89] but not all. Even the solved prob- remain, and we have found a few new ones. The lems merit discussion, since the code for Version 4 ultimate resolution of these issues is unclear as we has been widely disseminated. Finally, some prob- go to press. Consequently, a brief analysis of lems with Kerberos are not solvable without employ- Draft 3 is presented in an appendix, rather than in ing special-purpose hardware, no matter what the the main body of the document. design of the protocol. We will consider each of these areas in turn. Focus on Security We wish to stress that we are not suggesting Kerberos is a security system; thus, though we that Kerberos is useless. Quite the contrary Ð an address issues of functionality and ef®ciency, our attacker capable of carrying out any of the attacks primary emphasis is on the security of Kerberos in a listed here could penetrate a typical network of UNIX general environment. This means that security- systems far more easily. Adding Kerberos to a net- critical assumptions must be few in number and work will, under virtually all circumstances, stated clearly. For the widest utility, the network signi®cantly increase its security; our criticisms focus must be considered as completely open. Speci®cally, the protocols should be secure even if the network is ²A version of this paper was published in the October, 1990 issue of Computer Communications Review.

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 algorithm or to subvert a principal speci®cally assumed to be Table 1: Notation trustworthy. Only such a strong design goal can jus- tify the expense of encryption. (No ``steel doors in c client principal paper walls''.) We believe that Kerberos can meet s server principal this ambitious goal with only minor modi®cations, tgs ticket-granting server retaining its essential character. K x private key of ``x'' Some of our suggestions bear a performance K c,s session key for ``c'' and ``s'' { } penalty; others complicate the design of suggested in f o K x ``in f o'' encrypted in key K x { } enhancements. As more organizations make use of T c,s K s Encrypted ticket for ``c'' to use ``s'' { } Kerberos, pressures to enhance or augment its func- A c K c,s Encrypted authenticator for ``c'' to tionality and ef®ciency will increase. Security has use ``s'' real costs, and the bene®ts are intangible. There addr client's IP address must be a continuing and explicit emphasis on secu- rity as the overriding requirement.

Validation Kerberos principals may obtain tickets for ser- It is not suf®cient to design and implement a vices from a special server known as the ticket- security system. Such systems, though apparently granting server, or TGS. A ticket contains assorted adequate when designed, may have serious ¯aws. information identifying the principal, encrypted in Consequently, systems must be subjected to the the private key of the service. (Notation is summar- strongest scrutiny possible. A consequence of this is ized in Table 1.) that they must be designed and implemented in a { } = { } manner that facilitates such scrutiny. Kerberos has a T c,s K s s, c, addr, timestamp, li f etime, K c,s K s number of problems in this area as well. Since only Kerberos and the service share the private WHAT'S A KERBEROS? key K s, the ticket is known to be authentic. The ticket contains a new private session key, K c,s, Before discussing speci®c problem areas, it is known to the client as well; this key may be used to helpful to review Kerberos Version 4. Kerberos is encrypt transactions during the session.2 an authentication system; it provides evidence of a To guard against replay attacks, all tickets principal's identity. A principal is generally either a presented are accompanied by an authenticator: user or a particular service on some machine. A { } = { } principal consists of the three-tuple A c K c,s c, addr, timestamp K c,s < primaryname, instance, realm >. This is a brief string encrypted in the session key and containing a timestamp; if the time does not If the principal is a user Ð a genuine person Ð the match the current time within the (predetermined) primary name is the login identi®er, and the instance clock skew limits, the request is assumed to be is either null or represents particular attributes of the fraudulent. user, i.e., root. For a service, the service name is used as the primary name and the machine name is For services where the client needs bidirectional used as the instance, i.e., rlogin.myhost. The authentication, the server can reply with { + } realm is used to distinguish among different authen- timestamp 1 K c,s tication domains; thus, there need not be one giant This demonstrates that the server was able to read Ð and universally trusted Ð Kerberos database timestamp from the authenticator, and hence that it serving an entire company. 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 1The Project Athena Technical Plan[Mill87, section 2] describes a simpler threat environment, where eavesdrop- In other words, an ordinary ticket/authenticator pair ping and host impersonation are of primary concern. is used; the ticket is known as the ticket-granting While this may be appropriate for MIT, it is by no means 2 generally true. Consider, for example, a situation where Technically speaking, K c,s is a multi-session key, since general-purpose hosts also function as routers, and packet it is used for all contacts with that server during the life of modi®cation or deletion become signi®cant concerns. the ticket.

2 USENIX ± Winter '91 ± Dallas, TX Bellovin & Merritt Kerberos Limitations ticket. The TGS responds with a ticket for server s computer's daemons when contacting another com- and a copy of K c,s, all encrypted with a private key puter. Attempting to use Kerberos in such a mode shared by the TGS and the principal: can cause trouble.4 { { } } T c,s K s ,K c,s K c,tgs We make this statement for several reasons. First and foremost, typical computer systems do not The session key K is a newly-chosen random key. c,s have a secure key storage area. In Kerberos, a plain- The key K c,tgs and the ticket-granting ticket text key must be used in the initial dialog to obtain a itself, are obtained at session-start time. The client ticket-granting ticket. But storing plaintext keys in a sends a message to Kerberos with a principal name; machine is generally felt to be a bad idea;[Morr79] if a Kerberos responds with Kerberos key that a machine uses for itself is { { } } compromised, the intruder can likely impersonate K c,tgs , T c,tgs K tgs K c any user on that computer, by impersonating requests The client key K c is derived from a non-invertible vouched for by that machine (i.e., ®le mounts or transform of the user's typed . Thus, all cron jobs).5 Additionally, the session keys returned privileges depend ultimately on this one key. by the TGS cannot be stored securely; of necessity, Note that servers must possess private keys of they are stored in some area accessible to root. their own, in order to decrypt tickets. These keys Thus, if the intruder can crack the protection are stored in a secure location on the server's mechanism on the local computer Ð or, perhaps machine. more to the point, work around it for some limited purposes Ð all current session keys can be stolen. THE KERBEROS ENVIRONMENT This is less serious than a breach of the primary Ker- The Project Athena computing environment beros key, of course, since session keys are limited consists of a large number of more or less in lifetime and scope; nevertheless, one does not anonymous workstations, and a smaller number of wish these keys exposed. large autonomous server machines. The servers pro- This points out a second ¯aw when multi-user vide volatile ®le storage, print spooling, mailboxes, computers employ Kerberos, either on their own and perhaps some computing power; the worksta- behalf or for their users: the cached keys are acces- tions are used for most interaction and computing. sible to attackers logged in at the same time. In a Generally, they possess local disks, but these disks workstation environment, only the current user has are effectively read-only; they contain no long-term access to system resources; there is little or no need user data. Furthermore, they are not physically even to enable remote login to that workstation. secure; someone so inclined could remove, read, or There are many reasons for this; a consequence, alter any portion of the disk without hindrance. though, is that the intruder simply cannot approach Within this environment the primary need is for the safe door to try to pick its lock.6 Only when the user-to-server authentication. That is, when a user legitimate user leaves can the attacker attempt to ®nd sits down at a workstation, that person needs access the keys. But the keys are no longer available; Ker- to private ®les residing on a server. The workstation beros attempts to wipe out old keys at logoff time, itself has no such ®les, and hence has no need to leaving the attacker to sift through the debris. With contact the server or even to identify itself. a multi-user computer, on the other hand, an attacker has concurrent access to the keys if there are ¯aws in This is in marked contrast to a typical UNIX system's view of the world. Such systems do have the host's security. an identity, and they do own ®les. Assorted network There are two other minor ¯aws in Kerberos daemons transfer ®les in the background, clock dae- directly attributable to the environment. First, there mons perform management functions, electronic mail is some question about where keys should be cached. and news arrives, etc. If such a machine relied on Since all of the Project Athena machines have local servers to store its ®les, it would have to assert, and disks, the original code used /tmp. But this is possibly prove, an identity when talking to these highly insecure on diskless workstations, where servers. The Project Athena workstations are neither /tmp exists on a ®le server; accordingly, a capable nor in need of such; they in effect function modi®cation was made to store keys in shared as very smart terminals with substantial local com- memory. However, there is no guarantee that shared puting power, rather than as full computer systems.3 memory is not paged; if this entails network traf®c,

What does this mean for Kerberos? Simply 4 this: Kerberos is designed to authenticate the end- More precisely, Kerberos is not a host-to-host protocol. In Version 5, it has been extended to support user-to-user user Ð the human being sitting at the keyboard Ð authentication.[Davi90] to some number of servers. It is not a peer-to-peer 5Recall that we are assuming here that the machine Ð system; it is not intended to be used by one and hence its superuser Ð needs an identity of its own. 6On Project Athena machines, remote access to most 3We regard this as a feature, not a bug. workstations is in fact disabled.

USENIX ± Winter '91 ± Dallas, TX 3 Kerberos Limitations Bellovin & Merritt an intruder can capture these keys. caching, though this was never implemented. (While Finally, the Kerberos protocol binds tickets to that is a feature of the implementation rather than of IP addresses. Such usage is problematic on on the protocol itself, a security feature is not very use- multi-homed hosts (i.e., hosts with more than one IP ful if it is too hard to implement.) address). Since workstations rarely have multiple For several reasons, we do not think that cach- addresses, this feature Ð intended to enhance secu- ing solves the problem. First, on UNIX systems it is rity Ð was not a problem at MIT. Multi-user hosts dif®cult for TCP-based[Post81] servers to store often do have multiple addresses, however, and can- authenticators. Servers generally operate by forking not live with this limitation. This problem has been a separate process to handle each incoming request. ®xed in Version 5. The child processes do not share any memory with the parent process, and thus have no convenient way PROTOCOL WEAKNESSES to inform it Ð and hence any other child servers Ð Replay Attacks of the value of the authenticator used. There are a number of obvious solutions Ð pipes, authenticator The Kerberos protocol is not as resistant to servers, shared memory segments and the like Ð but penetration as it should be. A number of weaknesses all are awkward, and some even raise authentication are apparent; the most serious is its use of an authen- questions of their own. To date, we know of no ticator to prevent replay attacks. multi-threaded server implementation which caches The authenticator relies on use of a timestamp authenticators. to guard against reuse. This is problematic for UDP-based[Post80] query servers can store the several reasons. The claim is made that no replays authenticators more easily, as a single process gen- are likely within the lifetime of the authenticator erally handles all incoming requests; however, they (typically ®ve minutes). This is reinforced by the might have problems with legitimate retransmissions presence of the IP address in both the ticket and the of the client's request if the answer was lost. (UDP authenticator. We are not persuaded by this logic. does not provide guaranteed delivery; thus, all An intruder would not start by capturing a ticket and retransmissions happen from application level, and authenticator, and then develop the software to use are visible to the application.) Legitimate requests them; rather, everything would be in place before the could be rejected, and a security alarm raised inap- ticket-capture was attempted. Let us consider two propriately. One possible solution would be for the examples. application to generate a new authenticator when Some years ago, Morris described an attack retransmitting a request; were it not for the other based on the slow increment rate of the initial weaknesses of the authenticator scheme, this would sequence number counter in some TCP be acceptable. implementations.[Morr85] He demonstrated that it was possible, under certain circumstances, to spoof one Secure Time Services half of a preauthenticated TCP connection without ever seeing any responses from the targeted host. In As noted, authenticators rely on machines' a Kerberos environment, his attack would still work clocks being roughly synchronized. If a host can be if accompanied by a stolen live authenticator, but not misled about the correct time, a stale authenticator if a challenge/response protocol was used. Alterna- can be replayed without any trouble at all. Since tively, an intruder may simply watch for a ``mail- some time synchronization protocols are checking'' session, wherein a user logs in brie¯y, unauthenticated,[Post83, Mill88] and hosts are still using reads a few messages, and logs out. A number of these protocols despite the existence of better valuable tickets would be exposed by such a session, ones,[Mill89] such attacks are not dif®cult. notably the one used to mount the user's home direc- The design philosophy of building an authenti- tory. Note that the lifetime of the authenticators Ð cation service on top of a secure time service is itself 5 minutes Ð contributes considerably to this attack. questionable. That is, it may not make sense to Further, the proposed Version 5 of Kerberos build an authentication system assuming an already- anticipates alternative communication protocols in authenticated underlying system. Furthermore, while which such replays may be trivial to implement. If spoo®ng an unauthenticated time service may be a Kerberos is to be considered as a general-purpose dif®cult programming task, it is not cryptographi- 7 utility, it must make few security-critical assump- cally dif®cult. Using time-based protocols in a tions about the underlying network, and those must secure fashion means thinking through all these be explicit. issues carefully and making the appropriate

It has been suggested that the proper defense is 7 for the server to store all live authenticators; thus, an In some environments, programming is not even neces- sary. Low-powered fake WWV transmitters are not hard attempt to reuse one can be detected.[Stei88] In fact, to build, and, if properly located, could easily block out the original design of Kerberos required such the legitimate signal.

4 USENIX ± Winter '91 ± Dallas, TX Bellovin & Merritt Kerberos Limitations synchronization an explicit part of the protocol. As Password-Guessing Attacks Kerberos is proposed for more varied environments, A second major class of attack on the Kerberos its dependence on a secure time service becomes protocols involves an intruder recording login dialogs more problematic and must be stressed. in order to mount a password-guessing assault. As an alternative, we propose the use of a When a user requests T c,tgs (the ticket-granting challenge/response authentication mechanism. As is ticket), the answer is returned encrypted with K c, a done today, the client would present a ticket, though key derived by a publicly-known algorithm from the without an authenticator. The server would respond user's password. A guess at the user's password can with a nonce identi®er encrypted with the session be con®rmed by calculating K c and using it to key K c,s; the client would respond with some func- decrypt the recorded answer. An intruder who has tion of that identi®er, thereby proving that it recorded many such login dialogs has good odds of possesses the session key. ®nding several new ; empirically, users do Such an implementation is not without its costs, not pick good passwords unless forced to.[Morr79, of course. An extra pair of messages must be Gram84, Stol88] exchanged each time a ticket is used, which rules out We propose the use of exponential key the possibility of authenticated datagrams. More exchange[Diff76] to provide an additional layer of seriously, all servers must then retain state to com- encryption. Without describing the algorithm in plete the authentication process. While not a prob- detail, it involves the two parties exchanging lem for TCP-based servers, this may require substan- numbers that each can use to compute a secret key. tial modi®cation to UDP-based query servers. (The An outsider, not knowing how the numbers were cal- complexity of managing outstanding challenges may culated, cannot easily derive the key. be comparable to that needed to cache live authenti- Such a use of exponential key exchange would cators Ð the trade-off is not between a stateful and a prevent a passive wiretapper from accumulating the stateless protocol, but in managing two kinds of network equivalent of /etc/. While state.) exponential key exchange is normally vulnerable to There is a sign®cant philosophical difference active wiretaps, such attacks are comparatively rare, between the two techniques, however. In the current especially if dedicated network routers are used. Kerberos implementation, with its assumptions about Apart from licensing issues Ð exponential key the network environment, retained state is only exchange is protected by a U.S. patent Ð using it necessary to enhance security. The has its costs. LaMacchia and Odlyzko[LaMa] have challenge/response scheme, on the other hand, demonstrated that exchanging small numbers is quite guarantees security in a more general environment, insecure, while using large ones is expensive in com- but requires retained state to function at all. putation time. Additionally, we have added extra Instead of substituting challenge/response messages to the login dialog, and imposed the throughout, a possible compromise is to extend the requirement for considerable extra state in the server. protocol with a challenge/response option. This Given the trend towards hiding even encrypted pass- option could be used, for example, to authenticate words on UNIX systems, and given estimates that half the user in the initial ticket-granting ticket exchange of all logins at MIT are used within a two-week and to access a time service.8 Subsequent client- period, the investment may be justi®able. Perhaps server interactions could use the current time-based the best solution is to support this feature as a protocol. But synchronizing the servers remains a domain-speci®c option. problem; not synchronizing them will lead to denial Even exponential key exchange will not prevent of service, and if they access the time service as a all password-guessing attacks. Depending on how client, they must somehow obtain and store a ticket carefully the Kerberos logs are analyzed, an intruder and key to authenticate it. (See above on storing need not even eavesdrop. Requests for tickets are keys in servers.) Given these complexities and pos- not themselves encrypted; an attacker could simply sible weaknesses, it would seem reasonable to allow request ticket-granting tickets for many different any service to insist on the challenge/response users. An enhancement to the server, to limit the option. rate of requests from a single source, may be useful. Summarizing, we emphasize that the security of Alternatively, some portion of the initial ticket Kerberos depends critically on synchronized clocks. request may be encrypted with K c, providing a In essence, the Kerberos protocols involve mutual minimal authentication of the user to Kerberos, such trust among four parties: the client, server, authenti- that true eavesdropping would be required to mount cation server and time server. 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 8 alternative avenue for mounting a password-guessing This was suggested to us by Clifford Neuman. 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 they offer a substantial increase in security in high- obtained by any user. This capability has been sug- threat environments. If they are not used, the cost of gested as the basis for user-to-user authentication and our scheme is quite low, simply one extra encryption and enhanced mail services.[Salt90] But any such on each end. scheme would seem to require repeated re-entry of A second, more cogent, objection is that if the the user's password, an inconvenience we suspect client's workstation cannot be trusted with a user's will not be tolerated. We would prefer to provide password, it cannot be trusted with session keys pro- the same functionality by having clients register vided by Kerberos. This is, to some extent, a valid separate instances as services, with truly random criticism, though we believe that compromise of the keys. Keys could be supplied to the client by the login password is much more serious than the cap- keystore, described below.) ture of a few limited-lifetime session keys. This An alternative approach is a protocol described problem cannot be solved without the use of by Lomas, Gong, Saltzer, and Needham.[Loma89] special-purpose hardware, a subject we shall return They present a dialog with a server that does not to below. expose the user to password-guessing attacks. How- Finally, it has been pointed out that a user can ever, their protocol relies on public-key cryptogra- always supply a known-clean boot device, or boot phy, an approach explicitly rejected for Kerberos. via the network. The former we regard as improb- able in practice unless removable media are Spoo®ng Login employed; the latter is insecure because the boot pro- In a workstation environment, it is quite simple tocols are unauthenticated. for an intruder to replace the login command with a version that records users' passwords before Inter-Session Chosen Plaintext Attacks employing them in the Kerberos dialog. Such an According to the description in the Version 5 attack negates one of Kerberos's primary advantages, draft,[Kohl89] servers using the KRB_PRIV format are that passwords are never transmitted in cleartext over susceptible to a chosen plaintext attack. (A chosen- a network. While this problem is not restricted to plaintext attack is one where an attacker may choose Kerberos environments, the Kerberos protocol makes all or part of the plaintext and, typically, use the it dif®cult to employ the standard countermeasure: resulting cipher text to attack the cipher. Here we one-time passwords. use the cipher text to attack the protocol. Mail and A typical one-time password scheme employs a ®le servers are examples of servers susceptible to secret key shared between a server and some device such attacks.) Speci®cally, the encrypted portion of in the user's possession. The server picks a random messages of this type have the form number and transmits it to the user. Both the server X = (DATA, timestamp + direction, hostaddress, PAD) and the user (with the aid of the device) encrypt this number using the secret key; the result is transmitted Since cipher-block chaining[FIPS81, Davi89] has the back to the server. If the two computed values property that pre®xes of are encryptions match, the user is assumed to possess the appropriate of pre®xes, if DATA has the form key. (AUTHENTICATOR, CHECKSUM, REMAINDER) Kerberos makes no provision for such a then a pre®x of the encryption of X with the session challenge/response dialog at login time. The server's key is the encryption of response to the login request is always encrypted (AUTHENTICATOR, CHECKSUM) , with K c, a key derived from the user's password. Unless a ``smart card'' is employed that understands and can be used to spoof an entire session with the the entire Kerberos protocol, this precludes any use server. of one-time passwords. It may be argued that most servers are not sus- An alternative (®rst suggested to us by T.H. ceptible to chosen plaintext attacks. Given that there Foregger) requires that the server pick a random are easy counters to this attack, it seems foolish to number R, and use K c to encrypt R. This value advocate a general format for private servers that { } R K c, rather than K c, would be used to encrypt the does not also protect against it. server's response. R would be transmitted in the It should be noted that the simple attack above clear to the user. If a hand-held authenticator was in { } does not work against Kerberos Version 4, in which use, the user would employ it to calculate R K c; the encrypted portion of the KRB_PRIV message is otherwise, the login program would do it automatic- of the form ally. (length(DATA) , DATA, msectime, hostaddress, Several objections may be raised to this timestamp + direction, PAD) scheme. First, hand-held authenticators are often thought to be inconvenient. This is true; however, as the leading length(DATA) ®eld disrupts the pre®x-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 that a ticket was forwarded, but does not include the against this format, even allowing for the fact that original source. Version 4 uses the nonstandard PCBC mode of A second problem with forwarding is that the encryption. (Hint: assume the initial vector is ®xed concept only makes sense if tickets include the net- and public.) However, it is interesting to note that work address of the principal. If the address is omit- the order of concatenation of message ®elds can ted Ð as is permitted in Version 5 Ð a ticket may have security-critical implications. We return to this be used from any host, without any further question in the later section on message encoding. modi®cations to the protocol. All that is necessary to employ such a ticket is a secure mechanism for Exposure of Session Keys copying the multi-session key to the new host. But The term ``session key'' is a misnomer in the Ker- that can be accomplished by an encrypted ®le beros protocol. This key is contained in the service transfer mechanism layered on top of existing facil- ticket and is used in the multiple sessions between ites; it does not require ¯ag bits in the Kerberos the client and server that use that ticket. Thus, it is header. more properly called a ``multi-session key''. Mak- Is it useful to include the network address in a ing this point explicit leads naturally to the sugges- ticket? We think not. Given our assumption that tion that true session keys be negotiated as part of the network is under full control of the attacker, no the Kerberos protocol. This limits the exposure to extra security is gained by relying on the network cryptanalysis[Kahn67, Beke82, Deav85] of the multi- address. In fact, the primary bene®t of including it session key contained in the ticket, and precludes appears to be preventing immediate reuse of authen- attacks which substitute messages from one session ticators from a different host. in another. (The chosen-plaintext attack of the previ- Even with the protection provided by network ous section is one such example.) The session key addresses, replay attacks that involve faked addresses could be generated by the server or could be com- are easy; again, see [Morr85]. Furthermore, an puted as a session-speci®c function of the multi- attacker can always wait until the connection is set session key. up and authenticated, and then take it over, thus obviating any security provided by the presence of The Scope of Tickets the address. Given these problems, and the cascad- Kerberos tickets are limited in both time and ing trust issue raised earlier, we suggest that ticket- space. That is, tickets are usable only within the forwarding be deleted. realm of the ticket-granting server, and only for a A new inter-realm authentication mechanism is limited period of time. The ®rst is necessary to the also introduced in Version 5. Brie¯y, if a user design of Kerberos; the TGS would not have any wishes to access a service in another realm, that user keys in common with servers in other realms. The must ®rst obtain a ticket-granting ticket for that latter is a security measure; the longer a ticket is in realm. This is done by making the ticket-granting use, the greater the risk of it being stolen or server in a realm the client of another realm's TGS. compromised. It in turn may be a client of yet another realm's A further restriction on tickets, in Version 4, is TGS. A user's ticket request is signed by each TGS that they cannot be forwarded. A user may obtain and passed along; realms will normally be con®gured tickets at login time, and use these to log in to some in a hierarchical fashion, though ``tandem links'' are other host; however, it is not possible to obtain permitted. authenticated network services from that host unless Unfortunately, this scheme, while appearing to a new ticket-granting ticket is obtained. And that in solve the problem, is de®cient in several respects. turn would require transmission of a password across First, and most serious, there is no discussion of how the network, in violation of fundamental principles a TGS can determine which of its neighboring 9 of Kerberos's design. realms should be the next hop. Moving up the tree, Version 5 incorporates provisions for ticket- towards the root, is an obvious answer for leaf forwarding; however, this introduces the problem of nodes; however, each parent node would need com- cascading trust. That is, a host A may be willing to plete knowledge of its entire subtree's realms in trust credentials from host B, and B may be willing order to determine how to pass the request down- to trust host C, but A may not be willing to accept wards. There are obvious analogies here to tickets originally created on host C, which A believes network-layer routing issues; note, though, that any to be insecure. Kerberos has a ¯ag bit to indicate ``realm routing protocol'' must include strong authentication provisions. 9Actually, a special-purpose ticket-forwarder was built Another answer is to say that static tables for Version 4. However, the implementation was of should be used. This, too, has its security limita- necessity awkward, and required participating hosts to run tions: should realm administrators rely on electronic an additional server. 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, We shall return to this point below. the security risks are obvious; if they are, the secu- We must now ensure that the protocol itself rity of a Kerberos realm is subordinated to the secu- does not provide a mechanism to obtain keys. Look- rity of a totally different authentication system. ing at the message de®nitions, we see that only ses- There is also an evident link between inter- sion keys are ever sent, and these are always sent realm authentication and the cascading-trust problem. encrypted. Furthermore, user machines never gen- Kerberos Version 5 attempts to solve this by includ- erate any such messages; they merely forward them. ing path information in the ticket request. However, Thus, the box need not have the ability to transmit a in the absence of a global name space, it is not clear key, thereby providing us with a very high level of that this is useful. If a realm is not a neighbor, its assurance that it will not do so. name may not carry any global sign®cance, whether If an encryption box is used for the Kerberos by malice or coincidence. Furthermore, to assess the server itself, the problem is somewhat more com- validity of a request, a server needs global plex. There are two places where keys are transmit- knowledge of the trustworthiness of all possible tran- ted. First, when a ticket is granted, the ticket itself sit realms. In a large internet, such knowledge is contains a session key, and a copy of that session probably not possible. key is sent back encrypted in the client's ticket- KERBEROS HARDWARE DESIGN CRITERIA granting session key. Second, during the initial dia- log with Kerberos, the ticket-granting session key A Host Encryption Unit must be sent out, encrypted in the client's password One of the major reasons we question the suita- key. Note, though, that permanent keys are never bility of Kerberos for multi-user hosts is the need for sent; again, this assures us that the encryption box plaintext key storage. What if the host were will not give away keys. Furthermore, since these equipped with an attached cryptographic unit? We session keys are intended to be random, we can buy consider the design parameters for such a box. ourselves a great deal of security by including a hardware random number generator on-board. The primary goal is to perform cryptographic operations without exposing any keys to comprom- We are not too concerned about having to load ise. These operations must include validating tickets client and server keys onto the board. This operation presented by remote users, creating requests for both is done only by the Kerberos master server, for ticket-granting tickets and application tickets, and which strong physical security must be assumed in encrypting and decrypting conversations. Conse- any event. It is possible that such an encryption unit quently, there must be secure storage for an adequate can be made suf®ciently tamper-resistant that even number of keys, and the must be workstations can use them; certainly, there are com- able to select which key should be used for which mercial cryptographic devices that claim such function. strengths. The next question, of course, is how keys are One major objection to this entire scheme is entered into the secure storage area. If tickets are that ultimately, the encryption box is controlled by decrypted by the encryption box but transferred to the host computer. Thus, if root is compromised, the host's memory for analysis, the embedded ses- the host could instruct the box to create bogus tick- sion key is exposed.10 Therefore, we conclude that ets. Such concerns are certainly valid. However, as the encryption box itself must understand the Ker- noted above, we consider such temporary breaches of beros protocols; nothing less will guarantee the secu- security to be far less serious than the compromise rity of the stored keys. of a key. Furthermore, using a separate unit allows us to create untamperable logs, etc. Entry of user keys is more problematic, since they must travel through the host. Unless user ter- It is also desirable to prevent misuse of keys. minals are connected directly to the encryption unit, For example, we do not want the login key used to there is little choice. Storing them off the host, decrypt the arbitrary block of text that just happens though, is a signi®cant help, as the period of expo- to be the ticket-granting ticket. Accordingly, keys sure is then minimized. Host-owned keys Ð service should be tagged with their purpose. A login key keys, or the keys that root would use to do NFS should be used only to decrypt the ticket-granting mounts Ð should be loaded via a Kerberos- ticket; the key associated with it should be used only authenticated service resident in the encryption unit. for obtaining service tickets, etc. Since the encryp- tion box is performing all of the key management, 10This is not a hypothetical concern. A program to do this is not a dif®cult problem. just that (for conventional passwords) was posted to net- news as long ago as 1984. It operated by reading The Key Storage Unit /dev/kmem. The existence of this program was a princi- pal factor motivating the current restrictive permission set- tings on /dev/kmem.

8 USENIX ± Winter '91 ± Dallas, TX Bellovin & Merritt Kerberos Limitations

A variety of technologies may be used to known by the adversary. Only cryptographic keys implement encryption units, ranging from special speci®cally assumed to be secret should be unavail- boards to dedicated microcomputers connected to able to an attacker.[Kahn67, Kerc83] Given this basic server hosts by physically-secure lines. If the latter premise, the security of a cryptographic system is is used, there is the temptation to use its disk storage evaluated based on concerted efforts at cryptanalysis. to hold the service keys associated with the attached Kerberos is designed primarily as an authentica- host, but we feel that that is inadvisable. Any media tion system incorporating a traditional cryptosystem of that sort must be backed up, and the backups (the ) as a component. must be carefully guarded. Such a high degree of Never the less, the philosophy guiding Kerckhoffs' security may be impractical in some environments. evaluation criterion applies to the evaluation of the Instead, we suggest that keys be kept in volatile security of Kerberos. The details of Kerberos's memory, and downloaded from a secure keystore on design and implementation must be assumed known request, via an encryption-protected channel. Thus, to a prospective attacker, who may also be in league only one master key need be stored within the box; with some subset of servers, clients, and (in the case this key could either be in non-volatile storage, or be of hierarchically-con®gured realms) some authentica- supplied by an operator when necessary. tion servers. Kerberos is secure if and only if it can More generally, the keystore is a secure, reli- protect other clients and servers, beginning only with able repository for a limited amount of information. the premise that these client and server keys are A client of the keystore could package arbitrary data secret, and that the encryption system is secure. to be retained by the keystore, and retrieved at a Moreover, in the absence of a central, trusted ``vali- later date. This data Ð the service keys and tags, in dation authority'', each prospective user of Kerberos the case of an encryption unit, or even a conven- is responsible for judging its security. Of course, a tional Kerberos host Ð would be uninterpreted by public discussion of system security and publication the keystore. Storage and retrieval requests would of security evaluations will facilitate such judge- be authenticated by Kerberos tickets, of course. ments. _ Only encrypted transfer (KRB PRIV) should be By describing the Kerberos design in publica- employed, as insurance against disclosure of such tions and making the source code publically avail- sensitive material. able, the Kerberos designers and implementors at As noted, the same keystore protocol could be Project Athena have made a commendable effort to used to supply additional keys for new instances of encourage just such a public system validation. the same client. For example, a user pat could have Obviously, this document is itself part of that pro- a separate instance pat.email, for receiving encrypted cess. However, the system design and its implemen- electronic mail. The key for that instance would be tation have undergone signi®cant modi®cation, in restricted to that user, of course. part as a consequence of this public discussion. We Generally, transactions with the keystore are stress that each modi®cation to the design and imple- initiated by the client. However, there is some ques- mentation results in a new system whose security tion about how to create the additional user keys, as properties must be considered anew. (Examples of user workstations are not particularly good sources such modi®cations are the incorporation of of random keys. The best alternative is to provide a hierarchically-organized servers and forwardable tick- (secure) random number service on the network. ets in Version 5.) When a new client instance is added, this service Hence, on-going modi®cation of Kerberos would be consulted to generate the key; both Ker- makes it a moving target for security validation beros and the keystore would be told about the key. attempts. A detailed security analysis would thus be premature. However, the proposed changes to Ker- SECURITY VALIDATION beros in the next few section are intended, not so Is Kerberos correct? By that we are asking if much to defeat speci®c attacks, as to facilitate the there are bugs (or trapdoors!) in the design or validation process. In particular, these suggestions implementation of Kerberos, bugs that could be used are intended to make Kerberos more modular, in to penetrate a system that relies on Kerberos. Some design and implementation. Doing so should make would say that by making the code widely available, the security consequences of modi®cations more the implementors have enabled would-be penetrators apparant, and facilitate an incremental approach to to gain a detailed knowledge of the system, thereby Kerberos security validation. simplifying their task considerably. We reject that notion. Message Encoding and Cut-and-Paste Attacks In the late nineteenth century, Kerckhoffs for- The most simple analysis of the security of the Ker- mulated the basic principal under which the security beros protocols should check that there is no possi- of cryptographic systems should be evaluated: all bility of ambiguity between messages sent in dif- details of the system design should be assumed to be 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 implementations and validations involving alternative an analysis depends on redundancy in the pre- cryptosystems. Too much focus on mechanism, encryption binary encodings of each of the ticket and while endemic to design, authenticator information. Currently, that analysis leads away from the need to state the basic proper- must be repeated with every modi®cation to the pro- ties required of the encryption layer. We would sug- tocol. This repetitive and often intricate analysis gest the following adversarial analysis as the starting would be unnecessary if standard encodings (such as point for such a speci®cation: allow an adversary to ASN.1)[ASN1, BER] were used. These encodings submit, one after the other, any number of messages should include the overall message type (such as for encryption under an unknown key K. The adver- KRB_TGS_REP or KRB_PRIV). Together with rea- sary also has the ability to take pre®xes and suf®xes sonable assumptions about the encryption layer (see of known messages, exclusive-or known messages, the next section), such an encoding scheme would and encrypt or decrypt with known keys. At the end greatly simplify the protocol validation process, par- of this process, the adversary should not be able to ticularly as the protocol is modi®ed or extended. produce any encrypted messages other than those Some use of ASN.1 encodings has been speci®cally submitted for encryption. Such an adopted for other reasons in Version 5. We rein- analysis would preclude encryption schemes suscep- force here that there are design principles other than tible to simple chosen-plaintext attacks, as described standards compatibility that motivate such a change. in a previous section. Given the intractability of reasoning about The Encryption Layer DES, or of proving complexity properties of any cryptosystem with bounded key size, such analyses Version 4 of Kerberos uses the nonstandard PCBC will be no guarantee of overall security. But they mode of encryption, propagating cipher block chain- can be used to preclude the existence of trivial cut- ing, in which plaintext block i + 1 is exclusive-or'ed and-paste attacks.[DeMi83, Moor88] with both the plaintext and ciphertext of block i before encryption. This mode was observed to have RECOMMENDED CHANGES TO THE poor propagation properties that permit message- KERBEROS PROTOCOL stream modi®cation: speci®cally, if two blocks of ciphertext are interchanged, only the corresponding Below, we list our recommended changes to the Ker- blocks are garbled on decryption. Version 5 replaces beros protocol. Our ranking is governed by our esti- PCBC mode with the standard CBC mode, cipher mate of the likelihood and consequences of the block chaining, which exclusive-or's just the cipher- attack, balanced against the dif®culty of implement- text of block i with the plaintext of block i + 1 before ing the modi®cation. encryption. A checksum Ð as of Draft 2, the exact a. A challenge/response protocol should be form had not been determined Ð is used to detect offered as an optional alternative to time- message modi®cation. In order to ensure that dupli- based authentication. cate messages have different encryptions, random b. Use a standard message encoding, such as initial ``confounders'' are added to some message ASN.1, which includes identi®cation of the formats. In addition, Version 5 supports alternative message type within the encrypted data. encryption algorithms as options. c. Alter the basic login protocol to allow for { } handheld authenticators, in which R K C, for Both the confounder and checksum mechanisms a random R, is used to encrypt the server's are meant to augment the security of CBC encryp- reply to the user, in place of the key K C tion. They belong in a separate encryption layer, not obtained from the user password. This allows at the level of the Kerberos protocols themselves. the login procedure to prompt the user with R, Further, the confounder mechanism should be { } who obtains R K C from the handheld device replaced by using the standard initial vector mechan- and returns that value instead of the password ism of cipher-block chaining.[FIPS81, Davi89] itself. To prevent message-stream modi®cation during d. Mechanisms such as random initial vectors (in authenticated or private sessions, Version 5 uses a place of confounders), block chaining and timestamp ®eld to prevent entire encrypted messages message authentication codes should be left to from being replayed. This is another concern more a separate encryption layer, whose properly delegated to the encryption layer, where information-hiding requirements are clearly chaining across the packets of the entire session is explicated. Speci®c mechanisms based on the more standard mechanism. (Such chaining DES should be validated and implemented. avoids both the dependence on a clock and the need e. The client/server protocol should be modi®ed to cache recent timestamps.) so that the multi-session key is used to nego- Separating the Kerberos protocols from the tiate a true session key, which is then used to details of encryption would facilitate both validation protect the remainder of the session. of the security of the Kerberos protocols, and 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- of the server to the client via a nonce ®eld, tantly, future enhancements to the Kerberos instead of depending on the workstation time. protocol should be designed under the For application servers, the e − data ®eld in assumption that a host, particularly a multi- the KRB_AP_ERR_METHOD error message user host, may be using encryption and key- can be used by the server to signal the client storage hardware. to use a challenge/response alternative to the g. To protect against trivial password-guessing time-based kerberos authentication. attacks, the protocol should not distribute tick- b. All encrypted data is labeled with the message ets for users (encrypted with the password- type prior to encryption, via full integration of based key), and the initial exchange should the ASN.1 standard. Although there were authenticate the user to the Kerberos server. many reasons for this decision, we applaud its h. Support for optional extensions should be bene®cial impact on security. included. In particular, an option to protect c. An optional padata ®eld will probably be against password-guessing attacks via eaves- added to the KRB_AS_REP to allow for dropping may be a desirable feature. handheld authenticator protocol extensions. d. As discussed, mechanisms such as random ini- ACKNOWLEDGEMENTS tial vectors (in place of confounders), block We would like to thank D. Davis and T.H. chaining and message authentication codes are Foregger for their comments on an early draft. We'd now left to a separate encryption layer, with a especially like to thank C. Neuman for his detailed much clearer discussion of requirements and reviews of many versions of the paper, and his wil- of speci®c mechanisms based on DES. lingness to discuss the issues with us. W. Griffeth e. Optional ®elds will probably be added to the helped us with preparation of the appendix on AP_REQ and AP_REP messages to support Draft 3. Finally, we'd like to thank the Project the negotiation of true session keys. Athena and Kerberos development staff for their ini- f. Addition of optional ®elds (such as padata) tial design and implementation of Kerberos, their should facilitate extensions that exploit solicitation of comments, and their responsiveness to special-purpose hardware. our criticisms. g. The initial exchange still does not authenticate the user to the Kerberos server. Thus, the APPENDIX: VERSION 5 DRAFT 3 Kerberos equivalent of /etc/passwd must be treated as public, and passwords must be Draft 3 has gone a long way towards alleviating chosen and administered with password- our concerns. Many problems have been ®xed, and guessing attacks in mind. However, the provisions have been made for compatible enhance- padata ®eld facilitates optional implementa- ments to resolve other outstanding issues. These are tion of such preauthentication mechanisms. being re®ned in ongoing discussion. Still, some h. As above, several optional ®elds facilitate issues remain unresolved or unaddressed. In addi- extensions such as exponential-key exchange tion, we raise new issues related to older areas of the to protect against password-guessing via speci®cation. eavesdropping. In a few places, we mention changes that may The following sections discuss some of the revisions be made in future revisions of the speci®cation; the in Draft 3 in more detail, and raise some new issues. reader is cautioned that these represent our under- standing, and only our understanding, of a continuing Login Dialog process. The login dialog has been enhanced to include With one exception, this summary omits areas an additional authentication data ®eld. This can be where the authors' intent was clear or was clari®ed used to support hand-held authenticators, pre- in private communications. That exception Ð a way encryption of the original request, and future exten- to misuse weak checksums to subvert bidirectional sions. This is a signi®cant enhancement, but we authentication Ð we include to demonstrate the deli- regret that support for hand-held authenticators and cacy inherent in the design and speci®cation of pre-encryption is not yet a part of the standard. authentication protocols. In particular, the optional ®eld in the request message can support some sort of pre-encryption. Draft 3 and Our Recommended Changes For example, the nonce ®eld can be sent both in the We begin by reviewing our recommended changes in clear and encrypted in the user's login key, thereby light of Draft 3 and subsequent discussions with its demonstrating that the client is legitimate, and pre- authors. cluding remote collection of tickets encrypted with a. The KRB_AS_REQ/KRB_AS_REP and the user's key. As discussed in the main body of KRB_TGS_REQ/KRB_TGS_REP exchanges this paper, we feel such a mechanism should be now provide challenge/response authentication 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 new message with the same checksum. The CRC-32 need to provide grist for their mill. checksum is not collision-proof, while MD4 is As currently released, a challenge-response dia- believed to be. Note that encrypting a checksum log cannot be implemented by the Draft 3 reply for- provides very little protection; if the checksum is not mat. While the request message possesses the collision-proof and the data is public, an adversary optional extra ®eld, the reply does not, and hence can compute the value and replace the data with cannot carry the encrypted key. Adding this ®eld another message with the same checksum value. would also permit compatible support of exponential (Several such attacks are indicated below.) key exchange, wherein each party must send a ran- dom exponential. We understand that the optional Weak Checksums and Cut-and-Paste Attacks ®eld will probably be added to the reply. One of the major changes in Draft 3 was the removal of encryption protection from the additional The Encryption and Checksum Layers tickets and data that may be enclosed There is now a separate, well-de®ned encryp- with certain requests. These ®elds are protected by a tion layer, with speci®ed properties. Among these checksum sealed in the encrypted authenticator sent are that the encryption module be capable of detect- with the request. Assume that the checksum algo- ing any tampering with the message. The only sup- rithm used is CRC-32. (This is permitted by a literal ported method, in this version, is a CRC-32 check- reading of Draft 3, though we have learned that this sum sealed within the encrypted portion of the mes- was not the intent of the authors.) With this sage. assumption, the existence of the ENC-TKT-IN- SKEY option leads to a major security breach, and The encryption layer also reaps the bene®t of in particular to the complete negation of bidirectional the ASN.1 encoding. Since the encoding includes a authentication. length ®eld, it is no longer possible for an attacker to truncate a message, and present the shortened form As usual, the client, possessing a valid ticket- as a valid encrypted message. If a decision were granting ticket, sends off a request for a new ticket ever made to replace ASN.1 (say, with something for some service S. The enemy intercepts this more ef®cient), this property would need to be request and modi®es it. First, the ENC-TKT-IN- preserved. SKEY bit is set. This speci®es that the ticket, nor- mally encrypted in S's key, should be encrypted in The confounder has now been moved to the the session key of the enclosed ticket-granting ticket. encryption layer, but there is still some confusion of Second, the attacker's own ticket-granting ticket is function with the IV used by CBC-mode encryption. enclosed. Obviously, the attacker knows its session As commonly used, an IV is a confounder (see, for key. Finally, the additional authorization data ®eld example, [Voyd83]); to hold it constant during a ses- is ®lled in with whatever information is needed to sion negates its purpose and thus requires the addi- make the CRC match the original version. tional confounder. We suggest that the IV be used as intended, and be incremented or otherwise altered Consider what happens. The ticket-granting after each message. Initial values for it should be service, seeing a valid request, sends back a ticket. exchanged during (or derived from) the authentica- This ticket, encrypted in the enemy's key, will not tion handshake. Apart from simplifying the be intelligible to the real service, but of course, it de®nition of the encryption function, this scheme will not get that far. The legitimate client cannot tell would also allow detection of message deletions by that the ticket is misencrypted; tickets are, almost by interested applications. de®nition, encrypted in a key known only to the server and Kerberos. When the service is requested, It could be argued that requiring the IV to be the enemy intercepts the request and unseals the handled at a higher layer violates the layering we ticket. The client may request bidirectional authenti- have espoused. However, an IV is as much an attri- cation; however, since the attacker has decrypted the bute of a cryptosystem as is a key. It would be rea- ticket, the session key for that service request is sonable to encapsulate the de®nition of the IV into available. Consequently, the bidirectional authentica- the de®nition of the key object passed down to the tion dialog may be spoofed without trouble. encryption layer. A number of different factors interacted to The properties required of checksums are not as make this attack possible. One is obvious: the well-de®ned. Three types are speci®ed: CRC-32, ticket request was protected by what turned out to be MD4 and MD4 encrypted with DES.[Rive90] How- a weak checksum. If a collision-proof checksum ever, no mention is made of their attributes, save that were used, the attack would be infeasible; the enemy some are labeled ``cryptographic''. This is a crucial could not have generated the additional authorization omission, as discussed below. A better classi®cation data ®eld necessary to make the new request's is whether or not a checksum is ``collision-proof'', checksum match the original. But there are that is, whether or not an attacker can construct a 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 Second, the REUSE-SKEY and ENC-TKT-IN- would have been adequately protected by the very SKEY options ``overload'' the basic protocol, in that same CRC-32 checksum that was abused in the tickets may now share session keys or be encrypted attack. However, because of the encryption, the in keys other than the service. It is possible that enemy would be unable to either discern or match there are other ways an attack could exploit the the checksum. In other words, the context is critical; ensuing ambiguities. These options are intended for merely refraining from re-encrypting some encrypted very constrained uses, not general authentication; data, while using the same checksum to protect it, they should not be so intimately integrated into the has led to a security breach. (Note: we have been basic . The same purposes told that the designers intended to require that the would be served by adding separate message types cname in the additional ticket match the name of the that cannot be misinterpreted as tickets, and using server for which the new ticket is being requested. keys that are derived from but are not identical to This requirement would still permit the intended use those used in the basic protocol. of the option, but would foil the attack we describe. Even then, an analysis of the ®nal standard is Apparently, the requirement was inadvertently omit- needed, to assure that a minor extension has not ted from Draft 3.) negated a security-critical assumption. (E.g., the A similar attack may be possible using the basic Kerberos protocol assumes that no two tickets REUSE-SKEY option. This option was designed for share a session key, and that tickets are always multicast key distribution; with a weak checksum, an encrypted with the server's key.) attacker can abuse it to generate a service ticket whose key is known. The REUSE-SKEY option KRB_SAFE and KRB_PRIV Messages also permits a related, albeit less serious, attack. If The KRB_SAFE and KRB_PRIV messages two tickets, T1 and T2, share the same key, the employ the session key distributed with the ticket for attacker can intercept a request for one service, and integrity-checking and privacy, respectively. Draft 3 redirect it to the other. Since the two tickets share dictates that both use time-of-day values to guard the same key, the authenticator will be accepted. against replay, which may be problematic. Just how damaging this possibility is depends on Currently, the resolution of the timestamp is limited what sorts of services might want to share the same to 1 millisecond, which is far too coarse for many key. If, say, a ®le server and a backup server were applications. (This and other timestamps in the pro- invoked this way, an attacker might redirect some tocol will probably be changed to microsecond reso- requests to destroy archival copies of ®les being lution.) edited. A solution to this particular attack is to include either the service name, a collision-proof A second problem area is the need for a cache checksum of the ticket, or both, in the authenticator. of recently-used timestamps. Obviously, if such To be sure, Draft 3 explicitly warns against using messages are used for things like ®le system tickets with DUPLICATE-SKEY set for authentica- requests, the size of the cache could rapidly become tion. Servers that obey this restriction are not unmanageable. Furthermore, if two authenticated or vulnerable to this attack. Also, we have been told encrypted sessions run concurrently, the cache must that the REUSE-SKEY option will probably be omit- be shared between them, or messages from one ses- ted in future revisions of the protocol. sion can be replayed into the other. A last attack of this sort can occur if the Both problems can be solved if the idea of a attacker substitutes a different ticket for the legiti- timestamp is abandoned in favor of sequence mate one in key distribution replies from Kerberos. numbers. A random initial sequence number can be The encrypted part of such a message does not con- transmitted with the authenticator and/or in the tain any checksum to validate that the message was KRB_AP_REP message; after each authenticated not tampered with in transit. While this appears to message is sent, it would, of course, be incremented. be more a denial-of-service attack than a penetration, The cache is then a simple last-message counter. it would be useful for the client to know this This mechanism also provides the ability to detect immediately. deleted messages, by watching for gaps in sequence number utilization. And, since each session would Two issues underly this list of potential attacks. have its own initial sequence number, it would not As discussed, weak checksums (encrypted but not be possible for an attacker to perform cross-stream collision-proof, and over public data) allow an adver- replays, and concurrent access to a common cache is sary to paste together legitimate-looking messages. not necessary. (This advantage would be gained Message integrity via strong checksums and/or even with timestamps if true session keys were encryption should be extended to as many protocol used.) It is likely that in a future revision, sequence messages (and as many ®elds) as possible. numbers will be provided as an alternative to the use of timestamps.

USENIX ± Winter '91 ± Dallas, TX 13 Kerberos Limitations Bellovin & Merritt

Authenticators NEW RECOMMENDED CHANGES Draft 3 still calls for the use of authenticators Below, we include a new list of recommended to guard against ticket replay. However, there is changes, beyond those we have indicated are likely now a provision for the server to specify that addi- to be adopted. The ®rst two are repeated from our tional authentication is required, and an optional data earlier list, and are now (or will be) implementable ®eld for this has been added to the KRB_ERROR as options; we repeat them here to stress our belief reply message. This can be used to implement that they should be a mandatory part of the protocol. challenge/response schemes. a. Alter the basic login protocol to allow for The authenticator should have some other ®elds challenge/response handheld authenticators. added to it, some of them optional. As noted earlier, b. The initial exchange should authenticate the it must contain a collision-proof checksum linking it user to the Kerberos server, to complicate to the ticket, and an optional initial sequence password-guessing attacks. number. The latter would be used by any applica- c. Strong checksums, encryption, and additional tions that might wish to exchange encrypted or ®elds should be used to assure integrity of the authenticated messages. basic Kerberos messages. (For example, tick- The authenticator is also the right place to ets should be tied more closely to the contexts negotiate a true session key. We propose adding a in which they are used, by including service new ®eld for it to both the authenticator and the names in the ticket, and the encrypted part of _ _ _ _ KRB_AP_REP message. The actual session key KRB AS REP and KRB TGS REP should could be formed by an exclusive-or of the multises- contain collision-proof checksums of the tick- sion key associated with the ticket, a randomly- ets.) generated ®eld in the authenticator, and a similar d. Protocol extensions not related to basic ®eld in the reply message. Note that this retains a authentication (the ENC-TKT-IN-SKEY and measure of compatibility with the current scheme: if REUSE-SKEY options) should be omitted or the two optional ®elds are not present, the multi- use distinct message and ticket formats. session key will be used as the actual session key. References Negotiation of true session keys, initial sequence numbers, and confounders or IV's could be FIPS81. ``DES Modes of Operation,'' Federal combined in one standard mechanism, perhaps sub- Information Processing Standards Publication sumed as encryption-speci®c sub®elds of the session 81 (December 1980). National Bureau of Stan- key ®elds. dards, U.S. Department of Commerce ASN1. ``Information Processing Systems Ð Open Inter-Realm Authentication Systems Interconnection Ð Speci®cation of Abstract Syntax Notation One (ASN.1),'' Inter- Inter-realm authentication is still problematic. national Standard 8824 (1987). International Granted that static con®guration ®les can tell a Ker- Organization for Standardization and Interna- beros server who its parent is, and even the identities tional Electrotechnical Committee of all of its children, there is still no scalable mechanism to learn of grandchildren or more distant BER. ``Information Processing Systems Ð Open descendants. Systems Interconnection Ð Speci®cation of Basic Encoding Rules for Abstract Syntax To be sure, it is apparently the intention of the Notation One (ASN.1),'' International Standard authors that the Internet's domain name space be 8825 (1987). International Organization for used to denote realms, and Ð implicitly Ð the Standardization and International Electrotechni- hierarchy of servers. It is far from clear to us that cal Committee the two hierarchies coincide. Furthermore, such usage is not required. No alternative routing Beke82. H. Beker and F. Piper, Cipher Systems, mechanism has been suggested. John Wiley & Sons (1982). Additionally, there are several pieces of the Brya88. B. Bryant, Designing an Authentication protocol that are unclear or simply do not work with System: A Dialogue in Four Scenes, Draft inter-realm tickets. For example, ENC-TKT-IN- February 8, 1988. SKEY and REUSE-KEY require the ticket-granting Davi89. D.W. Davies and W.L. Price, Security for server to decrypt a ticket. It cannot do this if the Computer Networks, John Wiley & Sons ticket had been issued by another realm. Presum- (1989). Second Edition ably, of course, the request could be sent to the other Davi90. D. Davis and R. Swick, Workstation Ser- realm's ticket-granting server, but it may not possess vices and Kerberos Authentication at Project the necessary key to generate the new ticket. 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, Post81. J.B. Postel, ``Transmission Control Proto- Artech House (1985). col.,'' RFC 793 (September 1981). DeMi83. R. DeMillo and M. Merritt, ``Protocols Post83. J.B. Postel and K. Harrenstien, ``Time Pro- for Data Security,'' Computer 16(2) pp. 39-50 tocol.,'' RFC 868 (May 1983). (February 1983). Rive90. R.L. Rivest, ``MD4 message digest algo- Diff76. W. Dif®e and M.E. Hellman, ``New Direc- rithm,'' RFC 1186 (October 1990). tions in Cryptography,'' IEEE Transactions on Salt90. J.H. Saltzer, private communication June Information Theory 6 pp. 644-654 (November, 19, 1990. 1976). Stei88. J. Steiner, C. Neuman, and J.I. Schiller, Gram84. F.T. Grampp and R.H. Morris, ``Operat- ``Kerberos: An Authentication Service for Open ing System Security,'' AT&T Bell Laboratories Network Systems,'' in Proc. Winter USENIX Technical Journal 63(8, Part 2) pp. 1649-1672 Conference, , Dallas (1988). A&T, (October, 1984). Stol88. C. Stoll, ``Stalking the Wiley Hacker,'' Kahn67. D. Kahn, Codebreakers: The Story of Communications of the ACM 31(5) p. 484 (May Secret Writing, Macmillan (1967). 1988). Kerc83. A. Kerckhoffs, La Cryptographie Mili- Voyd83. V.L. Voydock and S.T. Kent, ``Security taire, Libraire Militaire de L. Baudoin & Cie., Mechanisms in High-Level Network Proto- Paris (1883). cols,'' ACM Computer Surveys 15(2) pp. 135- Kohl89. J. Kohl, B. Clifford Neuman, and J. 171 (June, 1983). Steiner, The Kerberos Network Authentication Service, MIT Project Athena (November 6, Steven M. Bellovin received a 1989). Version 5, Draft 2 B.A. degree from Columbia Kohl90. J. Kohl, B. Clifford Neuman, and J. University, and an M.S. and Steiner, The Kerberos Network Authentication Ph.D. in Computer Science Service, MIT Project Athena (October 8, 1990). from the University of North Version 5, Draft 3 Carolina at Chapel Hill. While a graduate student, he wrote the LaMa. B.A. LaMacchia and A.M. Odlyzko, Com- original version of pathalias putation of Discrete Logarithms in Prime and helped create netnews. Fields, (Manuscript in preparation) However, the former is not an Loma89. T.M.A. Lomas, L. Gong, J.H. Saltzer, indictable offense, and the and R.M. Needham, ``Reducing Risks from statute of limitations on the latter has expired. Poorly Chosen Keys,'' Operating Systems Nevertheless, he is still atoning for both actions. He Review 23(5) pp. 14-18 ACM, (December has been at AT&T Bell Laboratories since 1982, 1989). where he does research in networks, security, and Mill87. S.P. Miller, B.C. Neuman, J.I. Schiller, why the two don't get along. He may be reached and J.H. Saltzer, ``Kerberos Authentication and electronically as [email protected]; those Authorization System,'' in Project Athena who prefer to murder trees may send scraps of paper Technical Plan, (December 1987). Section to Room 3C-536B, AT&T Bell Laboratories, 600 E.2.1 Mountain Avenue, Murray Hill, NJ 07974, U.S.A. Mill88. D.L. Mills, ``,'' Michael Merritt received a B.S. RFC 1059 (July 1988). from Yale University, and an Mill89. D.L. Mills, ``Network Time Protocol,'' M.S. and Ph.D. in Information RFC 1119 (September 1989). and Computer Science from the Moor88. J.H. Moore, ``Protocol Failures in Cryp- Georgia Institute of Technol- tosystems,'' Proc. IEEE 76(5) pp. 594-602 ogy. His dissertation, "Crypto- (May 1988). graphic Protocols", developed Morr79. R. Morris and K. Thompson., ``UNIX techniques for exploring secu- Password Security,'' Communications of the rity properties of distributed ACM 22(11) p. 594 (November 1979). algorithms. He has been at AT&T Bell Laboratories since Morr85. R.T. Morris, ``A Weakness in the 4.2BSD 1983, where he does research in distributed systems TCP/IP Software,'' Computing Science Techni- and security. His email address is cal Report No. 117, AT&T Bell Laboratories, [email protected]; paper to Room Murray Hill, New Jersey (February 1985). 3D-458, AT&T Bell Laboratories, 600 Mountain Post80. J.B. Postel, ``User Datagram Protocol.,'' Avenue, Murray Hill, NJ 07974, U.S.A. RFC 768 (August 28, 1980).

USENIX ± Winter '91 ± Dallas, TX 15 16 USENIX ± Winter '91 ± Dallas, TX