Re: draft-ietf-ipsec-ikev2-06.txt

[Hugo Krawczyk <hugo@ee.technion.ac.il>]

On Wed, 9 Apr 2003, Paul Hoffman / VPNC wrote:

> At 10:46 AM -0400 4/8/03, David Jablon wrote:
> >I too prefer "MUST", and I prefer "MUST NOT" in the addition.
> 
> Could you explain the technical reason for that? If someone uses a 
> password instead of a sufficiently-random shared secret, will the PRF 
> break?
> 
> We have no way of testing if someone has used a password vs. a shared 
> secret. If we say MUST and MUST NOT, we are saying that 
> implementations must somehow test for this. SHOULD and SHOULD NOT 
> (with the appropriate wording about the problems of passwords) seems 
> more realistic, but if there truly is a technical problem with using 
> a password in a PRF as Hugo has described, then we should know about 
> it.

Let's answer this serious question with the following real life dialogue.

Doctor: I have some bad news and some very bad news.
Patient: Well, might as well give me the bad news first.
Doctor: The lab called with your test results. They said you have 24 hours
to live.
Patient: 24 HOURS! That's terrible!! WHAT could be WORSE? What's the very
bad news? 
Doctor: I've been trying to reach you since yesterday. 

In our case the bad news is that the prf's strength is now at most as the
entropy of the password (typically < 32 bits).  The weakness here is
obvious: brute force attacks in 2^32 operations.

The worse news is that some prf's may interact particularly bad with short
keys. Think, for example, of an application using 3keys-3DES as the prf
and a specification (as suggested in this list) to pad with 0s to the
whole key length.  If the key is given as an 8-character password then
this is at best (even if the password is totally random) equivalent to
single DES, against which you can use a "conventional" single-DES cracker.

The worst news is that the exchange is open to off-line dictionary attacks
no matter how you derive the key from the password (as long as this
derivation does not use additional secret keys). In particular, this is
the case when you use HMAC with a password.

Hugo


> 
> --Paul Hoffman, Director
> --VPN Consortium
>