RE: Do ipsec vendors care about privacy?

[Hugo Krawczyk <hugo@ee.technion.ac.il>]

Someone asked me (off list) why i did not include the issue of protecting
the user's identity (in the remote access scenario) in my list of
yet-to-be done issues that I sent earlier to Charlie.

I have two answers:

(1) I only included in that list issues that were previously discussed and
we reached agreement (or close to agreement) with Charlie.  Identity
protection for the user (initiator) in the EAP exchange was never agreed
by Charlie (he only said that he felt "genuinely conflicted about this one").

(2) From the latest thread on this issue (under the above subject) 
it was clear that very few explicitly supported doing the changes required
to provide user identity in the case of remote access, even though the
cost of these changes was very moderate (*) and affected only the EAP
exchange of ikev2 (without any modification required to the normal
authentication modes).

While this result disappoints me it seems to clearly reflect the desire of
this WG (as much as any discussion in this list can reflect such virtual
desire). And since I directed this thread particularly to ipsec vendors I
guess this outcome of the discussion is acceptable to them (several of
these vendors said that user's identity protection in the remote access
scenario is important to them, but no one really said it was important
enough to justify even the small complexity these changes required).

Hugo

*) about moderate cost: we had two main solutions (that only changed the
   EAP exchange of ikev2)

- leave everything as now and move IDi to message 5.
  Here the cost is an added round trip since the responder will
  not have the user's identity until message 5.

- move the responder's authentication to message 2.
  Here the cost is the loss of the "You Tarzan, Me Jane" functionality,
  some increased implementation complexity (by deviating from the order
  of authentication in the main ikev2 protocol, and by requiring a signature 
  on parts -rather than all- of message 2). It has also been argued that
  this ordering increases the exposure to DoS attacks (due to the signature
  performed by R in message 2); this does not convince me especially that
  in the current protocol one can already mount serious DoS attacks
  against an ike server, especially via DDoS (which is the "preferred" 
  form for attackers to avoid traceability -- and against which even 
  the anti-DoS cookie has very limited effect). In other words,
  the added signature computation makes DoS attack not significantly more
  attractive or effective than they already are (note also that state
  creation and expensive DH computation are already forced in the protocol
  on the responder before it authenticates the initiator).