Subject: [Hipsec] ENCRYPTED parameter when HIP_Transform is Duo mode

From: Robert Moskowitz <[email-masked]>
Date: Tue, 27 Apr 2010 09:50:15 -0400

One of the many differences between HIP and IKE is that IKE negotiates 
TWO encryption suites.  One for IKE to use itself, and one for the data 
transport.  HIP only negotiates a single encryption suite and uses it 
for both.

This was fine with AES modes of operation like CBC, but presents 
interesting challenges with the AES duo modes of operation.

In 5201-bis we are adding both CCM and GCM (RFCs 4309 & 4106).  Both 
define an ICV and use an AAD.  What would the AAD be in the HIP payload 
and what to do with the ICV?  If for the ICV is to drop it on 
encryption, what impact does this have on decryption?  What security 
risks are there to use CCM or GCM for  the ENCRYPTED parameter?  Will we 
need to add a separate transform negotiation for this parameter?

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Tue, 27 Apr 2010 07:24:12 -0700

> One of the many differences between HIP and IKE is that IKE 
> negotiates TWO encryption suites.  One for IKE to use itself,
> and one for the data transport.  HIP only negotiates a single
> encryption suite and uses it for both.

No, with HIP one can negotiate HIP_TRANSFORM and ESP_TRANSFORM as different suites, one for HIP itself and one for data.

-Jeff

> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 27 Apr 2010 10:49:44 -0400

OOPS!!!

> No, with HIP one can negotiate HIP_TRANSFORM and ESP_TRANSFORM as different suites, one for HIP itself and one for data.

Oh, that is in 5202, and I am only looking at 5201....

But this then 'begs the question' about modes.

Duo modes are not needed for HIP_TRANSFORM, but are of value for 
ESP_TRANSFORM.

Values are only defined for HIP_TRANSFORM, ASSUMING that what works for 
one works for the other.  This is no longer the case, so do we define 
the CCM and GCM transforms in 5202-bis?  And for the HIP Suites, we need 
to define which ESP_TRANSFORM to which suite also in 5202-bis?

thanks for setting me straight there Jeff, I have been staring at 5201 
for too long...

>> In 5201-bis we are adding both CCM and GCM (RFCs 4309&  4106).  Both

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Tue, 27 Apr 2010 08:36:48 -0700

> to define which ESP_TRANSFORM to which suite also in 5202-bis?

Yes it seems like 5202-bis now requires its own list of suite IDs (including CCM and GCM) instead of just referring to 5201.

Will the limit of 6 suite IDs in the ESP_TRANSFORM be enough?

> thanks for setting me straight there Jeff, I have been 
> staring at 5201 for too long...

np, you're doing good work :)

-Jeff

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 27 Apr 2010 11:53:53 -0400

> Will the limit of 6 suite IDs in the ESP_TRANSFORM be enough?

With the focus on HIP Suites, it will be.  Developers will tend to 
'group' like strengthed things together, and not just list everything.

Though I do remember early in the ICSAlabs testing of IPsec products we 
had one that ALWAYS put out (I Think) 12 proposals and crashed a lot of 
other products.  It became a stable in our testbed.  So since 6 are 
allowed for HIP and ESP transform, make sure you test with 6 and don't 
crash...