Subject: [Hipsec] Proposed new list for HIP_TRANSFORM

From: Robert Moskowitz <[email-masked]>
Date: Tue, 05 Jan 2010 23:08:05 -0500

Proposed new list for HIP_TRANSFORM:

          Suite ID                          Value

          RESERVED                          0
          AES-CBC with HMAC-SHA1            1     ([RFC3602], [RFC2404])
          3DES-CBC with HMAC-SHA1           2     ([RFC2451], [RFC2404])
          DEPRECATED                        3
          BLOWFISH-CBC with HMAC-SHA1       4     ([RFC2451], [RFC2404])
          NULL-ENCRYPT with HMAC-SHA1       5     ([RFC2410], [RFC2404])
          DEPRECATED                        6
          NULL-ENCRYPT with HMAC-SHA2       7     ([RFC2410], [RFC4868])
          AES-CBC with HMAC-SHA2            8     ([RFC3602], [RFC4868])
          AES-CCM-8                         9     [RFC4309]
          AES-CCM-12                        10    [RFC4309]
          AES-CCM-16                        11    [RFC4309]
          AES-GCM with a 8 octet ICV        12    [RFC4106]
          AES-GCM with a 12 octet ICV       13    [RFC4106]
          AES-GCM with a 16 octet ICV       14    [RFC4106]

---

From: Miika Komu <[email-masked]>
Date: Wed, 06 Jan 2010 19:07:42 +0200

Robert Moskowitz wrote:

Hi,

>          AES-GCM with a 16 octet ICV       14    [RFC4106]

seems fine with me. Should the "natural" key size be reflected in some 
of the algorithms descriptions?

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 06 Jan 2010 12:36:21 -0500

> of the algorithms descriptions?

I am not sure what you are alluding to here.  Key sizes for AES-based 
transforms start at 128 and go up.  If you are asking about those 
8/12/16 sizes in CCM and GCM, that applies to the auth size.

---

From: Miika Komu <[email-masked]>
Date: Wed, 06 Jan 2010 20:01:58 +0200

Robert Moskowitz wrote:

Hi,

> 8/12/16 sizes in CCM and GCM, that applies to the auth size.

do we have to negotiate AES key size?

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 06 Jan 2010 13:19:00 -0500

On 01/06/2010 01:01 PM, Miika Komu wrote:
>>> seems fine with me. Should the "natural" key size be reflected in 
>>> some of the algorithms descriptions?
>>

OOPS.  Good catch.  We want to make sure we have Suite B support...

Trying to dig around, how is it handled elsewhere, an ISAKMP keysize TLV 
for IKE and ESP?

I have some thoughts for a simple way here...

---

From: Miika Komu <[email-masked]>
Date: Wed, 06 Jan 2010 22:37:27 +0100

Robert Moskowitz wrote:

Hi,

> I have some thoughts for a simple way here...

either we fix the key size in the suite id or we negotiate it as 
max(key-size-in-r1, key-size-in-i2).

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 06 Jan 2010 16:50:32 -0500

On 01/06/2010 04:37 PM, Miika Komu wrote:
>>>> I am not sure what you are alluding to here.  Key sizes for 
>>>> AES-based transforms start at 128 and go up.  If you are asking 
>>>> about those 8/12/16 sizes in CCM and GCM, that applies to the auth 
>>>> size.
>>>
>> Trying to dig around, how is it handled elsewhere, an ISAKMP keysize 
>> TLV for IKE and ESP?
>>

So we either add a KEYSIZE parameter or change the HIP_TRANSFORM 
parameter to include a key size.  Any why the max of the two?  Rather 
the max in common.  Say R1 has 128, 192, 256 and I2 has 128 and 192.  
Thus the agreed keysize is 192, not 256.

---

From: Miika Komu <[email-masked]>
Date: Wed, 06 Jan 2010 22:52:29 +0100

Robert Moskowitz wrote:

Hi,

> Thus the agreed keysize is 192, not 256.

it could be also "initiator chooses".

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 06 Jan 2010 17:30:48 -0500

On 01/06/2010 04:52 PM, Miika Komu wrote:
>>>>>>> seems fine with me. Should the "natural" key size be reflected 
>>>>>>> in some of the algorithms descriptions?
>>>>>>
>>>>>> about those 8/12/16 sizes in CCM and GCM, that applies to the 
>>>>>> auth size.
>>>>>
>>>> Trying to dig around, how is it handled elsewhere, an ISAKMP 
>>>> keysize TLV for IKE and ESP?
>>>>

that makes the R1 key sizes being the offer, and I2 being the 
selection.  I don't have a problem with that.

Now is there any changes to any of the transforms based on the keysize?  
I hope not!

---

From: Paul Lambert <[email-masked]>
Date: Wed, 6 Jan 2010 17:37:02 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Robert Moskowitz
> Sent: Wednesday, January 06, 2010 2:31 PM
> To: [email-masked]
> Cc: HIP
> Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM
> 

The encryption key size should be part of the transform name .....

Also ... why so many algorithms?  Choices for similar algorithms are not necessary a good idea.  GCm is a little tricky and the max instantiations vary based on the ICV size ...

Paul

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

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 06 Jan 2010 21:22:32 -0500

> The encryption key size should be part of the transform name .....

Can you please expand on this?  Why is it better to have a different 
transform for each allowed key size?

> Also ... why so many algorithms?

So that someone with more knowledge about the various algorithms can 
pipe up and advise us!

Also depending on underlying MACsec, one algorithm might be perferred 
over another.  CCM is in 802.11, 15, and 16.  GCM is in 802.1AE for 
802.3 usage.  A device with a particular MAC may perfer that algorithm.

>    Choices for similar algorithms are not necessary a good idea.  GCm is a little tricky and the max instantiations vary based on the ICV size ...
>    

So only devices that have it already for the MAC might be using it?  I 
would like to see only one CCM and one GCM, but I don't know what has 
actually been fielded for say 15.4 or .3ah.

I went for a more 'complete' list for starters.

---

From: Paul Lambert <[email-masked]>
Date: Wed, 6 Jan 2010 19:08:34 -0800

Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141

> From: Robert Moskowitz [mailto:[email-masked]]
> Sent: Wednesday, January 06, 2010 6:23 PM
> To: Paul Lambert
> Cc: [email-masked]; HIP

The set of selected parameters for a "cryptographic transformation" may include: encryption algorithm, encryption algorithm key size, integrity algorithm, integrity key size, ICV size, padding approach, and potentiall other parameters (e.g. M and L value in CCM).  The usage considerations for a transform vary considerably based on these choices.  For example the ICV length in GCM has subtle implications on rekey counters.  It's really much better to have less knobs on the configuration and more clearly define the few modes that will actually be used.  Otherwise, you get significant complexity in implementations attempt to test and validate the combinations.  

So each named cipher suite should fully define one transform including the key sizes.

> >    Choices for similar algorithms are not necessary a good idea.  GCm is
> a little tricky and the max instantiations vary based on the ICV size ...
> >
> 

One version of GCM matching 802.1ae and one CCM matching IPsec (and .11) would be reasonable.  Dump 3DES and Blowfish.  Replace HMAC SHAx with CMAC.

Better to have just a few algorithms than to attempt and collect every known combination.  If successful ... interested parties can add more later.

Paul

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 7 Jan 2010 16:22:10 +1300

On 07/01/2010, at 7:01 AM, Miika Komu wrote:

>>> seems fine with me. Should the "natural" key size be reflected in some of the algorithms descriptions?
>> I am not sure what you are alluding to here.  Key sizes for AES-based transforms start at 128 and go up.  If you are asking about those 8/12/16 sizes in CCM and GCM, that applies to the auth size.
> 

No!  We need more suite IDs for the key sizes we're going to use.

The whole point of using suites in the first place was, once you have the suite you know everything you need to know about the crypto setup... you can literally just use the suite-id as an index into a table of all the numbers.

Andrew

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 06 Jan 2010 22:26:59 -0500

> No!  We need more suite IDs for the key sizes we're going to use.

I thank Paul and Andrew for jumping in and giving some good feedback.

So 128 and 256?  Skip 192?

---

From: Tobias Heer <[email-masked]>
Date: Thu, 07 Jan 2010 12:58:02 +0100

>>>>> Proposed new list for HIP_TRANSFORM:

...

> The whole point of using suites in the first place was, once you have the suite you know everything you need to know about the crypto setup... you can literally just use the suite-id as an index in…

I agree. I think we should also tie the MAC Algorithm for the HIP control packets to the transform to avoid a separate negotiation. Or can you imagine a case in which the ESP MAC algorithm and the HIP control channel MAC algorithm should differ?

Tobias

--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 07 Jan 2010 07:59:53 -0500

> I agree. I think we should also tie the MAC Algorithm for the HIP control packets to the transform to avoid a separate negotiation. Or can you imagine a case in which the ESP MAC algorithm and the…

The HIP control packet MAC algorithm is still HMAC, and it will use the 
HIH as the underlying hash.  There are HIP_TRANSFORMS that do not have a 
separate MAC, like CCM.

 From what I have read on the CFRG list, HMAC is sound and given all the 
things we do with it, it is OK to just use it where it makes sense.

Now maybe I have been reading too much on too little sleep and have a 
few things twisted, but I don't think so.  I will try and work up a new 
HIP_TRANSFORM list today, but I will be challenged to find the 
information on which size ICV to use for CCM and GCM.

---

From: Tobias Heer <[email-masked]>
Date: Thu, 07 Jan 2010 16:04:06 +0100

Am 07.01.2010 um 13:59 schrieb Robert Moskowitz:

> The HIP control packet MAC algorithm is still HMAC, and it will use the HIH as the underlying hash.  There are HIP_TRANSFORMS that do not have a separate MAC, like CCM.
> 

Is it really wise to use the HIH instead of the ESP transform to determine the HIP control packet HMAC hash algorithm? In my opinion, the MAC algorithm from the ESP transform has more in common with the control packet HMAC than the HIH. The HIH is for generating an identity tag and the two other MACs are for integrity protection of packets. Of course, both algorithms need to be supported by both hosts but I can imagine that hosts might want to use stronger and more costly hash functions for generating their identity than they would use for integrity protection. In this regard, the security requirements for control channel hash algorithm are more similar to the ESP HMAC.

Tobias

--

---

From: Tobias Heer <[email-masked]>
Date: Fri, 08 Jan 2010 21:16:02 +0100

Anfang der weitergeleiteten E-Mail:

> Von: Tobias Heer <[email-masked]>
> Datum: 7. Januar 2010 16:04:06 MEZ
> An: Robert Moskowitz <[email-masked]>
> Kopie: hip WG <[email-masked]>
> Betreff: Re: [Hipsec] Proposed new list for HIP_TRANSFORM
> 
> 

I see your point that some transforms don't use a hash function that can be used in an HMAC. If we want to use HMAC for the control channel whose HIH should we use? Initiator or responder? Is it an option to use the same MAC (be it CCM, GCM, HMAC, ...) for the data and control channel? 

Tobias

--