Re: [Hipsec] Comments on hiccups draft

[Jan Melen <[e-mail]>]

Hi Tobias,

Jan Melen wrote:
> Tobias Heer wrote:
>>
>> Am 28.07.2009 um 17:10 schrieb Jan Melen:
>>
>>> Hi Tobias,
>>>
>>> Tobias Heer wrote:
>>>> Am 28.07.2009 um 16:30 schrieb Jan Melen:
>>>>
>>>>>> Section 3: Existence of the HMAC in the packet:
>>>>>> The hiccups draft states that "[the payload is] protected by a 
>>>>>> PAYLOAD_HMAC parameter". To me it is unclear how such protection 
>>>>>> can possibly work. Since there is no previous handshake there are 
>>>>>> no keys for use in the HMAC. Jan explained that the HMAC is 
>>>>>> merely used as a way to create a digest over the packet for 
>>>>>> making the signature more efficient. However, if it is only used 
>>>>>> for creating the digest, I wonder why it is actually transmitted 
>>>>>> in the packet because without a secret included in the packet, 
>>>>>> the digest can easily be calculated and transmitting the digest 
>>>>>> in a packet seems to be a unnecessary waste of space. Am I 
>>>>>> missing something here? It would be nice if the draft was more 
>>>>>> precise about the nature and the use of the HMAC.
>>>>>>
>>>>>
>>>>> if you do send it as the receiving end doesn't have to generate 
>>>>> the actual parameter that was used to create MAC code in order to 
>>>>> verify the signature.
>>>>
>>>> You must recalculate the digest anyway. Otherwise the receiver will 
>>>> only check that the signature covers the HMAC but the receiver will 
>>>> not check that the packet contents match the HMAC. In that sense 
>>>> only the HMAC but not the packet contents would be 
>>>> integrity-protected. Since you have to generate the digest over the 
>>>> whole packet anew anyway I do not see the advantage of sending it 
>>>> in the packet.
>>>
>>> Yes you have to calculate it in either case I'm not referring to 
>>> that. I'm just saying that the implementation will be more error 
>>> prone if the host has to calculate the digest and then create the 
>>> parameter. And we send the parameter in the packet the receiver can 
>>> already after calculating the digest drop packets which have been 
>>> modified on the transmit without calculating the signature (the 
>>> non-malicious errors that happen on transmit).
>>
>> Now everything becomes a bit clearer. Since you do not expect to have 
>> a UDP header (with checksum) in all cases you use the HMAC as 
>> checksum? That works... Although a 20-byte checksum from a 
>> cryptographic hash function is rather large and expensive (compared 
>> to the usual transport-layer checksums TCP/UDP: 2 byte). Maybe this 
>> (non-standard?) use of the HMAC could be stated in the draft to avoid 
>> confusion.
>
> The upper-layer protocol might have it's own checksum but I do not 
> want to make a dependency to HIP protocol that a HIP implementation 
> should be able to identify all transport protocols thus it is easier 
> to define that HIP_DATA has some checksum calculation that is less 
> expensive than public key signature but still provides something for 
> the end goal. After all the if the packet would be IP (HIP(HIP_DATA, 
> HIP_SIGNATURE) UDP ()), the processing in the stack would go in the 
> following order:
> 1. IP stack processes the IP header
> 2. HIP processes the HIP header, HIP_DATA and HIP_SIGNATURE
> 3. Transport layer UDP processes the UDP header
> 4. Application
>
> If we wouldn't make this check on step 2 we might do the signature 
> calculation just to notice that the packet has been accidentally 
> modified in transit.
>
> But anyway I will add something to the draft.
>

http://users.piuha.net/jmelen/HICCUPS/draft-nikander-hip-hiccups-04-pre1.txt
I've now made yet another edit on the draft regarding the comment you 
gave. Take now a look at section 3 paragraph 4.

   Jan