[997] in Kerberos
Why is initial user authentication done the way it is?
daemon@ATHENA.MIT.EDU (Clifford Neuman)
Thu Jun 14 17:11:17 1990
Date: Thu, 14 Jun 90 12:50:15 -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 14:29:39 -0400 <9006141829.AA21208@PIT-MANAGER.MIT.EDU>
Date: Thu, 14 Jun 90 14:29:39 -0400
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
Subject: Why is initial user authentication done the way it is?
Given all this, it would seem to me that the issue of making the
protocol more secure should have been a high priority in the Kerberos
V5 design. Is there a particular reason why it wasn't?
Keeping the protocol secure WAS a high priority in the design of
Kerberos V5. Here's what is done in V5, and the rationale behind it.
Dictionary and brute force attacks were considered. There is only one
way we know of to avoid brute force attacks, and that is to eliminate
verifiable plaintext as described in "Reducing Risks from Poorly
Chosen Keys" cited earlier. We felt that this was a good approach,
but it had to be the basis of design for a protocol, not added on
later.
The design of a production authentication system such as Kerberos
involves many tradeoffs. While a protocol without verifiable
plaintext has advantages, those advantages don't come without cost.
The overall structure of the protocol would be changed (not just
extended), the simple nature of the Kerberos protocol would be lost,
and additional state would have to be maintained by all parties. Much
of what would be lost are those features we considered important for
the environment in which Kerberos was to operate.
Even if we did adopt such a protocol, I do not believe that the result
could properly be considered a new "version" of the original protocol.
Although we decided not to pursue a non-verifiable plaintext approach,
we did learn from the paper. In particular, we have added a confounder
to the front of all encrypted data. The confounder serves a purpose
similar to the salt in Unix passwords and eliminates pre-computed
dictionary attacks. It does not, however, prevent real-time, brute
force attacks (which may use a dictionary for its guesses).
We also considered adopting some form of pre-authentication before
credentials were returned by the KDC as a way to reduce the likelihood
of brute force attacks. We decided that there was not a significant
increase in security from such an approach. As has already been
pointed out, an attacker would still be able to obtain ciphertext to
work on by listening for a request from (or response to) the targeted
client(s). We made minimal assumptions about the security of the
underlying network. Without a secure underlying network, a determined
attacker would have little difficulty obtaining ciphertext to work on.
Our conclusion: without eliminating verifiable plaintext, the only
real countermeasure to a brute force attack is a well chosen password.
Passwords in Kerberos can be of any length. The longer the password,
or the more randomly chosen, the greater the portion of the 56 bit (DES)
keyspace that is used.
~ Cliff
