Path: utzoo!attcan!uunet!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!uwm.edu!lll-winken!ames!eos!shelby!PIT-MANAGER.MIT.EDU!jik From: jik@PIT-MANAGER.MIT.EDU ("Jonathan I. Kamens") Newsgroups: comp.protocols.kerberos Subject: Why is initial user authentication done the way it is? Message-ID: <9006142334.AA22508@PIT-MANAGER.MIT.EDU> Date: 14 Jun 90 23:34:40 GMT References: <9006141950.AA01453@n1dmm.cs.washington.edu> Sender: daemon@shelby.Stanford.EDU Organization: The Internet Lines: 106 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