Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!mcnc!gatech!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: sci.crypt
Subject: Re: Unix Password Hacker
Message-ID: <3319@bloom-beacon.MIT.EDU>
Date: 28 Feb 88 16:39:44 GMT
References: <731@ddsw1.UUCP> <657@morningdew.BBN.COM> <1368@homxc.UUCP> <3234@bloom-beacon.MIT.EDU> <1043@athos.rutgers.edu>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Distribution: na
Organization: Massachusetts Institute of Technology
Lines: 77

In article <1043@athos.rutgers.edu> webber@athos.rutgers.edu (Bob
Webber) writes:

>In article <3234@bloom-beacon.MIT.EDU>, jik@athena.mit.edu (Jonathan
>I. Kamens) writes:

>> [my initial, partially incorrect explanation of kerberos]

>Hmmm.  Clearly this isn't the whole story.  Sending the encrypted
>password down the pipe to be read and matched against an entry doesn't
>of itself add anything to security since anyone can duplicate a
>transmission of an encrypted password as easily as a raw password.  In
>order to get security, besides encryption, you need some kind of
>handshaking protocol that allows the permission-granter to ascertain
>that the sender really knows the unencrypted password and is not just
>duplicating an intercepted encrypted transmission.  Note that if you
>can monitor a users encrypted traffic, given the stereotyped nature of
>computer traffic, many attacks are possible.

You are totally correct, and my first explanation of kerberos' initial
authentication was incorrect.

Allow me to quote without permission from "Kerberos: An Authentication
Service for Open Network Systems," a paper by Jennifer G. Steiner,
Clifford Neuman and Jeffrey I. Schiller which was presented at the
1988 Usenix Conference held recently in Dallas, Texas.  They say it
much better than I could.

     Getting the Initial Ticket
       When the user walks up to a workstation, only one piece of
     information can prove her/his identity: the user's password.  The
     initial exchange with the authentication server is designed to
     minimize the chance that the password will be compromised, while
     at the same time not allowing a user to properly authenticate
     her/himself without knowledge of that password.  The process of
     logging in appears to the user to be the same as logging in to a
     timesharing system.  Behind the scenes, though, it is quite
     different.
       The user is prompted for her/his username.  Once it has been
     entered, a request is sent to the authentication server
     containing the user's name and the name of a special service
     known as the ticket-granting service.
       The authentication server checks that it knows about the
     client.  If so, it generates a random session key which will
     later be used between the client and the ticket-granting server.
     It then creates a ticket for the ticket-granting server which
     contains the client's name, the name of the ticket-granting
     server, the current time, a lifetime for the ticket, the client's
     IP address, and the random session key just created.  This is all
     encrypted in a key known only to the ticket-granting server and
     the authentication server.
       The authentication server then sends the ticket, along with a
     copy of the random session key and some additional information,
     back to the client.  This response is encrypted in the client's
     private key, known only to kerberos and the client, which is
     derived from the user's password.
       Once the response has been received by the client, the user is
     asked for her/his password.  The password is converted to a DES
     key and used to decrypt the response from the authentication
     server.  The ticket and the session key, along with some of the
     other information, are stored for future use, and the user's
     password and DES key are erased from memory.
       Once the exchange has been completed, the workstation possesses
     information that it can use to prove the identity of its user for
     the lifetime of the ticket-granting ticket.  As long as the
     software on the workstation had not been previously tampered
     with, no information exists that will allow someone else to
     impersonate the user beyond the life of the ticket.

I hope this clarifies things.  It is a little bit confusing, I admit.
My error was in stating that the user's password travels over the
network in DES-encrypted form.  In fact, the password never travels
over the net in any form at all.

 -=> Jonathan I. Kamens | "There is no expedient to which man will not go
     MIT '91            |  to avoid the real labor of thought."
     jik@ATHENA.MIT.EDU |                          -- Thomas Alva Edison