Re: Do ipsec vendors care about privacy?

[Tero Kivinen <kivinen@iki.fi>]

hugo@ee.technion.ac.il (Hugo Krawczyk) writes:
> I agree: no time for major surgery on the document.
> But not too late for a change that takes 1-5 minutes editorial work

All the proposal I have seen sent to the list are might be 1-5 minutes
editorial work, but the problem is that they also cause effects to the
other parts of the document, which means that much more analysis of
the actual effect of the change. I.e they actually ARE MAJOR SURGERY.

Lets analyze some of the proposal:

1) Leave out the IDi in the message 2 and move it later.

	- The current EAP mode assumes (and most of the
          implementations do require) that it has user's identity to
          before the EAP start. I.e the current text says that we are
          not supposed to use EAP(identity request / replies), as we
          can get the same information from the ID payload already.
          This adds one more round trip to the exchange.

	- The text currently says that if the EAP method creates
          shared key it MUST be used to generate the AUTH payloads
          using the shared secret method by both ends. If we move the
          AUTH payload to point before the EAP finishes (or actually
          before it starts), then we have to change this. I do not
          know the actual effects of this change. 

2) Move the authentication of the server to message 2.

	- This open one more DoS attack. The responder must sign the
          auth message before it actually knows if there is anybody
          there on the other end. Currently the resourses used from
          the responder for the first packet is very cheap (policy
          lookup, take precalculated Diffie-Hellman (or reuse old
          one), make some state, and send packet). In this model we
          would need to add do RSA/DSA sign operation during that,
          which is much more expensive operations than any of the
          above. That would most likely mean that the responder would
          always require the return routability check before doing
          anything, having an effect that we added one more round
          trip to the exchange in normal case.

	- Also the generation of the signature is little bit harder,
          as we are signing the packet we are also adding the
          signature to.

	- Also in that case we loose the "You Tarzan, Me Jane" for
          those cases, because the responder needs to sign the
          identity it is using in the packet 2, and the initiator is
          sending the preferred ID to be used in packet 3.

	- Then again, how does the server know when to do this,
          because it hasn't yet seen that the other end wants to do
          EAP. So we either need to add it to the SA payloads, or do
          it always. 

3) Move the server AUTH to place before the EAP has finished.

	- The text currently says that if the EAP method creates
          shared key it MUST be used to generate the AUTH payloads
          using the shared secret method by both ends. If we move the
          AUTH payload to point before the EAP finishes (or actually
          before it starts), then we have to change this. I do not
          know the actual effects of this change. 

4) Authenticate the responder first before initiator

	- All of these cases makes it easy to make polling attack, i.e
          I start process in the IETF and start IKE negotiation
          against each IP address. The responder will be very helpfull
          and send me proof who they actually are. Currently there is
          no way to get that information, I only can get the IP
          address, I do not know to whom which ip address is assigned
          to. Remember that IPsec is actually symmetric, thus the
          original initiator can be responder later.

> On the other hand, user's id protection in the remote access protocol of
> ikev2 IS A NATURAL REQUIREMENT according to anything I heard from ipsec
> developers (on the list and outside the list). So giving the opprtunity to
> this substantial improvement if it comes at little cost and on time is a
> reasonable thing to do. 

If you need it you can already do it know, by using the ID_KEY_ID, i.e
simply send random string to the other end as ID_KEY_ID, and made it
so that the server can then find map that to your identity, and update
it to be something different after you have authenticated
successfully. 

> In any case, ,I raised the issue and two possible solutions, but I am not
> the one that needs to decide if the WG is to adopt this or not. THOSE THAT
> CARE (in one way or another) SHOULD SPEAK UP.

I am strongly AGAINST this modification at this point of the process,
as I do not think it is small change. As I commented above all of the
small changes suggested have all kind of various problems, and I am
pretty much sure my list above is not complete list (they are those
that immediately came to my mind when seeing this discussion). 

> If there is not enough interest, then nothing needs to be done.
> At least it will be documented that this was a conscious decision rather
> than an overlook or the result of simple rushing.
> (This will help against future criticizers of the protocol that wil
> raise these issues in their papers...)

I agree that this decision should be documented. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/