Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mcnc!xanth!ames!ptolemy!eos!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: <9006140436.AA17824@PIT-MANAGER.MIT.EDU>
Date: 14 Jun 90 04:36:47 GMT
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 76


  While at Usenix, I had a discussion with someone about the way
Kerberos does its initial user authentication, and the discussion
raised some questions of which I am not sure the answers, so I'd like
to ask the people who know more about Kerberos than I do what the
story is.

  As I understand things now, here's what happens when a user wants to
authenticate himself to Kerberos (please correct me if I'm wrong):

1. A tgt request is sent to the Kerberos server.

2. The server sends back a tgt, including a session key, encrypted in
   the user's key.

3. The user's key (which is usually obtained by prompting for a
   password and then running it through string_to_key, is used to
   decrypt the encrypted tgt.

4. If the decryption succeeds, then the user has a tgt which he can
   use to request future services from Kerberos.

  The person with whom I spoke at Usenix raised the concern that the
scheme above is vulnerable to the following attack:

1. A tgt request for a person whom a malicious individual wants to
   nail is sent to the Kerberos server by the malicious individual.

2. The server sends back a tgt, including a session key, encrypted in
   the user's key.

3. The malicious individual has already prepared a database by running
   string-to-key over all of the words in /usr/dict/words, and over
   some other common passwords, or some such thing.

4. Decryption attempts are made with each of the trial passwords,
   until one succeeds.  At this point, the malicious individual has
   the password of the person he's trying to nail.

  The first question is, is this a reasonable scenario?

  If so, then the second question is, why wasn't the original user
authentication transaction implemented like this?

1. The user creates some request structure with the appropriate data
   in it, and encrypts that structure in his key.  Then, the structure
   (along with a plaintext header to tell the server what principle
   the request is for) is sent to the server.

2. The server performs a decryption on the structure using the user's
   key, and if it succeeds, then the server knows that it really is
   talking to the user.

3. The server sends back a tgt encrypted in the user's key.

4. The user decrypts the tgt with his key.

  The advantage of this scenario is that the user only gets something
encrypted in his key if he has already proven himself to be who he is
claiming to be.  Therefore, a malicious invididual can't get his hands
on an encrypted piece of text to bang on until he figures out its key.

  Furthermore, if the malicious individual makes repeated attempts to
prove that he is the user he's trying to nail, this can be detected on
the server.

  One disadvantage of this scenario is that there is an extra
encryption envolved.  Are there any other disadvantages I'm not
seeing?  If not, why weren't things implemented this way?

  Thanks.

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