Date: Tue, 19 May 1992 19:52:48 GMT
From: gp15@cunixf.cc.columbia.edu (Gerald Pulver)
Reply-To: Gerald Pulver <gp15@columbia.edu>
To: kerberos@shelby.Stanford.EDU

Have you had any experience (or heard any rumors) of kerberos being used
on novell networks?  I'd like to know what has already been done. (pointers:
both direct & indirect, would be appreciated.)  Thanks.

Date: 27 May 92 00:15:40 GMT
From: keith@novell.com (Keith Brown)
To: kerberos@shelby.Stanford.EDU

In article < 1992May19.195248.19623@cunixf.cc.columbia.edu> Gerald Pulver 
<gp15@columbia.edu> writes:
>Have you had any experience (or heard any rumors) of kerberos being used
>on novell networks?  I'd like to know what has already been done. (pointers:
>both direct & indirect, would be appreciated.)  Thanks.

NetWare has been walking down the RSA trail in terms of authentication
services. Use of Kerberos has not been entirely eliminated but RSA
looks far more commercially viable today. Distribution and implementation
of RSA technology is carefully controlled and limited (it must be licensed
from the one source). As a consequence, there is a defacto standard RSA and
implementations can be trusted.

Kerberos suffers from the fact that its source is widely available and
abusable by any Joe on the internet whose figured out how to use FTP.
Being such a Joe, I could FTP it over from MIT now, change a few lines
of code, insert a back door or two and unleash my kludgery upon an
unsuspecting planet. Is this what you would wish your bank to be using?

Keith
-
Keith Brown                                      Phone: (408) 473 8308
Novell San Jose Development Centre               Fax:   (408) 433 0775
2180 Fortune Dr, San Jose, California 95131      Net:   keith@novell.COM

Date: Wed, 27 May 92 11:15:59 -0400
From: tytso@Athena.MIT.EDU (Theodore Ts'o)
To: kerberos@Athena.MIT.EDU
In-Reply-To: Keith Brown's message of 27 May 92 00:15:40 GMT,

   Date: 27 May 92 00:15:40 GMT
   From: keith@novell.com (Keith Brown)

   NetWare has been walking down the RSA trail in terms of authentication
   services. Use of Kerberos has not been entirely eliminated but RSA
   looks far more commercially viable today. Distribution and implementation
   of RSA technology is carefully controlled and limited (it must be licensed
   from the one source). As a consequence, there is a defacto standard RSA and
   implementations can be trusted.

   Kerberos suffers from the fact that its source is widely available and
   abusable by any Joe on the internet whose figured out how to use FTP.
   Being such a Joe, I could FTP it over from MIT now, change a few lines
   of code, insert a back door or two and unleash my kludgery upon an
   unsuspecting planet. Is this what you would wish your bank to be
   using?

	How so?  Any random Joe on the internet can grab Kerberos, but
it certainly isn't the case that they would be able to unleash it on an
unsuspecting planet.  How would they do that?  If someone wants
Kerberos, they can get it from MIT, or some other trusted party --- for
example, there are a number of places that will sell you a Kerberos tape
and support to go with it.  They're not going to get it from your random
Joe on the internet.  The issue you raise is a complete red herring!

	When Novell (or any other computer vendor) puts together a
system using RSA, or Kerberos, that vendor will always be able to
install back doors into the system, and "unleash it unto an unsuspecting
planet".  Whether or not source is widely available is irrelevent.

	Furthermore, RSA is just an encryption algorithm.  Kerberos is a
complete authentication package (which uses DES) and which has stood the
test of time.  If you just get RSA from RSA DSI, it is up to you to take
that encryption and turn it into a viable authentication scheme.  That
scheme may not be compatible with the rest of the world; true, there are
standards for the format of certificates and encrypted objects, but
there's more to an authentication system than that --- for example, what
sort of packet format and what sort of exchange sequence do you use?

	So Novell is going to have to put together an authentication
system using RSA, and then the rest of the world (who won't be given
access to the source code), will have to hope that (1) Novell designed
it correctly, and (2) the green implementation which they did doesn't
have any bugs.

	If I were a bank security officer, I would much rather have a
system where (1) the system has stood the test of time and (2) the
sources are available so that an independent third party could audit
them.  I fail to see how having freely available source code could ever
be a disadvantage.  Security through obscurity is no security whatsoever
--- and I'm speaking as someone who has disassembled quite a few of
programs in my time, including the Internet worm/virus, and a couple of
copy protection schemes.  :-)

						- Ted

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