[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

At 4:57 PM -0400 4/9/03, David Jablon wrote: 
I don't really want to debate the point of whether the text should *allow* for
the use of weakened Shared Secret keys.

It sounds like you do. RFC 2119 has very specific definitions for SHOULD, SHOULD NOT, MUST, and MUST NOT. Saying "MUST NOT" has very different semantics than "SHOULD NOT do this because it is weak".

I assume you are not proposing that we remove the normative reference to RFC 2119. If you are, that's a very different topic...

  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.

I don't either, that's why I asked. "MUST NOT" would indicate that it would break something, "SHOULD NOT" would indicate that the the something would work but probably not the way one would want.

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.

I have never read a security proof, but if they rely on user-selected things like preshared keys to have a particularly amount of randomness, then they are not based on reality. No matter what you tell them, users will sometimes choose passwords or even non-password preshared secrets with less than 112/128 bits of randomness. They just will.

We are designing IKEv2 for Internet users, not for people who write security proofs. Having said that, I obviously support telling users as well as we can what they should do to make their systems secure in the way that the security proof says it is. But that is quite different than mandating that IKEv2 systems have to check the randomness of the preshared key.

The text in draft 06 states that human-chosen password-derived
keys are insecure in this context but it doesn't fully explain why.

We should obviously fix that.

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

That is not what RFC 2119 says for the difference between SHOULD and MUST. If you want us to redefine the words in RFC 2119, we can, but you can't both normatively reference RFC 2119 and use the argument above.

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

By using "MUST", you are.

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

Ah, much better! There is an interoperability reason why they MUST: some systems designed for people who can't enter passwords if they tried will have preshared secrets that are long.

 and { MUST | SHOULD } *encourage* the
use of full-strength keys.

Now you are talking about the user interface, which most definitely is out of scope for this protocol document. If you want to write an implementation guide for IKEv2, this would obviously be appropriate there.

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

I would leave out the "typically": you simply don't see passwords with 112 or 128 bits of randomness. I don't agree with the final clause because we can't mandate that IKEv2 systems change the password on the user. Instead, you could say "In order to get preshared secrets with a sufficient amount of randomness, users typically need those preshared secrets supplied by systems that compute them."

--Paul Hoffman, Director
--VPN Consortium