Subject: RE: [Hipsec] changes to base spec?

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 20 May 2005 15:09:59 -0700

> > Is that okay with everybody? Thanks.
> 
> Other than the note above, looks very good to me.
> 

I also agree with the changes hashed out regarding the rendezvous case.

However, I don't sense any convergence in agreeing on the initial
proposal to include nonce in I1 and R1, now that this rendezvous
case has been defused.  It seems to me that consensus is that the
stated vulnerability is unlikely to occur (off-path attacker who
obtains correct signed parts of R1 and times the fake R1 successfully
so that it tricks the initiator to solve the wrong puzzle).

Regarding the other changes proposed in the paper:

2- I do not think it is burdensome to retain I and J for this purpose,
so I would agree with the proposal

3,4,5-  These are all related to the puzzle implementation.  Perhaps
we could put the proposed puzzle mechanism into the appendix and
reference the paper?  (5 would require some change in section 4.1.1
and appendix C)

6- I don't object to this proposed change (reveal HI in I2)-- I don't
know the original requirement for this encryption, and the paper
points out that it seems to be flawed.

7a)- Let me respond to this in a separate post.

7b),7c),8- These are all related to achieving consistency in 
Initiator/Responder roles when I1s or I2s collide, and seem OK
to me.

Tom

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 24 May 2005 15:00:49 +0300

> so that it tricks the initiator to solve the wrong puzzle).

I agree.  OTOH, I don't see much harm in allowing (MAY) the Initiator
to include an ECHO_REQUEST in I1, with the provisioning that the
Responder is recommended (SHOULD) to reply with an ECHO_RESPONSE.
Furthermore, if the Initiator does implement this option, it MUST
be prepared for the case that the Responder does not reply with a
ECHO_RESPONSE.

The only problem with this is that it adds complexity and optional
behaviour, though in a fairly mild manner, IMHO.  That is, most of
the complexity is carried by the Initiator implementing this; at
the Responder end implementing the SHOULD is fairly simple.

> so I would agree with the proposal

Fine with me.

> reference the paper?  (5 would require some change in section 4.1.1

Fine wiht me.

> points out that it seems to be flawed.

I think we could easily allow both, i.e., both encrypted and unencrypted
initiator HI.  Then the question boils down to which should be the
preferred (MUST implement) style, which optional (MAY/SHOULD).

> Initiator/Responder roles when I1s or I2s collide, and seem OK

I don't remember the details of these any more, but my vague
recollection was that some of them may not be a problem as the
HITs identify the context.  However, I may be very wrong here.

--Pekka