Subject: [Hipsec] Issues for draft-moskowitz-hip-08 further development

From: [email-masked] (Petri Jokela)
Date: Thu Oct 30 09:43:01 2003

Hi everyone,

I have now installed an issue tracking system for the 
draft-moskowitz-hip-xx development. Unfortunately, issue numbering that 
Pekka used is no longer valid. The numbering of issues begins (again) 
form 1.

The issue tracker can be found from:

http://hip4inter.net/issues/

and with userid: guest and password: guest you get a reading access to 
the issue database.

For Issues #1 and #2 (originally from the Pekka's issue list #18 and 
#25), Thomas and Miika have offered their helping hands. I haven't yet 
begun the edition of the draft, I suppose that there is no hurry before 
Minneapolis, -08 will be used there anyway.

During HIP for *BSD and HIPL interop tests today, we found one 
interpretation problem with the -08 draft (Issue #3 in the issue 
tracker). We had understood the ESP key usage is different ways. In 
Minneapolis, it would be nice if everyone use the keys in the same way :-)

Problem description:

ESP keys are retrieved from the keymat. The direction where the keys are 
used is unclear.

For HIP keys, it is clear that the Initiator key is used by the 
Initiator for encryption. However, it seems that the interpretation for 
ESP keys is not straightforward. As the Initiator selects the SPI value 
to be used from the Receiver to the Initiator (SPI Initiator), it may be 
"logical" that the "Initiator ESP key" is used also by the Receiver to 
encrypt data that is sent to the Initiator, just like the SPI-I.

Solution that we propose (HIPL and NomadicLab)

A possible solution for clarifying the keymat usage (In chapter 9):

Rename:
"Initiator ESP encryption key" -> "SPI-I ESP encryption key"
"Initiator ESP authentication key" -> "SPI-I ESP authentication key"
"Responder ESP encryption key" -> "SPI-R ESP encryption key"
"Responder ESP authentication key" -> "SPI-R ESP authentication key"

Now, whenever the SPI-I is used, the corresponding SPI-I key is used 
(both for encryption and decryption). There should not be any 
misunderstanding after this change.

Any comments ?

/petri

---

From: [email-masked] (Andrew McGregor)
Date: Thu Oct 30 17:40:01 2003

> misunderstanding after this change.

Except that I can't easily understand your description....

How about:

> Rename:
> "Initiator ESP encryption key" -> "ESP encryption key for Initiator's 
incoming traffic (therefore also Responder's outgoing traffic)"
etc etc.

I suggest this because the SAs are what we are creating using these keys, 
and every SA uses all four keys, just in different slots.  So we should use 
the SA slots to describe the use of the keys; however, we only require to 
describe one direction, because the other is a mirror image.

Andrew

---------
Andrew McGregor
Director, Scientific Advisor
IndraNet Technologies Ltd
http://www.indranet-technologies.com/

---

From: [email-masked] (Pekka Nikander)
Date: Fri Oct 31 00:08:01 2003

> I suggest this because the SAs are what we are creating using these 
> keys, and every SA uses all four keys, just in different slots.  So we 
> should use the SA slots to describe the use of the keys; however, we 
> only require to describe one direction, because the other is a mirror 
> image.

I agree with Andrew that we (once more) must be pretty
explicit.  One possibility would be to add more text
to the ESP section, which is currently in bad shape since
I moved most of the text to the architecture draft.  For
example, there could be a subsection:

   X.1 ESP Security Associations

   Each HIP association is linked with two ESP SAs, one
   incoming and one outgoing.
   The Initiator's incoming SA corresponds with the Responder's
   outgoing one.  The initiator defines the SPI for this
   association, as defined in Section XXX.  This SA is called
   SA-I, and the corresponding SPI is called SPI-I.  Respectively,
   the responder's incoming SA corresponds with the Initiator's
   outgoing SA and is called SA-R, with the SPI-R.

   The Initiator creates SA-I as a part of R1 processing, before
   sending out the I2, as explained in Step XXX in Section XXX.
   The keys are derived from KEYMAT, as defined in Section XXX.
   The Responder creates SA-I as a part of I2 processing, see
   Section XXX.

   The Responder creates SA-R as a part of I2 processing,
   brefore sending out R2, see Step XXX in Section XXX.
   The Initator creates SA-R when processing R2, see Section XXX.

   X.2 Updating ESP SAs during rekeying

   <similar explanation as above, explaining how there are
   two SAs momentarily, spelling out when the new SAs are
   prepared and committed, and when the old ones are deleted.>

--Pekka

---

From: [email-masked] (Julien Laganier)
Date: Fri Oct 31 06:19:01 2003

> encrypt data that is sent to the Initiator, just like the SPI-I.

While it's true that the existing text is prone to different 
interpretations, I'm not sure that your proposition appears "logical" to 
me... Quoting you:

 > the "Initiator ESP key" is used also by the Receiver to

As is was unclear in the spec, I've assumed what appears "logical" to 
me: Use the ESP keys in the same way than HIP keys.

That is, the HIP initiator encryption KEY is used by the Initiator to 
_encrypt_ data sent to the Responder, so I induct that, similarly, the 
ESP initiator encryption key is used by the Initiator to encrypt data it 
sends to the Responder, which is exactly the opposite of what you've 
described ;-)

> misunderstanding after this change

It clarifies a lot of things, though I am not sure it's consistent with 
HIP keys usage.

Thanks,

--julien

---

From: [email-masked] (Pekka Nikander)
Date: Fri Oct 31 06:33:01 2003

> sends to the Responder, which is exactly the opposite of what you've 

I didn't notice that.  Sorry for my sloppiness.

I agree with you, Julien, that the keys should be used
in the same ways as HIP keys.

Therefore I would suggest that we rename the SAs and SPIs
once more:

   SA-I  => SA-RI
   SPI-I => SPI-RI
   SA-R  => SA-IR
   SPI-R => SPI-IR

This explicitly indicates the direction of the SAs, making
it unambigous.

Unless I am mistaken once more, it sounds like both HIPL
and we have to reverse key usage in our implementations.
That shouldn't be a big deal.

--Pekka

---

From: [email-masked] (Petri Jokela)
Date: Fri Oct 31 06:42:00 2003

Julien Laganier wrote:
> Petri Jokela wrote:
>  >
> 
>> ESP keys are retrieved from the keymat. The direction where the keys 
>> are used is unclear.
>>
>> Initiator for encryption. However, it seems that the interpretation 
>> for ESP keys is not straightforward. As the Initiator selects the SPI 
>> value to be used from the Receiver to the Initiator (SPI Initiator), 
>> it may be "logical" that the "Initiator ESP key" is used also by the 
>> Receiver to encrypt data that is sent to the Initiator, just like the 
>> SPI-I.
> 
> 

Yes, that would be logical when reading the key retrieving from the 
keymat. But: SPIs work the other way round, and the SPI-I (selected by 
the initiator) is used from the responder towards the initiator. Thus it 
can be thought that it is logical to use Initiator key for encrypting 
data to be sent to the Initiator, just like the SPI-I (and in that case 
we have a collision with the HIP key definition).

What is logical for one person is not logical for the other person, as 
was noticed yesterday during the interop test :-)

> It clarifies a lot of things, though I am not sure it's consistent with 

No, it's not, but by changing the naming we tried to get rid of the 
logic between the HIP and the ESP keys and tie the definition with the 
SPI selection.

It might be better to adopt the Andrew's proposal: we get rid of the 
"Initiator key" and "Responder key" names and, in fact, describe the 
actual usage of the key material. Also the ESP section modification, as 
Pekka proposed, would clarify the key usage.

/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] (Robert Moskowitz)
Date: Fri Oct 31 07:42:01 2003

>   The Responder creates SA-R as a part of I2 processing,

As good naming as anything.

BTW, we have also found it helpful to include an SA ID which is a hash of 
information within the SA.  This is valuable for SAs that don't naturally 
have SPIs.  In HIP (as in IPsec), the SPI is the SA ID...

---

From: [email-masked] (Robert Moskowitz)
Date: Fri Oct 31 07:42:04 2003

At 06:09 PM 10/30/2003, Andrew McGregor wrote:

>and every SA uses all four keys, just in different slots.  So we should 
>use the SA slots to describe the use of the keys; however, we only require 
>to describe one direction, because the other is a mirror image.

In 802.11, 802.1, and EAP-keying we are looking heavily into organizing 
everything in terms of SAs.  We have LOTS of SAs.  :)

In a new clause in 802.11 I wrote up 3 SAs (Jesse Walker 'normalized' my 
text :) ): PMKSA, PTKSA, and GTKSA.  In EAP we are doing similar work, 
setting up a separate SA for each level in the EAP keying hierarchy.

A similiar change in HIP could well help in understanding.  Something like 
INITSA and RESPSA, or just ISA and RSA  ;)

Just a quick check back here and now back to reading 180 page 802 specs for 
balloting (802.1X-REV due Nov 4th and 802.11i-D7 due Nov 9th).

---

From: [email-masked] (Petri Jokela)
Date: Fri Oct 31 07:52:00 2003

> That shouldn't be a big deal.

HIPL had it correctly (with this interpretation in mind) before 
yesterday, but they changed it according to our interpretation. It 
should not be too bad to change the order of the keys (once more ;-). 
But, anyway, it would be very convenient if everyone uses the same 
definitions :-)

If we define also the HIP keys in the same way, we would get:

9. HIP KEYMAT

...
HIP-IR encryption key for Initiator's outgoing HIP packets
HIP-IR integrity (HMAC) key for Initiator's outgoing HIP packets
HIP-RI encryption key (currently unused) for Responder's outgoing HIP 
packets
HIP-RI integrity (HMAC) key for Responder's outgoing HIP packets
SA-IR ESP encryption key for Initiator's outgoing traffic
SA-IR ESP authentication key for Initiator's outgoing traffic
SA-RI ESP encryption key for Responder's outgoing traffic
SA-RI ESP authentication key for Reponder's outgoing traffic

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.

...

and in Chapter 11:

Pekka's text (with SA-IR etc. modifications).

---

From: [email-masked] (Pekka Nikander)
Date: Fri Oct 31 08:10:01 2003

> Pekka's text (with SA-IR etc. modifications).

Looks good.

--Pekka

---

From: [email-masked] (Julien Laganier)
Date: Fri Oct 31 09:09:02 2003

> > Pekka's text (with SA-IR etc. modifications).

Fine with me too.

Thanks,

--julien