Subject: RE: Do ipsec vendors care about privacy?

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 9 Apr 2003 01:56:47 +0300 (IDT)

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).

---

From: Antonio Forzieri <[email-masked]>
Date: Wed, 09 Apr 2003 12:14:23 +0200

Hugo Krawczyk wrote:
[SNIP]
> enough to justify even the small complexity these changes required).
It disappoints me too.

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

>   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?

>   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
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: [email-masked]
------------------------------------------------

---

From: Derek Atkins <[email-masked]>
Date: 10 Apr 2003 14:06:21 -0400

Antonio Forzieri <[email-masked]> writes:

> It disappoints me too.
> 
> I think that we have to ask to ourselves what price we can pay to
> obtain IDi protection.

Remember that IPsec is a peer-to-peer protocol and can always be
reversed.  So the 'client' of one protocol can be turned into the
'server' in another context.  The protection we're talking about here
is against _ACTIVE_ attacks -- we're already protected against passive
attacks.

The concern is that an attacker sees an IKE connection from 1.2.3.4
and wants to figure out who 1.2.3.4 is, so they initiate an IKE to
1.2.3.4 (they can't just watch the existing session -- IKE is
protected against passive eavesdropping).  If the responder just gives
up it's identity, then you've just lost!

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com