Re: Do ipsec vendors care about privacy?

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

Tero, it seems to me that your presentation of issues below provides
a sense of complexity and cost well beyond what is really involved in these 
solutions. Yet, the issues you raise are valid concerns and they will help
deciding whether protecting user's identity in IKEv2's EAP methods is worth
the pain or not. 

I will re-write your concerns, and analyze their effect (editorial,
security and implementation). I cannot qualify this as MAJOR SURGERY.
Let me know what I am missing.

To avoid an even longer message I will focus here in the solution in which the
server authenticates using its signature in message 2 (which at this point
seems to me as the preferred alternative). 
To make this self-contained recall that this solution calls for:

  (1) adding to message 1 an indication that the initiator asks to use an
      EAP-based exchange. 
  It seems to me that the best way to do it is by means of a new exchange
  type. If there is any problem with this then you can add such an 
  indication to the SA payload.

(2) moving IDr, [CERT,] AUTH from msg 4 to msg 2.
    Namely, message 2 from R to I (in section 2.16) will look as:
                           <--  HDR, SAr1, KEr, Nr, IDr, [CERT,] AUTH
    and message 4 will simply be:
                           <--   HDR, SK {EAP}


Now to your objections as they apply to this solution.

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

I do not agree with this assesment.
First there is NO reason to go to the routability check if you are NOT under
attack (this is true for the regular protocol, for the current EAP-based
protocol, and for the modification I suggest).
The question is whether this modification opens a signifcant new DoS 
opportunity.  Not really.
Already now the responder needs to compute the DH key (something that CANNOT
be done off-line) AND verify I's signature (relatively cheap for RSA and
very expensive in the case of DSA) BEFORE it has authenticated the initiator.
The fact that this computation cost happens at the reception of message 3
rather than after message 1 (in the modified solution) does not make the
attack significantly harder to mount. Certainly not in a way that such 
attacks were hard to mount (or ineffective) before  and are realistic now due
to the modified protocol.  DoS attacks are possible in all cases and the only
mitigation we provide is the optional cookie in message 2. (This option
remains unchanged in the suggested solution.)

BTW, I do not envision EVERY ikev2 machine to be configured to run the
EAP variant of ikev2 (section 2.16) but only those machines acting as
gateway/servers for support of remote access users. Thus for most machines all
this issue is irrelevant.


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

Indeed a litttle bit harder. Still nothing major.
A possible specification using the current text would say something like:

   Payloads SAr1 and KEr are included as the first and second payload in
   message 2 (immediately after HDR), and the responder signs the octets 
   starting with the first octet of the first SPI in the header of
   the second message and end with the last octet of the KEr payload in
   the second message.  Appended to this (for purposes of computing the
   signature) is the initiator's nonce Ni (just the value, not the
   payload containing it) and the value prf(SK_ar, IDr).

  [Note: the last sentence is modified from ikev2-05 but this is pending
   revision by Charlie anyway]

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

Right. The good news however is that when Jane is in the road she does
not have to reveal her name before she really knows she is talking to 
Tarzan.  (something like "You Tarzan? Me wonder...")

It's all about tradeoffs and here I see privacy as the winner. Don't you?

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

As said above the Exchange Type can indicate that (or some other bit/octet in
SAi)

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

There is no change here. This SECOND AUTH (with the EAP-derived key)
by the responder (its definition and position in the protocol) are not
affected by the changes I suggested.

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

As I said, I do not suggest that every ipsec machine is configured
as a server (i.e. responder) for the sake of running IKEv2's EAP support 
protocol. Support for this method should be allowed only on gateways
(or machines) running as EAP servers (or relays).
Thus only such gateways will be open to polling attacks. However, in this
case we do not care about these attacks as we assume the gateway's id to be
public (we do not even encrypt it in message 2).

If you disagree with these views please let us know. This is an important
exercise. It is needed to decide where we establish the trade-offs.
I agree with two basic rules: do not mess with the non-EAP
portions of ikev2 and do not delay finalization of ikev2 as a whole.
Beyond that, I suggest that we consider user's privacy as a REAL issue in
remote access scenatios and be prepared, if needed, to pay some moderate
price for its inclusion.

Hugo