Subject: [Hipsec] (no subject)

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 19 Oct 2010 07:55:41 -0700

> -----Original Message-----
> From: Tobias Heer [mailto:[email-masked]]
> 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 association

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

---

From: Tobias Heer <[email-masked]>
Date: Tue, 19 Oct 2010 19:04:53 +0200

Hello Tom,

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

> 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

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

---

From: Miika Komu <[email-masked]>
Date: Wed, 20 Oct 2010 12:20:44 +0300

Hi,

> 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 respond…

+1 for (a)

---

From: René Hummen <[email-masked]>
Date: Wed, 20 Oct 2010 11:36:15 +0200

>> 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 respon…

+1 for (a) from me as well.

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 20772
web: http://ds.rwth-aachen.de/members/hummen

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 20 Oct 2010 08:16:54 -0700

> Sent: Tuesday, October 19, 2010 10:05 AM
> To: Henderson, Thomas R
> Cc: HIP WG
> Subject: CLOSE and identical session keys
>
> Hello Tom,
>
> > 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

---

From: Tobias Heer <[email-masked]>
Date: Wed, 20 Oct 2010 21:22:32 +0200

Hello Tom (and everyone else involved),

> 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).

My suggestion for the new passage for RFC5201-bis:

   The puzzle value I and the solution J are inputs for deriving the
   keying material from the Diffie Hellman key exchange (Section 6.5).
   Therefore, a responder SHOULD NOT use the same puzzle I with the same
   DH keys for the same Initiator twice to ensure that the derived
   keying material differs.  Such uniqueness can be achieved, for
   example, by using a counter as input for generating I. This counter
   can be increased for each processed I1 packet.  The state of the
   counter can be transmitted in the Opaque data field in the PUZZLE
   (Section 5.2.4), in an ECHO_REQUEST_SIGNED (Section 5.2.19) or in an
   ECHO_REQUEST_UNSIGNED parameter (Section 5.2.20) without the need to
   establish state.

Any comments / suggestions?

However, with this passage some other text on the puzzle requires minor changes and clarifications as well.

BR,

Tobias

---

From: Ari Keranen <[email-masked]>
Date: Thu, 21 Oct 2010 16:22:00 +0300

> Any comments / suggestions?

Looks good to me.

Cheers,
Ari