Re: AES-based PRF for IKEv2

[Paul Hoffman / VPNC <paul.hoffman@vpnc.org>]

At 7:35 PM +0200 3/26/03, Hugo Krawczyk wrote:
>I said that the preshared key "has to be at least of the length of the prf
>key". ("half" was used for the nonces since we concatenate them for
>creating a key to the prf, not for the pre-shared key).

Right.

>And the reason we need to specify the above for the length of the
>preshared key is that we use it as an input to the prf (section 2.15,
>page 26 of ikev2-05)

It is *part* of the input: it is concatenated with 17 bytes of ASCII 
text. The secret/password doesn't have to be at least the length of 
the prf key, it has to be at least the length of the prf key minus 17 
bytes. If the prf key has to be 128 bits, then the secret/password 
can be of any length, yes? Also, don't all prf functions that we 
allow do padding?

In 2.15, I see the sentence "The pre-shared key SHOULD contain as 
much randomness as the strongest key being negotiated." but I think 
it should say "unpredictability" instead of "randomness".

Of course, we need to warn about the authentication problems with 
using passwords or easily-predictable preshared secrets (such as 
short random strings instead of long random strings), and we should 
explain that they can lead to man-in-the-middle attacks but not 
passive attacks.

>  > >There is no reason that an implementation will not be able to meet these
>>  >requirements. The only case in which this may happen is if someone tries
>>  >to use a password as a preshared key.
>>
>>  Exactly. This is quite common in the real world.
>
>This is a wrong practice that ikev2 should not officially support
>(actually it should officially unsuport).

How are you going to enforce your proposed rule? Each side is 
supposed to somehow deduce that the preshared key that they agreed to 
is not a password? We should not specify rules that cannot be 
enforced by implementations.

>Using passwords as pre-shared keys might have been forced upon
>applications before because ikev1 did not have any other method to support
>password-based authentication. IKEv2 does have this method. So whoever
>upgrades from ikev1 to ikev2 should also upgrade from low-entropy
>pre-shared key to EAO-based exchange (section 2.16 of ikev2-05)

Yes, they should. And we should encourage them to do so, probably in 
section 2.15. But we cannot force them to.

>  > >  But that should be seen as a
>>  >vioaltion of the purpose of pre-shared key mode. Especially in view that
>>  >ikev2 explicitly supports password-based authentication methods through
>>  >its EAP exchange.
>>
>>  If the preshared key is only used for authentication, not key
>>  strength, it is not a violation of the spec for someone to have weak
>>  authentication.
>
>I do not agree! Breaking authentication is a much easier (and
>realistic) way to BREAK the SECRECY property of the protocol than
>cryptanalyzing the DH, the PRF or encryption functions.

This is only true for man-in-the-middle attacks, not passive attacks, 
yes? We need to be clear here.

>  > If using a password instead of a real preshared key
>>  weakens the key strength, we need to point that out very clearly in
>>  the text. (But I still don't see where that happens.)
>>
>
>OK. Please ask Charlie to add to the security considerations section the
>something like:
>
>"The strength of the key exchanged via IKEv2 is not stronger (for the sake of
>authentication and secrecy) than the strength of the authentication method
>used in the protocol.

s/no stronger/no stronger against man-in-the-middle attacks/

>   This is the case for the signature-based
>authentication, the pre-shared key authentication, and the EAP methods.
>In particular, applications that use low-entropy keys (such as passwords)
>for authentication should use one of the EAP methods, and must not use the
>low-entropy key as a preshared secret. Doing the latter opens the protocol
>to dictionary attacks that compromise the strength of authentication and
>of the exchanged keys."

... against man-in-the-middle attacks.

If we are going to say this, we *have* to explain why using passwords 
under EAP is better than using them as preshared secrets. Typical 
implementers will not figure this out and are therefore likely to 
mess it up.

--Paul Hoffman, Director
--VPN Consortium