Subject: [Hipsec] Update race condition

From: [email-masked] (Pekka Nikander)
Date: Fri Apr 2 08:50:01 2004

[Sorry for the delay in answering.]

> In the original KEYMAT generation, the HITs are put into the KEYMAT
> "generator" in a certain order. The key retrieval is done depending on
> the Initiator / Responder status.

Nope.  See the draft in more detail :)

>     K1   = SHA-1( Kij | sort(HIT-I | HIT-R) | 0x01 )
>    ...
>    Sort(HIT-I | HIT-R) is defined as the network byte order
>    concatenation of the two HITs, with the smaller HIT preceding the
>    larger HIT, resulting from the numeric comparison of the two HITs
>    interpreted as positive (unsigned) 128-bit integers in network byte
>    order.

> In the UPDATE case, we retrieve keys using the HIT comparison. I don't 
> see direct analogy between these processes. Or was this what you 
> meant?

To me they seem to be identical.

> 8.10 Processing UPDATE packet
>
> When a host receives an UPDATE packet, it indicates that either the 
> host
> itself has earlier requested rekeying or the peer is initiating 
> rekeying.
>
> If either of the hosts requires that a new KEYMAT must be generated, 
> the generation is done as described in 9. HIP KEYMAT.

I think the text above is enough.

> The order of the keys retrieved from the KEYMAT during rekeying process
> depends on the HIT value comparison. We denote the host with lower HIT
> value with HOST_l and, respectively, the host with greater HIT with
> HOST_g. The HITs are compared in network byte order. The keys are
> retrieved from the KEYMAT in the following order.

That nor any of the following suggested text is not needed, as far as I 
can see.

>>>    5.   If the received UPDATE does not contain a Diffie-Hellman
>>>         parameter, the received Keymat Index MUST be larger or equal 
>>> to
>>>         the index of the next byte to be drawn from the current 
>>> KEYMAT.
>>>         If the host is in REKEYING state, a smaller Keymat Index 
>>> value
>>>         MAY be accepted.  If the host is in ESTABLISHED state and 
>>> this
>>>         test fails, the packet SHOULD be dropped and the system 
>>> SHOULD
>>>         log an error message.
>> I find this lacking of information.  I think there should be some 
>> description
>> of the reasons for the MAY, i.e., under which condition accepting 
>> such a
>> lower index is reasonable.
>
> ... a smaller Keymat Index MAY be accepted, if the host itself has
> skipped part of the KEYMAT and selected a bigger index for the
> previously sent UPDATE packet.

Ok.

--Pekka

---

From: [email-masked] (Petri Jokela)
Date: Mon Apr 5 01:32:00 2004

> Nope.  See the draft in more detail :)

Now you have to point out this for me, because I read from section 9:

--8<--

The initial keys are drawn sequentially in the following order:
   HIP-IR encryption key for Initiator's outgoing HIP packets
   HIP-IR integrity (HMAC) key for Initiator's outgoing HIP packets
   (... and so on)

The IR and RI denotes the direction of the traffic where the key is
applied.  The IR describes "from the Initiator to the Responder"
-direction and the RI the other direction.

--8<--

For me this looks clear that the key retrieval is done using Initiator / 
Responder status.

/petri

-- 
Petri Jokela                        Tel:    +358 9 299 2413
Research scientist                  Fax:    +358 9 299 3535
NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
Oy L M Ericsson Ab                  email: [email-masked]

---

From: [email-masked] (Pekka Nikander)
Date: Tue Apr 6 06:45:01 2004

> -direction and the RI the other direction.

Oops.  We are apparently comparing apples and oranges.

The HITs are *put* into the KEYMAT in sorting order,
still in Section 9:

>   The KEYMAT is derived by feeding Kij and the HITs into the following
>    operation; the | operation denotes concatenation.
>
>     KEYMAT = K1 | K2 | K3 | ...
>           where
>

Note the *sort* operation.

The keys are *drawn* from the KEYMAT in role depending order.
I've had so many interruptions during this discussion that I
don't remember any more which matters.

--Pekka

---

From: [email-masked] (Petri Jokela)
Date: Tue Apr 6 08:14:00 2004

> don't remember any more which matters.

Yes, the discussion was about drawing the keys from the keymat during 
UPDATE that will depend on the HIT comparison, and will be different 
from the original key drawing during base exchange. Generation will be 
done during the base exchange or in a similar way during UPDATE.

/petri

---

From: [email-masked] (Pekka Nikander)
Date: Tue Apr 6 13:41:01 2004

> done during the base exchange or in a similar way during UPDATE.

Just to simplify code:  Should we change the case even in the base
exchange case, so that we use the HIT order instead of the roles?
In other words, should we define the key order to _always_ depend
on the order of HITs, regardless of the roles of the parties?

Any opinions?

--Pekka

---

From: [email-masked] (Jonathan Wood)
Date: Tue Apr 6 16:31:04 2004

Sounds like a good idea.

On Apr 6, 2004, at 11:29 AM, Pekka Nikander wrote:
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: [email-masked] (Andrew McGregor)
Date: Tue Apr 6 23:23:00 2004

Consistency is preferable, in my opinion.  Therefore, yes, we should adopt 
the same method in each case, whatever it is.

Andrew

---

From: [email-masked] (Pekka Nikander)
Date: Wed Apr 7 00:10:02 2004

> Consistency is preferable, in my opinion.  Therefore, yes, we should 
> adopt the same method in each case, whatever it is.

I guess I'm seeing consensus for this change (though I'm
not a chair and therefore can't really announce one... :)

Petri, I guess you can create an issue, edit in the change,
and either close the issue or leave it still tentative for a while...
(if I was still editor I would close the case, but the idea
was mine, anyway...)

--Pekka

---

From: [email-masked] (Petri Jokela)
Date: Wed Apr 7 00:35:01 2004

> (if I was still editor I would close the case, but the idea

Yes, this simplifies the key drawing. I'll put it in the next version, 
if there are no arguments (soon) against it.

/petri

---

From: [email-masked] (Petri Jokela)
Date: Thu Apr 15 06:46:00 2004

As agreed earlier, the key retrieval will be based on HIT comparison. 
Here is some initial new text that describes the key retrieval order for 
the base exchange and for rekeying.

First, the key retrieval order described in 8.10 for UPDATE:

--8<--
8.10 Processing UPDATE packets

    When a system receives an UPDATE packet, its processing depends on
    whether the packet is a reply to a previously sent UPDATE packet or
    the UPDATE is a new packet.

    The order of the keys retrieved from the KEYMAT during rekeying
    process is similar to that described in Section 9.  Note, that only
    IPsec ESP keys are retrieved during rekeying process, not the HIP
    keys.

    The following steps define the conceptual processing rules for
    handling a received UPDATE packet:

--8<--

And in section 9, the new order for drawing keys, based on HIT comparison:

--8<--

    The initial keys are drawn sequentially in the order that is
    determined by the numeric comparison of the two HITs, with comparison
    method described in the previous paragraph.  HOST_g denotes the host
    with the greater HIT value, and HOST_l the host with the lower
    HIT value.

    The drawing order for initial keys:

       HIP-gl encryption key for HOST_g's outgoing HIP packets

       HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets

       HIP-lg encryption key (currently unused) for HOST_l's outgoing HIP
       packets

       HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets

       SA-gl ESP encryption key for HOST_g's outgoing traffic

       SA-gl ESP authentication key for HOST_g's outgoing traffic

       SA-lg ESP encryption key for HOST_l's outgoing traffic

       SA-lg ESP authentication key for HOST_l's outgoing traffic

--8<--

/petri

---

From: [email-masked] (Pekka Nikander)
Date: Thu Apr 15 07:29:01 2004

> As agreed earlier, the key retrieval will be based on HIT
> comparison. Here is some initial new text that describes
> the key retrieval order for the base exchange and for rekeying.

Both looked good to me, but I may have missed something.

--Pekka