[Hipsec] Fwd: Proposed new list for HIP_TRANSFORM

Anfang der weitergeleiteten E-Mail:

> Von: Tobias Heer <heer@cs.rwth-aachen.de>
> Datum: 7. Januar 2010 16:04:06 MEZ
> An: Robert Moskowitz <rgm@htt-consult.com>
> Kopie: hip WG <hipsec@ietf.org>
> Betreff: Re: [Hipsec] Proposed new list for HIP_TRANSFORM
> 
> 
> Am 07.01.2010 um 13:59 schrieb Robert Moskowitz:
> 
>> On 01/07/2010 06:58 AM, Tobias Heer wrote:
>>> Am 07.01.2010 um 04:22 schrieb Andrew McGregor:
>>> 
>>> 
>>>> On 07/01/2010, at 7:01 AM, 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-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?
>>>>> 
>>>> No!  We need more suite IDs for the key sizes we're going to use.
>>>> 
>>>> The whole point of using suites in the first place was, once you have the suite you know everything you need to know about the crypto setup... you can literally just use the suite-id as an index into a table of all the numbers.
>>>> 
>>>> 
>>> I agree. I think we should also tie the MAC Algorithm for the HIP control packets to the transform to avoid a separate negotiation. Or can you imagine a case in which the ESP MAC algorithm and the HIP control channel MAC algorithm should differ?
>> 
>> The HIP control packet MAC algorithm is still HMAC, and it will use the HIH as the underlying hash.  There are HIP_TRANSFORMS that do not have a separate MAC, like CCM.
>> 
> 
> Is it really wise to use the HIH instead of the ESP transform to determine the HIP control packet HMAC hash algorithm? In my opinion, the MAC algorithm from the ESP transform has more in common with the control packet HMAC than the HIH. The HIH is for generating an identity tag and the two other MACs are for integrity protection of packets. Of course, both algorithms need to be supported by both hosts but I can imagine that hosts might want to use stronger and more costly hash functions for generating their identity than they would use for integrity protection. In this regard, the security requirements for control channel hash algorithm are more similar to the ESP HMAC.
> 

I see your point that some transforms don't use a hash function that can be used in an HMAC. If we want to use HMAC for the control channel whose HIH should we use? Initiator or responder? Is it an option to use the same MAC (be it CCM, GCM, HMAC, ...) for the data and control channel? 

Tobias
> 
> 
> 
> --  
> 
> Dipl.-Inform. Tobias Heer, Ph.D. Student
> Distributed Systems Group 
> RWTH Aachen University, Germany
> tel: +49 241 80 207 76
> web: http://ds.cs.rwth-aachen.de/members/heer
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec

--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer