The Kerberos authentication system, a part of MIT's Project Athena, has bee n adopted by other organizations . Despite Kerberos's many strengths, it has a numbe r of limitations and some weaknesses . Some are due to specifics of the MIT environment; others represent deficiencies in the protocol design . We discuss a number of such problems, and present solutions to some of them . We also demonstrate how special-purpose cryptographic hardware may be needed in som e cases . The Kerberos authentication system [steiss, Mi1187, Brya88] was introduced by MIT to meet the needs of Projec t Athena . It has since been adopted by a number of other organizations for their own purposes, and is bein g discussed as a possible standard . In our view, both these decisions may be premature. Kerberos has a number of limitations and weaknesses ; a decision to adopt or reject it cannot properly be made withou t considering these issues . (A limitation is a feature that is not as general as one might like, while a weakness could be exploited by an attacker to defeat the authentication mechanism .) Some improvements can be mad e within the current design . Support for optional mechanisms would extend Kerberos's applicability t o environments radically different from MIT . These problems fall into several categories . Some stem from the Project Athena environment . Kerberos was designed for that environment ; if the basic assumptions differ, the authentication system may need to b e changed as well . Other problems are simply deficiencies in the protocol design . Some of these are correcte d in the proposed Version 5 of Kerberos, FKohls9] but not all . Even the solved problems merit discussion, since the code for Version 4 has been widely disseminated . Finally, some problems with Kerberos are no t solvable without employing special-purpose hardware, no matter what the design of the protocol . We wil l consider each of these areas in turn . We wish to stress that we are not suggesting that Kerberos is useless . Quite the contrary -an attacker capable of carrying out any of the attacks listed here could penetrate a typical network of UNix ® systems far more easily . Adding Kerberos to a network will, under virtually all circumstances, significantly increase its security ; our criticisms focus on the extent to which security is improved . Further, we recommend change s to the protocols that substantially increase security . Beyond its specific utility in production, Kerberos serves a major function by focusing interest on practica l solutions to the network authentication problem . The elegant protocol design and wide availability of th e code has galvanized a wide audience. Far from a condemnation, our critique is intended to contribute to an understanding of Kerberos's properties and to influence its evolution into a tool of greater power and utility . Several of the problems we point out are mentioned in the original Kerberos paper or elsewhere . [Davi90] Fo r some of these, we present protocol improvements that solve, or at least ameliorate, the problem ; for others , * Author's address : Steven M. Bellovin, Room 3C-536B, AT&T Bell Laboratories, 600 Mountain Avenue, Murray Hill, New Jersey 07974, f Author's address : Michael Merritt, Room 3D-458, AT&T Bell Laboratories, 600 Mountain Avenue, Murray Hill, New Jersey 07974 . -119-we place them squarely in the context of the intended Kerberos environment . Kerberos is a security system ; thus, though we address issues of functionality and efficiency, our primar y emphasis is on the security of Kerberos in a general environment . This means that security-critical assumptions must be few in number and stated clearly . For the widest utility, the network must b e considered as completely open . Specifically, the protocols should be secure even if the network is under th e complete control of an adversary . ) This means that defeating the protocol should require the adversary t o invert the encryption algorithm or to subvert a principal specifically assumed to be trustworthy . Only such a strong design goal can justify the expense of encryption . (No "steel doors in paper walls") We believ e that Kerberos can meet this ambitious goal with only minor modifications, retaining its essential character . Some of our suggestions bear a performance penalty ; others complicate the design of suggested enhancements . As more organizations make use of Kerberos, pressures to enhance or augment its functionality and efficiency will increase . Security has real costs, and the benefits are intangible . There must be a continuing and explicit emphasis on security as the overriding requirement . It is not sufficient to design and implement a security system . Such systems, though apparently adequate when designed, may have serious flaws . Consequently, systems must be subjected to the strongest scrutin y possible . A consequence of this is that they must be designed and implemented in a manner that facilitate s such scrutiny. Kerberos has a number of problems in this area as well . Before discussing specific problem areas, it is helpful to review Kerberos Version 4 . Kerberos is an authentication system ; it provides evidence of a principal's identity . A principal is generally either a user o r a particular service on some machine . A principal consists of the three-tupl e <primaryname, instance, realm> . If the principal is a user -a genuine person -the primary name is the login identifier, and the instance is either null or represents particular attributes of the user, i .e., root . For a service, the service name is used as the primary name and the machine name is used as the instance, i .e ., rlogin .myhost . The realm is used to distinguish among different authentication domains ; thus, there need not be one giant -an d universally trusted -Kerberos database serving an entire company . Kerberos principals may obtain tickets for services from a special server known as the ticket-granting server , or TGS . A ticket contains assorted information identifying the principal, encrypted in the private key of th e service . (Notation is summarized in Table 1 . ) {Tc, S}Ks={s, c, addr, timestamp, lifetime, K c Since only Kerberos and the service share the private key K s , the ticket is known to be authentic . The ticke t contains a new private session key, K c,s , known to the client as well ; this key may be used to encryp t transactions during the session . 2 To guard against replay attacks, all tickets presented are accompanied by an authenticator : 1. The Project Athena Technical Plan] Mft8l , sect10n 2] describes a simpler threat environment, where eavesdropping and hos t impersonation are of primary concern . While this may be appropriate for MIT, it is by no means generally true . Consider, fo r example, a situation where general-purpose hosts also function as routers, and packet modification or deletion become significan t concerns. 2. Technically speaking, K, ,, is a multi-session key, since it is used for all contacts with that server during the life of the ticket . -120- This is a brief string encrypted in the session key and containing a timestamp ; if the time does not match th e current time within the (predetermined) clock skew limits, the request is assumed to be fraudulent . For services where the client needs bidirectional authentication, the server can reply wit h This demonstrates that the server was able to read timestamp from the authenticator, and hence that it kne w K c,s ; that in turn is only available in the ticket, which is encrypted in the server's private key . In other words, an ordinary ticket/authenticator pair is used ; the ticket is known as the ticket-granting ticket . The TGS responds with a ticket for server s and a copy of K, ,s , all encrypted with a private key shared b y the TGS and the principal : The session key K, ,s is a newly-chosen random key . The key K c,tgs and the ticket-granting ticket itself, are obtained at session-start time . The client sends a message to Kerberos with a principal name ; Kerberos responds wit h {K c,tgs ,{T c,tgs }Ke gs }K c The client key K c is derived from a non-invertible transform of the user's typed password . Thus, al l privileges depend ultimately on this one key . Note that servers must possess private keys of their own, in order to decrypt tickets . These keys are stored in a secure location on the server's machine . The Project Athena computing environment consists of a large number of more or less anonymou s workstations, and a smaller number of large autonomous server machines . The servers provide volatile file storage, print spooling, mailboxes, and perhaps some computing power ; the workstations are used for mos t interaction and computing . Generally, they possess local disks, but these disks are effectively read-only ; they contain no long-term user data . Furthermore, they are not physically secure ; someone so inclined could remove, read, or alter any portion of the disk without hindrance . Within this environment the primary need is for user-to-server authentication . That is, when a user sits dow n at a workstation, that person needs access to private files residing on a server . The workstation itself has n o such files, and hence has no need to contact the server or even to identify itself . -121-This is in marked contrast to a typical UNIX system's view of the world. Such systems do have an identity , and they do own files . Assorted network daemons transfer files in the background, clock daemons perfor m management functions, electronic mail and news arrives, etc . If such a machine relied on servers to store it s files, it would have to assert, and possibly prove, an identity when talking to these servers . The Projec t Athena workstations are neither capable nor in need of such ; they in effect function as very smart terminal s with substantial local computing power, rather than as full computer systems . 3 What does this mean for Kerberos? Simply this : Kerberos is designed to authenticate the end-user -th e human being sitting at the keyboard -to some number of servers . It is not a peer-to-peer system ; it is no t intended to be used by one computer ' s daemons when contacting another computer . Attempting to use Kerberos in such a mode can cause trouble. 4 We make this statement for several reasons . First and foremost, typical computer systems do not have a secure key storage area . In Kerberos, a plaintext key must be used in the initial dialog to obtain a ticketgranting ticket . But storing plaintext keys in a machine is generally felt to be a bad idea ; [Morr79] if a Kerberos key that a machine uses for itself is compromised, the intruder can likely impersonate any user o n that computer, by impersonating requests vouched for by that machine (i .e ., file mounts or cron jobs) .5 Additionally, the session keys returned by the TGS cannot be stored securely ; of necessity, they are stored in some area accessible to root . Thus, if the intruder can crack the protection mechanism on the loca l computer -or, perhaps more to the point, work around it for some limited purposes -all current sessio n keys can be stolen . This is less serious than a breach of the primary Kerberos key, of course, since sessio n keys are limited in lifetime and scope; nevertheless, one does not wish these keys exposed . This points out a second flaw when multi-user computers employ Kerberos, either on their own behalf or fo r their users : the cached keys are accessible to attackers logged in at the same time . In a workstation environment, only the current user has access to system resources ; there is little or no need even to enabl e remote login to that workstation . There are many reasons for this ; a consequence, though, is that th e intruder simply cannot approach the safe door to try to pick its lock . 6 Only when the legitimate user leaves can the attacker attempt to find the keys . But the keys are no longer available ; Kerberos attempts to wip e out old keys at logoff time, leaving the attacker to sift through the debris . With a multi-user computer, on the other hand, an attacker has concurrent access to the keys if there are flaws in the host's security . There are two other minor flaws in Kerberos directly attributable to the environment . First, there is som e question about where keys should be cached . Since all of the Project Athena machines have local disks, th e original code used /tmp . But this is highly insecure on diskless workstations, where /tmp exists on a fil e server ; accordingly, a modification was made to store keys in shared memory . However, there is no guarantee that shared memory is not paged ; if this entails network traffic, an intruder can capture these keys . Finally, the Kerberos protocol binds tickets to IP addresses . Such usage is problematic on on multi-homed hosts (i .e ., hosts with more than one IP address) . Since workstations rarely have multiple addresses, this feature -intended to enhance security -was not a problem at MIT . Multi-user hosts often do hav e multiple addresses, however, and cannot live with this limitation . This problem has been fixed in Version 5 . 3. We regard this as a feature, not a bug . 4. More precisely, Kerberos is not a host-to-host protocol . In Version 5, it has been extended to support user-to-use r 5. Recall that we are assuming here that the machine -and hence its superuser -needs an identity of its own . 6. On Project Athena machines, remote access to most workstations is in fact disabled . -122- The Kerberos protocol is not as resistant to penetration as it should be . A number of weaknesses are apparent; the most serious is its use of an authenticator to prevent replay attacks . The authenticator relies on use of a timestamp to guard against reuse. This is problematic for several reasons . The claim is made that no replays are likely within the lifetime of the authenticator (typically five minutes) . This is reinforced by the presence of the IP address in both the ticket and the authenticator . We are not persuaded by this logic . An intruder would not start by capturing a ticket and authenticator, and then develop the software to use them ; rather, everything would be in place before the ticket-capture wa s attempted . Let us consider two examples . Some years ago, Morris described an attack based on the slow increment rate of the initial sequence number counter in some TCP implementations . iM°r r85] He demonstrated that it was possible, under certai n circumstances, to spoof one half of a preauthenticated TCP connection without ever seeing any response s from the targeted host . In a Kerberos environment, his attack would still work if accompanied by a stole n live authenticator, but not if a challenge/response protocol was used . Alternatively, an intruder may simpl y watch for a "mail-checking" session, wherein a user logs in briefly, reads a few messages, and logs out . A number of valuable tickets would be exposed by such a session, notably the one used to mount the user' s home directory . Note that the lifetime of the authenticators -5 minutes -contributes considerably to thi s attack . Further, the proposed Version 5 of Kerberos anticipates alternative communication protocols in which suc h replays may be trivial to implement . If Kerberos is to be considered as a general-purpose utility, it mus t make few security-critical assumptions about the underlying network, and those must be explicit . It has been suggested that the proper defense is for the server to store all live authenticators ; thus, an attemp t to reuse one can be detected . tstelss] In fact, the original design of Kerberos required such caching, thoug h this was never implemented . (While that is a feature of the implementation rather than of the protocol itself, a security feature is not very useful if it is too hard to implement . ) For several reasons, we do not think that caching solves the problem . First, on UNrx systems it is difficult for TCP-based [POstst] servers to store authenticators . Servers generally operate by forking a separate proces s to handle each incoming request . The child processes do not share any memory with the parent process, an d thus have no convenient way to inform it -and hence any other child servers -of the value of th e authenticator used . There are a number of obvious solutions -pipes, authenticator servers, shared memor y segments and the like -but all are awkward, and some even raise authentication questions of their own . To date, we know of no multi-threaded server implementation which caches authenticators . UDP-based [P°s tSO] query servers can store the authenticators more easily, as a single process generall y handles all incoming requests ; however, they might have problems with legitimate retransmissions of th e client's request if the answer was lost . (UDP does not provide guaranteed delivery ; thus, all retransmission s happen from application level, and are visible to the application .) Legitimate requests could be rejected, an d a security alarm raised inappropriately . One possible solution would be for the application to generate a ne w authenticator when retransmitting a request ; were it not for the other weaknesses of the authenticator scheme , this would be acceptable . As noted, authenticators rely on machines' clocks being roughly synchronized . If a host can be misled abou t the correct time, a stale authenticator can be replayed without any trouble at all . Since some tim e synchronization protocols are unauthenticated, tpostSS, 1'4 E11' 8 ] and hosts are still using these protocols despit e the existence of better ones,[Mm89] such attacks are not difficult . The design philosophy of building an authentication service on top of a secure time service is itself questionable . That is, it may not make sense to build an authentication system assuming an alreadyauthenticated underlying system . Furthermore, while spoofing an unauthenticated time service may be a difficult programming task, it is not cryptographically difficult . Using time-based protocols in a secure -123-fashion means thinking through all these issues carefully and making the appropriate synchronization an explicit part of the protocol . As Kerberos is proposed for more varied environments, its dependence on a secure time service becomes more problematic and must be stressed . As an alternative, we propose the use of a challenge/response authentication mechanism . As is done today , the client would present a ticket, though without an authenticator. The server would respond with a nonc e identifier encrypted with the session key K c,s ; the client would respond with some function of that identifier , thereby proving that it possesses the session key . Such an implementation is not without its costs, of course . An extra pair of messages must be exchange d each time a ticket is used, which rules out the possibility of authenticated datagrams . More seriously, al l servers must then retain state to complete the authentication process . While not a problem for TCP-based servers, this may require substantial modification to UDP-based query servers . (The complexity of managin g outstanding challenges may be comparable to that needed to cache live authenticators--the trade-off is no t between a stateful and a stateless protocol, but in managing two kinds of state . ) There is a signficant philosophical difference between the two techniques, however . In the current Kerberos implementation, with its assumptions about the network environment, retained state is only necessary t o enhance security . The challenge/response scheme, on the other hand, guarantees security in a more genera l environment, but requires retained state to function at all . Instead of substituting challenge/response throughout, a possible compromise is to extend the protocol with a challenge/response option . This option could be used, for example, to authenticate the user in the initia l ticket-granting ticket exchange and to access a time service . 8 Subsequent client-server interactions could us e the current time-based protocol . But synchronizing the servers remains a problem ; not synchronizing the m will lead to denial of service, and if they access the time service as a client, they must somehow obtain an d store a ticket and key to authenticate it . (See above on storing keys in servers .) Given these complexitie s and possible weaknesses, it would seem reasonable to allow any service to insist on the challenge/respons e option . Summarizing, we emphasize that the security of Kerberos depends critically on synchronized clocks . I n essence, the Kerberos protocols involve mutual trust among four parties : the client, server, authenticatio n server and time server . .3 Password-Guessing Attacks
A breach of a system's authentication server will result in the exposure of all user accounts due to the centralization of authentication management REF .
Limitations of the Kerberos authentication system
CCRV
Computer Science