Path: utzoo!attcan!uunet!jarthur!elroy.jpl.nasa.gov!ames!eos!shelby!ATHENA.MIT.EDU!tytso
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Newsgroups: comp.protocols.kerberos
Subject: Re: Why is initial user authentication done the way it is?
Message-ID: <9006151937.AA06034@BINKLEY.MIT.EDU>
Date: 15 Jun 90 19:37:28 GMT
References: <1990Jun15.170137.5454@terminator.cc.umich.edu>
Sender: daemon@shelby.Stanford.EDU
Reply-To: tytso@ATHENA.MIT.EDU
Organization: The Internet
Lines: 43


   >Sure there is.  All I have to do is get a valid TGT, and then ask the
   >KDC for a ticket to jik@ATHENA.MIT.EDU.  The response will include a
   >"ticket to jik", which will contain my name (and other things)
   >encrypted in your key.  I can then bang on the ticket all I want in
   >the privacy of my own CPU.

   This is interesting, but really not as bad as the problem Jon and I
   talked about. The above *does* require a valid TGT, first. Biff, of
   course, doesn't have a valid TGT. Unfortuately he doesn't need one,
   either.

Getting a valid TGT is pretty trivial.  Athena's Kerberos setup has
several guest/test principals whose passwords are eminently guessable.
In addition, anybody who has a principal (or who can crack a guest/test
principal) in a Kerberos realm who has exchanged keys with the target's 
Kerberos server can also get a cross-realm TGT.  As you can see, it
*isn't* hard to get a TGT, and so it *won't* be hard to request a ticket
for jik@ATHENA.MIT.EDU.

So for this reason, I don't think there's any point in complicating the
protocol with a pre-authentication step for an initial
ticket-granting-ticket, as long as there's another similar "hole" which
cannot be closed without doing major revisions to the entire Kerberos
concept.

In addition, I think people are going a bit rabid screaming "dictionary
attack".  Granted, you can pre-compute the string_to_key() to obtain a
"dictionary", and this process does involve a DES encryption step, so it
would save a bit of time.  But you still have to use the resultant key
to attempt a DES decryption for every single key in your "dictionary" on
the sealed TGT which you got from the server, and this decryption can
not be done in parallel for many different users.  (This is assuming
that the confounders in V5 Kerberos prevent the optimization which Ted
Anderson pointed out.)  And as Steve Bellovin has asserted, the speed
difference involved between the DES decyption and something like
fcrypt() are probably very close to each other.

						- Ted

P.S.  I've always wondered what would happen if someone were to create a
DES chip with the modified E-boxes (and optimized it for Unix password
cracking) in an VLSI design course...  :-)