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

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



Paul,

In light of your repeated inappropriate referrals to RFC 2119,
a few things need to be said.

>At 11:57 AM -0400 4/10/03, David Jablon wrote:
>>I think the use of very weak keys breaks the utility of the method,
>>and even if allowed, should not be encouraged.

At 10:15 AM 4/10/03 -0700, Paul Hoffman / VPNC wrote:
>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.

There is no huge difference between a 20-bit key and a zero-bit key, in this method.
They're both broken. Do you really want to argue otherwise?

David wrote:
>>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.

Paul wrote:
>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.

I see you also don't agree with being particularly polite too, in continuing
to imply that I am somehow ignorant of the rules or unable to apply them.

Regarding the text in question:

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

It merely mandates the size of a value that used to create another protocol
element, in the interest of guaranteeing interoperability and increasing
security.  This is more than sufficient motivation for using the term MUST.

Whether the text actually achieves those objectives, without introducing
unwanted side-effects, may be a point of debate. But it cannot legitimately
be dismissed by simply telling the opponent to go read a dictionary.

Speaking of which:

 From RFC 2119:
>6. Guidance in the use of these Imperatives
>
>  [The imperative "MUST"] MUST only be used where it is
>   actually required for interoperation or to limit behavior which has
>   potential for causing harm (e.g., limiting retransmisssions)

Regarding interoperation, it is actually required that two parties
agree on key size.  This motivates providing clear guidance for
the appropriate key size, or range of key sizes, that implementations
must support.  And I have heard no technical reason of any kind to
motivate using a *key* size other than the size of the prf key.

Note, again, that password size is a different matter than key size.
Specifying limits for acceptable key length does not imply any limits
on the length of a password. One can use hash, padding, and
truncation functions to transform any password into a key of any
desired length. Limitations on key size may constrain the choices
of such a transformation method, but, I believe this could only
have a *positive* effect on interoperability, even if you dismiss
Hugo's stated positive effect on security.

Regarding security, I simply call attention to the words "to limit
behavior which has the potential for causing harm".  Maybe I've
misinterpreted your words, but this sounds like a *significantly*
lower threshhold for use of the term "MUST" than your interpretation.
Are "retransmissions" so much more devastating than using a
very weak key?

Paul wrote:
>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.

I presume your words attempt to justify the point that people
should be able to get the rope to do it.  Fine.  I gave that one to you
already, and I won't debate it ... unless you really really want me to.

My point is that people already have that rope, to use a password of
any size or quality, regardless of any MUST/SHOULD limitations on
key size.  Thus, your words are pointless in an argument against
the use of "MUST" in this context.

David wrote:
>>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.

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

Loose specs. sink ships.  Can anyone think of *any* legitimate technical
reason to use other *key* sizes?  Why leave potential implementors
guessing?

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

I believe that a decreased level of security, with the *potential* to
cause harm, perhaps by naive or confused implementors, *is* a valid
technical reason. Especially if the concern is easily avoided.

David wrote:
>>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.

Paul wrote:
>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?

I'm going to deliberately sound dense in this first part of the answer, to make a point:

I have no idea what it means to "agree on a shared secret [key] of "Baseball2003"".

Of course, I do have a fairly good idea of what it means to agree on a shared secret
*password* of "Baseball2003".  But without knowing binary character representation
(ASCII, UNICODE, ...?) and other aspects of the necessary, but unspecified, password-to-key
transformation function (hash it, pad it, truncate it, include the null, ...?), it's not at all clear
that two different implementations will interoperate using a shared password.

Second, the SHOULD version of the text by itself does not absolutely guarantee
support for *keys* that have a size that matches the prf.  One implementation may
use fixed 128-bit keys, another may use 256, and a third may use another arbitrary
range, all for reasons that a (perhaps naive) implementor may deem technically valid.
How can one determine a set of keys that will work for all implementations?
"SHOULD support X" is not the same as "MUST support X and MAY support Y".

There are multiple kinds of interoperability concerns, between different
implementations using a given key, between different implementations
using a given password, and between different implementations where
only one provides a convenient means to enter a password.

But even if the text is *never* be clear about how to deal with passwords in a
standard way in this pre-shared key mechanism, it *must* be crystal clear
how to deal with keys.  The MUST version achieves that, and draws a clear
line in the sand between passwords and keys, whereas the SHOULD version
does neither.

Paul wrote:
>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.

Please, spare us all the unnecessary lecture.

David wrote:
>>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.

Paul wrote:
>Where in the draft is that?

Surely you're not asking about where in the draft it talks about passwords,
and a password obviously has to come from somewhere. But this is old news.
I addressed your concern anyway.   Just in case you missed it, I carefully
avoided using RFC 2119 terms with regard to passwords in the text in
the message to which you've responded, in light of your concern that
passwords are elements of the user interface.

My main point, in case I haven't beaten it to death by now, is that a "password"
is not the same thing as a "key".  Part of your argument only makes sense
if one mistakenly interprets these terms as synonyms.

Regardless of how the text ends up, I urge that the distinction between
passwords and keys be kept clear, and that at least interoperability when
using keys be guaranteed.

-- David