[1002] in Kerberos
Why is initial user authentication done the way it is?
daemon@ATHENA.MIT.EDU (Clifford Neuman)
Thu Jun 14 20:52:30 1990
Date: Thu, 14 Jun 90 17:03:18 -0700
From: bcn@cs.washington.edu (Clifford Neuman)
To: jik@pit-manager.MIT.EDU
Cc: mdl@B.GP.CS.CMU.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: "Jonathan I. Kamens"'s message of Thu, 14 Jun 90 19:34:40 -0400 <9006142334.AA22508@PIT-MANAGER.MIT.EDU>
In my last message, I gave the general rationale behind our decisions
for V5. Unfortunately, I only included part of the reasoning behind
rejecting the pre-authentication scheme you described. Let me
elaborate here. Like everything else, tradeoffs are involved; two in
particular.
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).
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.
~ Cliff
