Re: [Hipsec] Proposed new list for HIP_TRANSFORM

[Robert Moskowitz <[e-mail]>]

On 01/06/2010 08:37 PM, Paul Lambert wrote:
>
>    
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Robert Moskowitz
>> Sent: Wednesday, January 06, 2010 2:31 PM
>> To: [e-mail]
>> Cc: HIP
>> Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM
>>
>> 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!
>>      
>
> 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.