Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!hao!gatech!bloom-beacon!athena.mit.edu!wesommer
From: wesommer@athena.mit.edu (William Sommerfeld)
Newsgroups: sci.crypt
Subject: Re: Unix Password Hacker
Message-ID: <3245@bloom-beacon.MIT.EDU>
Date: 27 Feb 88 01:19:27 GMT
References: <731@ddsw1.UUCP> <657@morningdew.BBN.COM> <1368@homxc.UUCP> <739@ddsw1.UUCP> <1118@uop.edu> <2584@crash.cts.com> <3234@bloom-beacon.MIT.EDU> <2085@polya.STANFORD.EDU>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: wesommer@athena.mit.edu (William Sommerfeld)
Distribution: na
Organization: Massachusetts Institute of Technology
Lines: 45

Jon Kamens' description of how Kerberos works was incorrect; I would
bet that he hasn't read the paper...  If you want an accurate,
detailed description, see the Kerberos paper in the Winter '88 USENIX
proceedings.

In normal use (not counting password changes) the user's password
never leaves the workstation, whether in the clear or encrypted.  It
only exists in the memory of the workstation for a few seconds; it is
used only to get a `ticket granting ticket' with a different session
key which expires after eight hours.

In article <2085@polya.STANFORD.EDU> haddad@polya.UUCP (Ramsey Haddad) writes:
>Whether passwords are sent over the network in plaintext or encrypted
>text is irrelevant.  ...
>To get around this problem one needs to use public-key cryptography
>and an interactive login protocol.

You _DON'T_ need public key cryptography if you can trust a key
distribution center to share a secret with you, and share a different
secret with entities you want to communicate with.

It also doesn't need to be `interactive' if you are only concerned
with authenticating in one direction (that is, authenticating the
client to the server, but not the reverse).  Kerberos does support
mutual authentication, but applications to date have typically not
used it.

You can protect against replays by using a (loosely) synchronized
clock and including timestamp information in the authentication
information.  The clock synchronization information prevents long-term
replays, since the authenticator built by the client expires after
five minutes.

The server could easily remember the last timestamp from each client
and only allow new timestamps which come after the previous one;
however, we haven't implemented this (yet).  Assuming that system
reboot time is on the order of ~10 minutes (and that the attacker
hasn't subverted the time synchonization protocol), this means that
the server doesn't need to preserve state across a crash.

Incidentally, the Sun `secured' NFS uses the latter technique combined
with a public key method to distribute (DES) session keys; some people
from Sun seem interested in replacing their public key approach with
Kerberos, which does the same thing and is more secure.

				- Bill