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

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

At 11:57 AM -0400 4/10/03, David Jablon wrote: 
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.

It doesn't break the utility of the method, it weakens it. There is a huge difference there. If it breaks it, you cannot ever allow it; if it weakens it, you are responsible for pointing out the weakness.

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.

No, we still don't agree. If we say that the definition of MUST etc. comes from RFC 2119, we have to use that definition. This isn't hair-splitting: it is simple protocol mechanics.

The "other problems" that it fixes are non-fatal problems. They are related to the weakness of passwords, namely their susceptibility to faster dictionary attacks, but they are not fatal to the protocol. They don't affect the communication channel.

Please remember that we are talking about pre-shared keys here: *both* parties have to agree to using any particular key. If that is their shared security policy (even after our exhortations about the weakness of it), then that is what they want.

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

By using a MUST in the proposed wording, you are saying that the implementation *has* to prevent passwords from being used.

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

Only if they have a technical reason to do so; that's what RFC 2119 says.

There is no technical reason that I know of that says that the length of the key matters to the PRF. If the length is shorter, the PRF will not fail, it will simply produce that much less value.

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.

Sorry, maybe I'm being dense. I don't see how the SHOULD would not guarantee the interoperability. Let's say that both sides are using a PRF that wants 128 bits of keying material, and the two parties agree to a shared secret of "Baseball2003". How is the guarantee of interoperability broken?

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

The IETF almost never mandates how a user interface or documentation should act. This is meant to be an IETF protocol, so we have to follow the IETF rules. That's why we are using RFC 2119, even though we could use some other definitions of MUST and SHOULD if we wanted to.

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.

Where in the draft is that?

  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.

That is already done: none are prohibited.

Are special password-to-key transformations deemed out of scope?

Of course not: the two sides agree to a shared secret, regardless of how the secret is formed.

--Paul Hoffman, Director
--VPN Consortium