[Hipsec] CLOSE and identical session keys

[Tobias Heer <[e-mail]>]

Hello Tom,

Am 19.10.2010 um 16:55 schrieb Henderson, Thomas R:

> 
> 
>> -----Original Message-----
>> From: Tobias Heer [mailto:[e-mail]]
>> Sent: Tuesday, October 19, 2010 7:25 AM
>> To: Henderson, Thomas R
>> Cc: HIP WG
>> Subject: Re: [Hipsec] Completing 5201 state machine
>> 
>> Hi Tom,
>> 
>> thanks for the clarification.
>> 
>> Am 19.10.2010 um 16:04 schrieb Henderson, Thomas R:
>> 
>> [...]
>>>>> 
>>>>> OpenHIP allows CLOSE in states ESTABLISHED, CLOSING,
>>>> CLOSED, and R2_SENT, but does not process it in this state.
>>>>> 
>>> 
>>> <snip>
>>> 
>>>> 
>>>> Above you said that OpenHIP wouldn't process CLOSE messages
>>>> in state R2_SENT. What do you mean by that? Isn't sending a
>>>> CLOSE_ACK (as you mention for 2.) such processing? Am I
>>>> confusing something here?
>>>> 
>>> 
>>> Sorry for not being clear; the "this state" in the above
>> explanation refers to state I2-sent, not R2-sent.
>>> 
>> What is your opinion on processing CLOSE messages in state
>> I2-sent? Do you have reasons why you don't process it in that state?
>> 
> 
> I can't recall exactly the reason for this decision, but another possible scenario:
> 
> 1.) remote host sends CLOSE
> 2.) local host sends CLOSE_ACK, moves to CLOSED.  CLOSE_ACK lost
> 3.) local host tries to immediately set up the session again, sends I1, receives (stateless) R1
> 4.) local host sends I2.  Meanwhile, remote host is still in CLOSING state until it gets I2, which it accepts and moves back to R2-sent.  Here it it more helpful for the local host to just ignore the (stale) CLOSE from the past asso

In my opinion it is unlikely that the Initiator confuses the old CLOSE with a new close for the newly established association because it is protected with an HMAC that depends on the DH and puzzle used in the handshake.
Hence, processing of the CLOSE packet will only be successful if the R1 counter has not advanced and the puzzle solution was identical. However, the suggestion for generating new puzzles is "once every few minutes" so identical session keys could actually be the case and it is not so unlikely at all. 

It might make sense to be able to detect replayed and old CLOSE packets reliably to avoid vulnerabilities for hosts that set up and close connections rapidly. Such detection should probably happen via the HMAC/shared key. Hence, the key generation should be different. The best option for varying keys would be the puzzle.

My suggestion would be:

a) add a recommendation that a host SHOULD to not send the same puzzle to a host twice. A host can use the opaque field in the puzzle to generate unique puzzle parameters (e.g., by using a counter as input for the generation of I and by using the opaque field in the puzzle to remember it).

or

b) add MUST to use different puzzles. This may be a bit more costly because a host could deprive the puzzles that can be indexed with the opaque field with 2^16 I1 packets. In that case the responder would have to increase the R1 generation counter (and would possibly generate new DH keys and signatures for these).

Any opinions?

Tobias





> ciation
> 
> Again, this is somewhat of a contrived scenario.  I am fairly neutral as to how to handle this since these seem to be unlikely scenarios, and would be willing to adopt your suggestion.
> 
> - Tom




-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: [phone]
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi