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

[David Jablon <dpj@theworld.com>]

I agree with recommendation 2(b) with a further suggestion.

At 07:35 AM 4/8/03 +0300, Hugo Krawczyk wrote:
>(2) Issue of key length for the prf: Make sure that the users of ikev2
>provide enough bits to key the prf. 
>This is very simple and requires only the following two editorial changes:
>
> a- [ ... ]
> b- specify that when pre-sharing a key for use in prf-based authentication 
>    (i.e., Shared Secret") this key SHOULD [ be ] of the length of the key for the
>    prf agreed for use by the parties

I recommend adding "and this key SHOULD NOT be derived solely
from a password or other data that has less randomness than a
truly random key of the appropriate length."

>       Note: here I would have preferred to say MUST instead of SHOULD, 
>        but I know that you want to allow the use of passwords in this mode.

I too prefer "MUST", and I prefer "MUST NOT" in the addition.

If this text is meant to allow the shared secret key to be a password,
or to be derived solely from a password, it is insufficient to specify
merely the length of the shared secret.  If not, then MUST and
MUST NOT seem more appropriate.

In any case, the text should at least encourage implementations that
encourage use of a shared secret that has sufficient randomness,
which, in the case of a password, typically requires that the password
be a good amount longer than an equivalent key.

Regarding:

>    We assume that the prf
>    function takes a variable length key and produces a fixed length
>    output. When the key for the prf function has fixed length, its
>    specification for use in IKEv2 must include a procedure for deriving
>    its required fixed length key from a variable length key.
>
>This may be short and elegant but it actually creates a big problem 
>for who wants to use non-HMAC prfs, in particular AES.
>Indeed, AES takes fixed keys only and it has no built-in mechanism to handle
>variable-length keys.  Designing such a mechanism is a very non-trivial
>problem (as those subscribed to the cfrg list have witnessed recently).
>Therefore, your text above while seemingly simplifying the IKE specification
>actually requires to standarize something (variable key support for AES or
>general block ciphers) that can take long to get right technically and even
>longer to get ietf consensus. In contrast, the spedifications on the length 
>of nonces and preshared key, suggested above, are simple to state, and 
>transform the variable key headache into a non-issue.
        
It seems like a tradeoff must be made here.  A prf that takes variable
length input might be seen as useful to accept passphrases that are
a good amount longer than equivalent shared secret keys.  I think the
suggested (amended) text only makes the headache disappear
when shared secrets are keys, and not things like passphrases.

-- David