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

[David Jablon <dpj@theworld.com>]

Paul,

I don't really want to debate the point of whether the text should *allow* for
the use of weakened Shared Secret keys.  But it seems like the implications
need to be more clearly stated, and whether an implementation must allow
for full-strength keys is not addressed in the SHOULD version.

Here's the proposed text in question:

2(b)+:
        "When pre-sharing a key for use in prf-based authentication 
        (i.e., Shared Secret") this key {SHOULD | MUST} be of the length
        of the key for the prf agreed for use by the parties, and this key
        {SHOULD NOT | MUST NOT} be derived solely from a password
        or other data that has less randomness than a truly random key
        of the appropriate length."

At 09:47 AM 4/9/03 -0700, 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?

I think that's the wrong question, or at least I don't understand
how insufficiently random input can "break" a PRF.

But your first question forces me to elaborate my concern over the
SHOULD version.  Using "SHOULD", the security of an implementation
may certainly be broken.  And any relevant security proofs or arguments
that assume that keys are random will certainly not apply.

The text in draft 06 states that human-chosen password-derived
keys are insecure in this context but it doesn't fully explain why.
(See proposed change below.)
Naively replacing key bytes with password bytes results in a
skewed distribution. Depending on how the password is chosen,
an N-byte password may have as little as 10% to 20% of the
randomness of an N-byte key.  Just having the high bit of each
ASCII password byte set to zero guarantees at least a 12.5% loss.

A good technical reason for saying MUST instead of SHOULD in 2(b)+
is that SHOULD permits implementations that restrict ALL keys to
insecure length and/or insufficient randomness.

>We have no way of testing if someone has used a password vs. a shared secret. ...

Now that you mention it, there are surely some easy ways to detect
common causes for insufficient randomness.  But I wasn't proposing
such a requirement.

>... If we say MUST and MUST NOT, we are saying that implementations must somehow test for this. ...

No.  I don't think so.  At least I didn't intend to.
It does (and should) say something about the design of the mechanism
for shared secret key entry, and for shared key selection (if any) ---
namely that they should not force or encourage the use of weakened keys.

>... 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.

If we didn't know how passwords are different than keys,
and how our security assumptions require truly random keys,
then we should now.

A little more wordsmithing would seem to be needed to fix the
technical problem with the SHOULD version of 2(b)+.
Even if weak keys are supported, it seems good to at least
require that implementations MUST *permit* the use of
full-strength keys, and { MUST | SHOULD } *encourage* the
use of full-strength keys.

Also, one sentence in draft 06 should be expanded to better
distinguish the insecure practice from various other secure ways
of deriving shared secrets from combinations of passwords and keys.
Here's a suggested expansion:

        "Note that it is a common but [[ typically ]] insecure practice to have a
        shared key derived [[ solely ]] from a user chosen password[[,
        without incorporating another source of randomness ]]."

-- David