Re: [Hipsec] CLOSE and identical session keys

["Henderson, Thomas R" <[e-mail]>]

> -----Original Message-----
> From: Tobias Heer [mailto:[e-mail]]
> Sent: Tuesday, October 19, 2010 10:05 AM
> To: Henderson, Thomas R
> Cc: HIP WG
> Subject: CLOSE and identical session keys
>
> 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?
>

I had some similar thoughts when originally replying (about the possible need to detect replayed CLOSE packets) and of the two choices above, I would probably favor a).

- Tom