Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!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: <9006141950.AA01453@n1dmm.cs.washington.edu> Date: 14 Jun 90 19:50:15 GMT References: <9006141829.AA21208@PIT-MANAGER.MIT.EDU> Sender: daemon@shelby.Stanford.EDU Organization: The Internet Lines: 55 Date: Thu, 14 Jun 90 14:29:39 -0400 From: "Jonathan I. Kamens" 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