Re: [Hipsec] Proposed new list for HIP_TRANSFORM

[Paul Lambert <[e-mail]>]

 
Paul A. Lambert | Marvell Semiconductor | [phone]
 

> -----Original Message-----
> From: Robert Moskowitz [mailto:[e-mail]]
> Sent: Wednesday, January 06, 2010 6:23 PM
> To: Paul Lambert
> Cc: [e-mail]; HIP
> Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM
> 
> 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?

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.

> 
> > 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.
> 

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