[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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