Re: Do ipsec vendors care about privacy?

[Antonio Forzieri <antonio.forzieri@cefriel.it>]

Hugo Krawczyk wrote:
[SNIP]
> 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, 

                                          [CERT,] [CERTREQ,] PREAUTH

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

                                   <--	  HDR, SK {EAP}
					
HDR, SK {EAP, [COMP_AUTH],
          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@cefriel.it
------------------------------------------------