Re: [Hipsec] Proposed new list for HIP_TRANSFORM

[Robert Moskowitz <[e-mail]>]

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.