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

[David Jablon <dpj@theworld.com>]

Paul,

An amended version of the text in question is at the end.

The rest of this note is meant to explain or clarify any remaining
differences of opinion, or mistakes.


At 04:17 PM 4/9/03 -0700, Paul Hoffman / VPNC wrote:
>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. ...

No, I really, really don't want to debate the *allow for* point.
(regardless of how I feel about that practice. :-)

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

I pointed out a problem or two with using "SHOULD", that don't
exist when using "MUST".  You noted different problems or issues
with using the "MUST", "MUST NOT", and "SHOULD NOT" text.

Surely, we can both assume we're at least *trying* to properly use
these terms, despite any momentary blindness we might have
for the other's viewpoint.

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

I think I took a broader view of what "break something" means.
In the spirit of Hugo's medical analogy:
"The operation was a success!  But the patient died from complications." 
I think the use of very weak keys breaks the utility of the method,
and even if allowed, should not be encouraged.

But you're absolutely right that I haven't justified the "MUST NOT" text,
given that I choose not to debate accomodation for weak keys.
"MUST NOT" doesn't work in that sense, regardless of what "I prefer".

I wonder if we can agree that the "MUST" text in the first part works?
Especially in light of the two other points that Hugo raised:
(1) that having the first case be "MUST" fixes other problems, and
(2) that it still permits implementors to derive full-length keys from
passwords of arbitrary length using arbitrary functions, if they so choose.

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

You're preaching to a choir-boy.

User security and user convenience are surely good things to seek.
And I'd prefer to see implementors and users, that choose to use
passwords, encouraged to seek alternate methods, where one may
have a better chance of achieving these goals simultaneaously.
I think that is part of the value of EAP.

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

Good. I too like "telling users what they should do to make their systems secure."
And I see no need to qualify that point.

>But that is quite different than mandating that IKEv2 systems have to check the randomness of the preshared key.

Fine. I didn't propose that, and I never meant such a mandate to be implied.

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

Good.

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

It's not a definition issue.  In the first part, "MUST" is justified, but in the
second part, "MUST NOT" isn't.

Part 1:
>>        ... this key {SHOULD | MUST} be of the length
>>        of the key for the prf agreed for use by the parties, ...

I see no need to re-define "MUST" and "SHOULD" to support this point:
The "SHOULD" here gives license to an implementator to do potentially
nasty things, like say, truncating all such keys to 64-bits,
in the interest of handling passwords in some way.

That "MUST" here helps to guarantee interoperability when using
full-length keys, and that "SHOULD" does not, is something I thought
you'd agree with.  And if not then, then perhaps now, in light of points
(1) and (2) above.

However, mandating a fixed key length does imply something about
transformations that may be used to derive a key from a variable-length
password.  But, in light of your comments below, it's not clear to me
whether such transformations are in the proper scope of this document.

Part 2:
>>       ... 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."

I concede the point that the "MUST NOT" version doesn't accomodate
implementations that allow weak keys to be derived from passwords.
To accomodate this practice, this could be either "SHOULD NOT"
or "should not".  (More on that below.)  I think either form permits,
but doesn't promote the practice, which seems reasonable.

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

No, but I could see why you might think so. I tried to acknowledged the
legitimacy of your alternate interpretation by proposing an alternate
solution:

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

Good.  (I think.)

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

I see the point, but I'm not so sure about where that scope line is, or should be.

I think the current draft has already crossed the line in talking about the kinds
of keying material (e.g. passwords) that users will presumably stuff into the
user interface.  And to maximize interoperability, one may wish to consider
the type and form of keying material that can be input (or output?), and any
relevant transformations that may be used by different implementations.
Are special password-to-key transformations deemed out of scope?
If so, how is a requirement to be able to permit input of any full-strength
key, which seems similarly a user interface issue, justified as being in scope?

In any case, I hope we agree that its generally a good thing to
recommend discouraging use of shared secret keys that are derived solely
from passwords without another source of randomness, and that it's good
to elaborate the security implications of not following that recommendation.

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

Ok.  I sometimes use the term "password" broadly to encompass other kinds
of memorizable authenticators, but expanding discussion to include
high-entropy passphrases seems like opening an even larger can.

In light of the above, and in the spirit of being constructive,
see if the following text addresses your concerns:

        "When pre-sharing a key for use in prf-based authentication
        (i.e., "Shared Secret") the key MUST be of the length
        of the key for the prf agreed for use by the parties.
        The implementation must permit the use of any specific key
        value of that length, and the key should not be derived solely
        from a password or other data that is shorter than or is less
        random than a truly random key of the appropriate length. ..."

Even though "is shorter than" seems redundant in light of
"is less random than", I think this makes it clear that password
length and key length are separate matters.

-- David