[993] in Kerberos
Re: Why is initial user authentication done the way it is?
daemon@ATHENA.MIT.EDU (Steve Lunt)
Thu Jun 14 15:24:31 1990
Date: Thu, 14 Jun 90 11:40:38 -0400
From: Steve Lunt <lunt@ctt.bellcore.com>
To: athena.mit.edu!kerberos@bellcore.bellcore.com
In this case, the workstation is still vulnerable to someone spoofing the authentication server. That is, the workstation has no way of knowing if it is talking to the real Kerberos. The real Kerberos could be down, and the user could simply send an appropriate reply to the workstation's TGT request as if it were coming from Kerberos. You have this vulnerability with the current Kerberos TGT
request protocol if you configure your login program to use the reply from Kerberos rather than the password in /etc/passwd for authentication. The workstation needs some way of knowing that it is talking to the real Kerberos. It could use it's secret (in /etc/srvtab) for this purpose (requiring a change in the TGT request protocol.
-- Steve
Steven J. Lunt | lunt@ctt.bellcore.com | RRC 1L-213
Computer Security Technology |-------------------------| 444 Hoes Lane
Bellcore | (201) 699-4244 | Piscataway, NJ 08854
----- Begin Included Message -----
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
Subject: Why is initial user authentication done the way it is?
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
----- End Included Message -----
