[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