Re: [Hipsec] Proposed new list for HIP_TRANSFORM

[Miika Komu <[e-mail]>]

Robert Moskowitz wrote:

Hi,

> On 01/06/2010 04:37 PM, Miika Komu wrote:
>> Robert Moskowitz wrote:
>>
>> Hi,
>>
>>> On 01/06/2010 01:01 PM, Miika Komu wrote:
>>>> Robert Moskowitz wrote:
>>>>
>>>> Hi,
>>>>
>>>>> On 01/06/2010 12:07 PM, Miika Komu wrote:
>>>>>> Robert Moskowitz wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> 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]
>>>>>>
>>>>>> 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.
>>>>
>>>> do we have to negotiate AES key size?
>>>
>>> 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...
>>
>> either we fix the key size in the suite id or we negotiate it as 
>> max(key-size-in-r1, key-size-in-i2).
> 
> 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.

it could be also "initiator chooses".