[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Do ipsec vendors care about privacy?

Hugo Krawczyk wrote:
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
It disappoints me too.

I think that we have to ask to ourselves what price we can pay to obtain IDi protection.

*) 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.
This solution makes IKEv2 handshake 4RTT long (IKEv1 was 4,5RTT long with MM and 3RTT long with AM), even if with some trick (EAPC) we can make it 3RTT long when using some EAP methods (MD5 and GTC).

From IKEv2 draft (Appendix A):
   4) To decrease IKE's latency in the common case...

Is 1RTT a good price for IDi protection?

- 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).
This is a general solution for the problem, however it changes IKEv2 much more. The idea of moving IDr and AUTH payload to message 2, which didn't convice me in the past, may be is better than the first solution.
What I have in mind (and maybe what Hugo has in mind) is something like this:

         Jane                               Tarzan
       --------                           ----------

HDR, SAi1, KEi, Ni, IDr, -->
"You tarzan"
<-- HDR, SAr1, KEr, Nr, IDr,


                                         PREAUTH = SIG{R}(KEr)
                                         PREAUTH = HMAC(PSS,KEr)
         SAi2, TSi, TSr}          -->

                                  <--	  HDR, SK {EAP}
         CP(CFG_REQUEST)}         -->

                                  <--    HDR, SK {EAP, [COMP_AUTH],
                                                  AUTH, CP(CFG_REPLY)
                                                  SAr2, TSi, TSr}

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).
Agreed. As JFKi proposed in the past we can use a FIFO queue in which we put PREAUTH, and we can generate a PREAUTH i.e. each 30s. This should be useful expecially with digital signatures, while with PSS i guess that it can be done also "on-the-fly" (HMAC).
I agree with Hugo that these changes doesn't open IKEv2 to DoS attack more than IKEv2 already is; this mainly because the responder has to calculate SKEYSEED and {SK_d, SK_ai, SK_ar, SK_ei, SK_er} before it authenticates the initiator, so an attacker can mount a DDoS - Memory/CPU Exhaustion -.

But... Is this a good price for IDi protection?

Antonio Forzieri
CEFRIEL - Politecnico di Milano
Tesista Area E-Service Tecnologies
Tel: 02-23954.334 - email: forzieri@xxxxxxxxxx