[1001] in Kerberos
Why is initial user authentication done the way it is?
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Thu Jun 14 20:25:15 1990
Date: Thu, 14 Jun 90 19:34:40 -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 12:50:15 -0700 <9006141950.AA01453@n1dmm.cs.washington.edu>
Date: Thu, 14 Jun 90 12:50:15 -0700
From: bcn@cs.washington.edu (Clifford Neuman)
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.
"Keeping the protocol secure" is the wrong terminology. The problem
I described in my original message is present in Version 4.
Therefore, it's not a question of keeping the protocol secure, it's a
question of making the protocol more secure in Version 5 than it was
in Version 4.
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.
I am aware that verifiable plaintext in the encrypted messages sent
over the network poses a problem that is not easily solveable.
However, I have always found the claim, "We can't fix everything, so
we aren't going to be fix anything," to be remarkably bogus.
The modification to the protocol which I proposed in my original
message makes it impossible for someone to get an encrypted tgt to
work on unless they are eavesdropping on the network. As someone has
already pointed out, this makes a large portion of dictionary attacks
impossible. Furthermore, the code to implement the change I proposed
(or a similar one) is negligible, and can be plugged into the library
and server code without modifying any application code. Why, then,
was not such a change considered?
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.
I have not proposed that all verifiable plaintext be removed from
the protocol. The proposal I've made is much simpler than that, and
yet even though it's simple, it makes a dictionary attack on the
Kerberos server much more difficult. I ask again, why do so many
people appear to be rejecting this change, or the possibility of one
like it to make the protocol more secure, out-of-hand?
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).
Even with the confounder, it's still easier to use a dictionary
attack on a Kerberos server than it is to do so on an /etc/passwd
file. Adding pre-authentication would make it no easier to do the
fomrmer than to do the latter, and possibly make it harder to do the
former.
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.
I really think you've underestimated the effect of adding
pre-authentication. Fine, you can assume that in at least some cases,
the network is insecure. Let me ask you this question, however:
let's say someone in California wants to break into my Athena account.
Under the current protocol, they don't have to be able to monitor the
Athena subnet (and, indeed, they probably can't) -- all they have to
do is ask kerberos.mit.edu for an encrypted tgt for me, and bang on it
in California. If you add pre-authentication, then they can't get
that encrypted tgt, and since they can't monitor the Athena subnet,
they can't get it that way either.
It's a big step to conclude from "This change won't fix all of our
problems" that "This change won't do any significant amount of good."
I agree with the former, but I most certainly do not agree with the
latter.
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.
I see many people on this list saying, "This is not a relevant
danger because people should choose good passwords." The problem is
that PEOPLE DON'T CHOOSE GOOD PASSWORDS. The people on this mailing
list/in this newsgroup (well, at least some of them) are supposed to
be experts in the field of authentication. I'm not, and yet it seems
obvious to me that authentication systems shoulde be written in a way
that attempts to behave reasonably EVEN IN THE FACE OF USER STUPIDITY.
Using "people should choose good passwords" as an excuse for why we
don't have to improve the Kerberos security is just that, an excuse.
jik
