[991] in Kerberos
Why is initial user authentication done the way it is?
daemon@ATHENA.MIT.EDU (Mark Lillibridge)
Thu Jun 14 13:38:25 1990
From: Mark Lillibridge <mdl@B.GP.CS.CMU.EDU>
Date: Thu, 14 Jun 90 11:06:42 EDT
To: jik@pit-manager.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: "Jonathan I. Kamens"'s message of Thu, 14 Jun 90 00:36:47 -0400 <9006140436.AA17824@PIT-MANAGER.MIT.EDU>
> Date: Thu, 14 Jun 90 00:36:47 -0400
> From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
>
> [description of how a user initially authenticates himself to Kerberos]
>
> [description of how the above is vulnerable to a dictionary attack]
>
> The first question is, is this a reasonable scenario?
Yes, although I believe the scenario given is slightly
incorrect. I haven't checked but I believe you can not just look at the
decrypted ticket-session key pair and tell that it is a valid pair.
This can be gotten around though with slightly more cleverness.
(Hint: tickets are normally sent in the clear...)
> 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 person 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 involved. Are there any other disadvantages I'm not
> seeing? If not, why weren't things implemented this way?
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.
I have argued previously on the kerberos-protocol list that the
only way to prevent a dictionary attack from being used against Kerberos
is to add either randomness or a one-way function to the protocol. For
an example of the later, see "Reducing Risks from Poorly Chosen Keys".
A reference to which is given in a recent message to this list.
- Mark Lillibridge
