Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!usc!apple!bionet!agate!shelby!PIT-MANAGER.MIT.EDU!jik
From: jik@PIT-MANAGER.MIT.EDU ("Jonathan I. Kamens")
Newsgroups: comp.protocols.kerberos
Subject: Why is initial user authentication done the way it is?
Message-ID: <9006141829.AA21208@PIT-MANAGER.MIT.EDU>
Date: 14 Jun 90 18:29:39 GMT
References: <9006141634.AA20691@PIT-MANAGER.MIT.EDU>
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 37


   From: Mark Lillibridge <mdl@B.GP.CS.CMU.EDU>
   Date: Thu, 14 Jun 90 11:06:42 EDT

	   The short answer: Because this scenario is also vulnerable to a
   dictionary attack.  Suppose I wanted to break your password under the
   new scheme.  I just wait until you log in, recording your data request
   in part 1.  I now pretend to be Kerberos, and try and decrypt your
   initial request with each possible key until I succeed.  Once I have a
   key that successfully decodes your request, I have found your key.

  This assumes that you have the ability to monitor transactions going
over the network.  The way things stands now, you do not need to be
able to do this in order to get an encrypted packet to hack on,
whereas in the proposed system I described, you do; therefore, my
system provides at least some level of increased security.

  Incidentally, it seems to me that the way the Kerberos protocol is
currently written, Kerberos is even *more* vulnerable to dictionary
attack than is /etc/passwd encryption.

  This is because there are no seeds involved, so it's possible to
build up a large database of encrypted keys, because the decryption is
faster than crypt() (or at least I think it is; I'm not really sure
about this one, so someone correct me if I'm wrong), and because it's
possible to request an encrypted tgt for anyone in any realm, thus
eliminating the security (albeit slight) of passwd files not being
available for cracking on.

  Given all this, it would seem to me that the issue of making the
protocol more secure should have been a high priority in the Kerberos
V5 design.  Is there a particular reason why it wasn't?

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710