Re: [Hipsec] Proposed new list for HIP_TRANSFORM

> -----Original Message-----
> From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On Behalf
> Of Robert Moskowitz
> Sent: Wednesday, January 06, 2010 2:31 PM
> To: miika.komu@hiit.fi
> 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 .....

Also ... why so many algorithms?  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 ...

Paul

> 
> 
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec