Limitations of the KerberosAuthentication System†Steven M. Bellovin – AT&T Bell LaboratoriesMichael Merritt – AT&T Bell LaboratoriesABSTRACTThe Kerberos authentication system, a part of MIT’s Project Athena, has beenadopted by other organizations. Despite Kerberos’s many strengths, it has a number oflimitations and some weaknesses. Some are due to specifics of the MIT environment;others represent deficiencies in the protocol design. We discuss a number of suchproblems, and present solutions to some of them. We also demonstrate how special-purpose cryptographic hardware may be needed in some cases.INTRODUCTIONThe Kerberos authentication system[Stei88, Mill87,Brya88] was introduced by MIT to meet the needs ofProject Athena. It has since been adopted by anumber of other organizations for their own pur-poses, and is being discussed as a possible standard.In our view, both these decisions may be premature.Kerberos has a number of limitations andweaknesses; a decision to adopt or reject it cannotproperly be made without considering these issues.(A limitation is a feature that is not as general as onemight like, while a weakness could be exploited byan attacker to defeat the authentication mechanism.)Some improvements can be made within the currentdesign. Support for optional mechanisms wouldextend Kerberos’s applicability to environments radi-cally different from MIT.These problems fall into several categories.Some stem from the Project Athena environment.Kerberos was designed for that environment; if thebasic assumptions differ, the authentication systemmay need to be changed as well. Other problems aresimply deficiencies in the protocol design. Some ofthese are corrected in the proposed Version 5 ofKerberos,[Kohl89] but not all. Even the solved prob-lems merit discussion, since the code for Version 4has been widely disseminated. Finally, some prob-lems with Kerberos are not solvable without employ-ing special-purpose hardware, no matter what thedesign of the protocol. We will consider each ofthese areas in turn.We wish to stress that we are not suggestingthat Kerberos is useless. Quite the contrary — anattacker capable of carrying out any of the attackslisted here could penetrate a typical network of UNIXsystems far more easily. Adding Kerberos to a net-work will, under virtually all circumstances,significantly increase its security; our criticisms focus†A version of this paper was published in the October,1990 issue of Computer Communications Review.on the extent to which security is improved. Further,we recommend changes to the protocols that substan-tially increase security.Beyond its specific utility in production, Ker-beros serves a major function by focusing interest onpractical solutions to the network authenticationproblem. The elegant protocol design and wide avai-lability of the code has galvanized a wide audience.Far from a condemnation, our critique is intended tocontribute to an understanding of Kerberos’s proper-ties and to influence its evolution into a tool ofgreater power and utility.Several of the problems we point out are men-tioned in the original Kerberos paper orelsewhere.[Davi90] For some of these, we present pro-tocol improvements that solve, or at least ameliorate,the problem; for others, we place them squarely inthe context of the intended Kerberos environment.Version 5, Draft 3Since this paper was written, a new draft of theVersion 5 protocol has been released, and a finalspecification is promised.[Kohl90] Many of the prob-lems we discuss herein have been corrected. Othersremain, and we have found a few new ones. Theultimate resolution of these issues is unclear as wego to press. Consequently, a brief analysis ofDraft 3 is presented in an appendix, rather than inthe main body of the document.Focus on SecurityKerberos is a security system; thus, though weaddress issues of functionality and efficiency, ourprimary emphasis is on the security of Kerberos in ageneral environment. This means that security-critical assumptions must be few in number andstated clearly. For the widest utility, the networkmust be considered as completely open. Specifically,the protocols should be secure even if the network isUSENIX – Winter ’91 – Dallas, TX 1Kerberos Limitations Bellovin & Merrittunder the complete control of an adversary.1Thismeans that defeating the protocol should require theadversary to invert the encryption algorithm or tosubvert a principal specifically assumed to betrustworthy. Only such a strong design goal can jus-tify the expense of encryption. (No ‘‘steel doors inpaper walls’’.) We believe that Kerberos can meetthis ambitious goal with only minor modifications,retaining its essential character.Some of our suggestions bear a performancepenalty; others complicate the design of suggestedenhancements. As more organizations make use ofKerberos, pressures to enhance or augment its func-tionality and efficiency will increase. Security hasreal costs, and the benefits are intangible. Theremust be a continuing and explicit emphasis on secu-rity as the overriding requirement.ValidationIt is not sufficient to design and implement asecurity system. Such systems, though apparentlyadequate when designed, may have serious flaws.Consequently, systems must be subjected to thestrongest scrutiny possible. A consequence of this isthat they must be designed and implemented in amanner that facilitates such scrutiny. Kerberos has anumber of problems in this area as well.WHAT’S A KERBEROS?Before discussing specific problem areas, it ishelpful to review Kerberos Version 4. Kerberos isan authentication system; it provides evidence of aprincipal’s identity. A principal is generally either auser or a particular service on some machine. Aprincipal consists of the three-tuple<primaryname, instance, realm >.If the principal is a user — a genuine person — theprimary name is the login identifier, and the instanceis either null or represents particular attributes of theuser, i.e., root. For a service, the service name isused as the primary name and the machine name isused as the instance, i.e., rlogin.myhost. Therealm is used to distinguish among different authen-tication domains; thus, there need not be one giant— and universally trusted — Kerberos databaseserving an entire company.1The Project Athena Technical Plan[Mill87, section 2]describes a simpler threat environment, where eavesdrop-ping and host impersonation are of primary concern.While
View Full Document
Unlocking...