[1003] in Kerberos
Why is initial user authentication done the way it is?
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Thu Jun 14 21:23:25 1990
Date: Thu, 14 Jun 90 20:32:02 -0400
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
To: bcn@cs.washington.edu
Cc: mdl@B.GP.CS.CMU.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Clifford Neuman's message of Thu, 14 Jun 90 17:03:18 -0700 <9006150003.AA01762@n1dmm.cs.washington.edu>
Date: Thu, 14 Jun 90 17:03:18 -0700
From: bcn@cs.washington.edu (Clifford Neuman)
One of our concerns in the initial design of Kerberos (V1) was that
the password be vulnerable for as short a period as possible. As a
result, we did not prompt for a password until a response had been
received from the KDC. To perform pre-authentication, we would have
to prompt for the password before the request was made, and store it
until the response was received (if at all). I will admit that the
increase in exposure is practically negligible, but it must be
compared with the gain in security due to pre-authentication, which I
also feel is pretty small (though perhaps not negligible).
Apparently, we disagree on the relative dangers of someone grabbing
a password froom a program doing authentication, and someone grabbing
a tgt from the server. Frankly, I don't think it's possible to
justify the trade-off you describe in the paragraph above.
In order to grab a password out of a process, you've got to get a
memory dump of some sort of that process during the very short window
of time during which the procedss has the password stored. This means
that you have to be aware of exactly when that window occurs, that you
have to have a way of grabbing a memory image instantly when the
window happens, and that you have to have access to the machine in
question in order to grab the memory image. Oh, yes, you also usually
have to have root access since a properly configured machine won't
allow non-root users to get access to the memory images of processes
run by other users.
On the other hand, all I have to do in order to grab someone's tgt
and hack on it is to ask the server for it.
Do you really believe that it's more likely that someone is going to
steal a password in the second or so more it is stored, if we do
preauthentication, than it is that someone is going to be able to
figure out someone's password from a tgt they've requests from the
server? Sorry, but I don't believe it.
I hope the people I talked to at Usenix post the source code to
their program which hacks on tgt's, just to show how easy it is to get
a password from a tgt.
More importantly, Kerberos does not distinguish between types of
principals. A principal can play the role of either a client or a
server. The distinction is not made in the Kerberos database. We
felt that doing so would make the Kerberos model less clear. If
clients and servers are equivalent your argument about an attacker in
California being unable to obtain ciphertext to work on would no
longer hold. The attacker could request a set of credentials with the
target of his attack listed as the server. He could then apply the
brute force attack to decrypt the ticket.
It is extremely, extremely likely that the Kerberos server itself
is going to have a very good password. The pre-authentication scheme
I've described, as I have already said several times, is not meant to
prevent every possible attack against the kerberos server. It is
meant to prevent EASY attacks on the kerberos server.
As you have already pointed out, deciding on how to do
authentication is a matter of making various trade-offs. None of the
trade-offs provide COMPLETE security, so you've got to choose which
ones give you the best security for the least amount of effort.
The preauthentcation scheme I've described, in my opinion, gives you
a much higher level of security (For heaven's sake, breaking into
Kerberos now is easier than breaking into any Unix box! Does that
mean so little to you? Are you so eager to take a step backward in
Unix security when you push Kerberos? I'm bewildered by that, really
bewildered.), for an extremely low cost (the only disadvantage you've
mentioned that is even worth considering is the extra time the key
stays in memory, and I would argue that it isn't worth considering
that either).
Jonathan Kamens USnail:
MIT Project Athena 11 Ashford Terrace
jik@Athena.MIT.EDU Allston, MA 02134
Office: 617-253-8495 Home: 617-782-0710
