Re: [Hipsec] Comments on hiccups draft

[Jan Melen <[e-mail]>]

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.

    Jan