Re: IKEv2 use of HMAC-SHA-1 for Key Derivation

[Russ Housley <housley@vigilsec.com>]

Hugo:

Thanks for the reply.

I agree that the overhead of the additional SHA-1 application for each 
output is insignificant when compared to the other operations being 
performed.  However, I am seeing other standards adopt the same 
construction, so I wanted to make sure that I understand the properties 
that are needed.

Russ

At 07:43 AM 11/27/2002 +0200, Hugo Krawczyk wrote:
>Russ,
>
>I guess that you are suggesting to use "prepended SHA1"  (i.e. SHA1(K,...))
>instead of HMAC as the the default instantiation of the prf in IKEv2. The
>advantage of "prepended SHA1" is that it may require one less application
>of the compression function of SHA1 (per 160 bits of key material). The
>disadvantage is that, in general, "prepended SHA1" is broken as a prf
>(extension attacks as those in the Preneel-van Oorschot paper break the
>unpredictability of the function). While this later disadvantage may not
>be crucial in the current application (since the known attacks against
>prepended-key hash use variable length inputs), the computational
>advantage in IKEv2 is not an issue either (what is the cost of the extra
>application of the compression function compared to the DH exchange, the
>signatures, the encryption, the MAC, and (if applicable) the DoS cookie
>generation?) Therefore, it seems to me that using a prf that is more
>secure in general and computationally equivalent in this context is the
>right choice. Not to mention that IKEv2 requires the use of a MAC function
>for which HMAC is definitely more secure than "prepended SHA1" and thus
>using HMAC for both saves the implementation of yet another function.
>
>Hugo
>
>On Tue, 26 Nov 2002, Russ Housley wrote:
>
> > On pages 23 and 33 of draft-ietf-ipsec-ikev2-03.txt, there is a discussion
> > of the use of HMAC-SHA1 for key derivation.  I have no doubt that this
> > construction is secure, but I do wonder if it is overkill.
> >
> > HMAC-SHA1 was designed as a packet integrity mechanism.  The designers
> > needed to deal with many concerns that are not obviously (at least to me)
> > needed to generate a good key derivation function.
> > > Can anyone tell me the properties HMAC-SHA1 that are needed here that
>are
> > not otherwise provided by a straightforward application of SHA1?
> >
> > Putting it another way, the current document uses:
> >
> >     T1 = HMAC-SHA1(K, S | 0x01)
> >     T2 = HMAC-SHA1(K, T1 | S | 0x02)
> >     T3 = HMAC-SHA1(K, T2 | S | 0x03)
> >     T4 = HMAC-SHA1(K, T3 | S | 0x04)
> >
> > What needed property does this construction have that is not provided by
> > the following?
> >
> >     T1 = SHA1(K, S | 0x01)
> >     T2 = SHA1(K, T1 | S | 0x02)
> >     T3 = SHA1(K, T2 | S | 0x03)
> >     T4 = SHA1(K, T3 | S | 0x04)
> >
> > Thanks for any insights that can be provided.
> >
> > Russ
> >
> >