Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt

[Tero Kivinen <[e-mail]>]

Scott Fluhrer (sfluhrer) writes:
> > Btw, both PRF_AES128_XCBC and PRF_AES128_CMAC do use 128-bit keys
> > always, they cannot use longer keys, so the text saying "even though they
> > can use larger keys" is wrong, as those versions cannot use longer keys.
> 
> Actually, if you look through the definitions of the transforms that
> IANA points to, RFC4434 and RFC4615, the transform can take as input
> a "key" longer than 128 bits.  Yes, if you look inside the
> definition of the transform, you see that they transform the
> arbitrary-length "key" into a 128 bit one; people quite often don't
> look into the innards of their crypto (nor should they have to). 

Yes, as PRF they can take arbitrary long keys, but the AES is always
using 128-bit keys. So both of those are true in a way. For encryption
algorithms you can use the key length attribute to specify key length
for the AES, but for the PRF or INTEG you cannot, instead they use
fixed length key for AES.

The original version of the AES-XCBC-PRF-128 specified in the RFC3664
did require the exactly 128-bit key for the PRF use also, but this
caused problems as in IKEv2 we want to use PRF on the nonces, and the
shared secret, thus requiring them to be 128-bits caused problems.
Because of this RFC4434 was done so that it allows arbitrary sized
keying material but the PRF still has security of 128-bit...

I.e. the prehashing done to feed the PRF key to the AES is just to
allow any sized material, and using longer PRF key does not increase
the security.

So at least separate the "PRF key" and "AES key" in the text, so it is
clear which text we are refering.
-- 
[e-mail]