[1935] in Kerberos
Re: kerberos & novell
daemon@ATHENA.MIT.EDU (smb@ulysses.att.com)
Wed May 27 12:05:44 1992
From: smb@ulysses.att.com
To: keith@novell.com (Keith Brown)
Cc: tytso@Athena.MIT.EDU (Theodore Ts'o), kerberos@Athena.MIT.EDU
Date: Wed, 27 May 92 11:40:47 EDT
Ted is absolutely correct in his comments. At the risk of immodesty,
let me quote what Michael Merritt and I wrote in our critique of
Kerberos (Usenix, Jan '91, also available as dist/kerblimit.usenix.ps
on research.att.com):
Is Kerberos correct? By that we are asking if there are bugs
(or trapdoors!) in the design or implementation of Kerberos,
bugs that could be used to penetrate a system that relies on
Kerberos. Some would say that by making the code widely
available, the implementors have enabled would-be penetrators
to gain a detailed knowledge of the system, thereby simplifying
their task considerably. We reject that notion.
.....
Kerberos is designed primarily as an authentication system
incorporating a traditional cryptosystem (the Data Encryption
Standard) as a component. Never the less, the philosophy
guiding Kerckhoffs' evaluation criterion applies to the
evaluation of the security of Kerberos. The details of
Kerberos's design and implementation must be assumed known to a
prospective attacker, who may also be in league with some
subset of servers, clients, and (in the case of
hierarchically-configured realms) some authentication servers.
Kerberos is secure if and only if it can protect other clients
and servers, beginning only with the premise that these client
and server keys are secret, and that the encryption system is
secure. Moreover, in the absence of a central, trusted
``validation authority'', each prospective user of Kerberos is
responsible for judging its security. Of course, a public
discussion of system security and publication of security
evaluations will facilitate such judgements.
By describing the Kerberos design in publications and making
the source code publically available, the Kerberos designers
and implementors at Project Athena have made a commendable
effort to encourage just such a public system validation.
Obviously, this document is itself part of that process.
However, the system design and its implementation have
undergone significant modification, in part as a consequence of
this public discussion. We stress that each modification to
the design and implementation results in a new system whose
security properties must be considered anew. (Examples of such
modifications are the incorporation of hierarchically-organized
servers and forwardable tickets in Version 5.)
Kerberos has been exposed to several years of public scrutiny. The
Novell scheme has not. Even though its basis (public key cryptography)
gives it a considerable edge, there are still innumerable ways to
commit subtle errors in the implementation. Of course, I have no
reason to think there are such security holes -- but I also have no
reason to think that there aren't.
--Steve Bellovin
