Re: AES-based PRF for IKEv2

[Hugo Krawczyk <hugo@ee.technion.ac.il>]

see below

On Wed, 26 Mar 2003, Paul Hoffman / VPNC wrote:

> At 6:22 AM +0200 3/26/03, Hugo Krawczyk wrote:
> >Preshared key is NOT used in the calculation of SKEYSEED.
> >Sorry if my text gave the wrong impression.
> >
> >The only thing we need to make sure is that the ikev2 document will
> >mandate a minimal length for the nonces Ni and Nr (each has to be at least
> >of half the length of the prf), and a minimal size of the preshared key
> >(which has to be at least of the length of the prf key).
> 
> OK, then I'm still confused. Why does the length of the preshared key 
> have to be half the length of the prf key? Why are they linked at all?

This time I am not taking responsibility for your confusion :)
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).

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)

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

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

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

Hugo

> --Paul Hoffman, Director
> --VPN Consortium
>