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

[daw@mozart.cs.berkeley.edu (David Wagner)]

The Purple Streak, Hilarie Orman wrote:
>What I've been suggesting to Hugo and Charlie is that the iterated
>counter be prepended to K before using HMAC:
>
>     T1 = HMAC-SHA1(0x00 | K, S)
>     T2 = HMAC-SHA1(0x01 | K, T1 | S) 
>     T3 = HMAC-SHA1(0x02 | K, T2 | S |
>     T4 = HMAC-SHA1(0x03 | K, T3 | S )
>
>I believe this works properly for all cases, and uses a zero-based
>counter (a real nit).

This is a tangent, but:

Is there any reason to prefer the counter being part of the key
rather than the message?  The following seems slightly better to me:
    T1 = HMAC-SHA1(K, 0x00 | S)
    T2 = HMAC-SHA1(K, 0x01 | T1 | S) 
    T3 = HMAC-SHA1(K, 0x02 | T2 | S |
    T4 = HMAC-SHA1(K, 0x03 | T3 | S )
My version is secure if HMAC-SHA1 is a secure PRF.  Your version
also requires that HMAC-SHA1 be secure against related-key attacks.

This is almost certainly a very minor nitpick.  It seems very
unlikely that this will make a difference in practice.  Nonetheless,
I do like my construction a little better, on general principles.

Again, this is not at all important, and it is tangential to
what you proposed.  My apologies for the distraction.