Re: [Hipsec] Host ID question

[Tobias Heer <[e-mail]>]

Am 18.04.2010 um 23:56 schrieb Robert Moskowitz:

> On 04/18/2010 11:33 AM, Tobias Heer wrote:
>> Hi,
>> 
>> Am 16.04.2010 um 23:02 schrieb Robert Moskowitz:
>> 
>>   
>>> On 04/16/2010 09:31 AM, Miika Komu wrote:
>>>     
>>>> On 15/04/10 23:55, Robert Moskowitz wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> maybe understood the intent of the question incorrectly, but here goes nothing..
>>>> 
>>>>       
>>>>> Why did we specify RSA/SHA1 for a Host ID value in 5201?
>>>>>         
>>>> RSA does not have any patents and it was interoperated successfully.
>>>> 
>>>>       
>>>>> Why the inclusion of SHA1?
>>>>>         
>>>> Well supported everywhere and it was interoperated successfully.
>>>>       
>>> I have looked at the offending RFC: 3110 and see that there are TWO RR defined there.  One for RSA keys one for RSA/SHA1 sig RR.  And our format is the former, not the latter, so IMNSHO we made an error to call this RSA/SHA1 and it should have just been RSA.  Afterall, there is nothing hash related in HIPv1 Host-IDs.
>>> 
>>>     
>> If I am not completely mistaken the inclusion of SHA in RSA/SHA1 is to align it to DSA. DSA specifically specifies SHA-1 as hash function to compress the input before applying the costly PK signature scheme. RSA does not have such dependency to a hash function by default. Anyway, you want to compress your input before feeding it to RSA. Hence the combination of both.
>> 
>> IMHO it is good to have RSA/SHA1 as bundle here.... but I may be wrong, of course.
>>   
> 
> This applies to Host_ID, which the TLV mimes just the RSA RR, not the RSA/SHA1 RR; at least as I look at the RFCs.
> 
> Then IF it really IS RSA/SHA1, we would need a Host_ID for EACH hash with RSA, when we will be adding a separate TLV for hash....
> 
> 
I did not full get your point but I will try to answer nonetheless - so I may be wrong or I might even answer the wrong question.

I think the concept of HIP suites covers the issue quite well. We can define combinations of hash functions and signature schemes that make sense or that enable the use of HIP for a special purpose. These suites ca bundle a set of roughly equivalent hash functions and signature schemes - the actual choice of hash function and signature scheme can be communicated during the BEX or the update (for on-path elements). We do not have parameters for conveying that choice yet but as long as it is granted that a host can pick the right suite, the actual algorithms are negotiable.

BR, 

Tobias



> 
>> Tobias
>> 
>> 
>> 
>> 
>> --
>> 
>> Dipl.-Inform. Tobias Heer, Ph.D. Student
>> Distributed Systems Group
>> RWTH Aachen University, Germany
>> tel: [phone]
>> web: http://ds.cs.rwth-aachen.de/members/heer
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>   




--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: [phone]
web: http://ds.cs.rwth-aachen.de/members/heer