Path: utzoo!attcan!uunet!lll-winken!uwm.edu!bionet!agate!shelby!CS.WASHINGTON.EDU!bcn
From: bcn@CS.WASHINGTON.EDU (Clifford Neuman)
Newsgroups: comp.protocols.kerberos
Subject: Why is initial user authentication done the way it is?
Message-ID: <9006150003.AA01762@n1dmm.cs.washington.edu>
Date: 15 Jun 90 00:03:18 GMT
References: <9006142334.AA22508@PIT-MANAGER.MIT.EDU>
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 27

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