Subject: [Hipsec] Closing issue 17: Unifying crypto suites for HIP and ESP SAs

From: [email-masked] (Pekka Nikander)
Date: Wed Oct 1 04:07:01 2003

Since we added the HMAC parameter, we now need separate
integrity and encryption keys in the HIP SAs.  To facilitate
this, -08-pre defines the HIP transform crypto parameters
differently from -07

Please read the revised sections, and send your comments
to the list.  This time I am not quite happy with the
text; I'm afraid there are corner cases (e.g. with NES)
that haven't been really worked out.

The relevant sections:

6.3.4  HIP_TRANSFORM
6.3.5  ESP_TRANSFORM
9.  HIP KEYMAT

URLs for easy reading:

http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#anchor32
http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#keymat

--Pekka Nikander

---

From: [email-masked] (Andrew McGregor)
Date: Thu Oct 2 18:47:01 2003

-----BEGIN PGP SIGNED MESSAGE-----

It seems to me that current text is fine so long as we don't want to rekey 
the HIP keys along with ESP.

It seems to me that the rekey procedure should do ESP only, since there is 
a way if we really want to to rekey HIP (simulate loss of state, i.e. 
increment the birthday and send an I2).  Anything else will create races 
with respect to packet reordering in the network.  In a fast mobility 
situation, this will happen and could very easily result in losing contact 
unnecessarily.  I don't see a large security benefit to rekeying HIP 
anyway, since in most cases the number of messages protected will be fairly 
small by comparison to the number of ESP payloads.

Comments?

Andrew

- --On Wednesday, October 01, 2003 11:34:18 AM +0300 Pekka Nikander 
<[email-masked]> wrote:

> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec
>
>

- --------
Andrew McGregor
Director, Scientific Advisor
IndraNet Technologies Ltd
http://www.indranet.co.nz/
Office: +64 3 3656485
Mobile: +64 21 898856

---

From: [email-masked] (Pekka Nikander)
Date: Fri Oct 3 02:26:02 2003

> small by comparison to the number of ESP payloads.

Agreed.

Now, what shall we do with KEYMAT?  I have currently written the
text so that the first bytes of the new KEYMAT would be thrown
away, corresponding to the non-used new HIP keys.  Is that what
we want, or would it be better to draw the new ESP keys from
the beginning of KEYMAT?

Basically, the question is of what is simpler from the implementation
point of view.  Since I have not been involved in writing the
crypto parts of our implementation, I don't know, and can't have any
good opinion.

--Pekka

---

From: [email-masked] (Andrew McGregor)
Date: Fri Oct 3 07:42:01 2003

-----BEGIN PGP SIGNED MESSAGE-----

> crypto parts of our implementation, I don't know, and can't have any

Six of one, half a dozen of the other.  Throwing away the first keys drawn 
may take a few more cycles (will for me), but may mean less code for some 
implementations.  Logically, KEYMAT is a stream and we should just draw 
from the beginning, is my opinion.

Andrew

- --------
Andrew McGregor

---

From: [email-masked] (Julien Laganier)
Date: Fri Oct 3 08:14:00 2003

> we want, or would it be better to draw the new ESP keys from

Pekka,

AFAICS, the only point in favor of throwing away the non-used HIP keys might 
be to make legacy implementations compatible with an hypothetical future 
usage of the HIP keys; otherwise I can't imagine what simplification goal 
would be achieved by throwing them, nor what would be the usefullness of 
rekeying HIP.

Thanks,

--julien

---

From: [email-masked] (Pekka Nikander)
Date: Mon Oct 6 01:50:01 2003

Thanks for your input, Andrew and Julien!

> would be achieved by throwing them, nor what would be the usefullness of 

The consensus seems to be that we draw the new ESP keys from
the beginning of the new KEYMAT.

I have fixed the draft.

Unless there are any other problems here, the issue is now closed.
(Which, of course, doesn't mean that it can't be reopened if
needed, or that we can't create new issues.  I just will not
consider this any more for getting -08 out.)

--Pekka

---

From: [email-masked] (Pekka Nikander)
Date: Thu Oct 9 04:14:00 2003

> this, -08-pre defines the HIP transform crypto parameters

One more minor nit:  In 6.3.4, the max number of transforms
is three.  In 6.3.5, the max number of transforms is six.
Fixed now so that it is six (6) in both cases.

(Yes, we implemented this today, cutting again our line count :-)

--Pekka Nikander