Re: [Hipsec] Proposed new list for HIP_TRANSFORM

[Robert Moskowitz <[e-mail]>]

On 01/06/2010 04:52 PM, Miika Komu wrote:
> 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".

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!