Re: Do ipsec vendors care about privacy?

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

> 
> > 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).
> 
> Some vendors refused to implement or use the aggressive mode of the
> IKEv1, just because of it required you to do expensive operations
> without ever knowing if there is anybody here. I would still guess,
> that most implementations would require the return routability check
> every time if this kind of protocol is used (at least I would in my
> implementation). 

There is no reason to do that if the ipsec machine is not responding to
EAP based exchanges. ANd even if the machine does respond to these
exchanges there is no reason to use the cookie before the traffic 
reaches some "abnormality threshold". The comparison with IKEv1 is not
valid since ikev1 did not even give you the option to use a "routability
cookie". 

 > 
> > 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.
> 
> Yes, he needs to do that, but at that point he have seen that the
> other end can see the packets sent to him, thus it makes spoofed
> attacks impossible. The real attack is when someone sends lots of
> spoofed packets each having fake IP address (so you cannot use IP
> address to filter them out) and something that causes you to do work.
> 
> The current protocol do not allow that. 
> 

The current protocol allows you to use the routability cookie when
necessary. I agree that the opportunity for DoS seems more concrete in
this variant of the protocol but this is not much more than an ilusion. If
someone wants to DoS-attack a gateway it can do it in the regular protocol
via state exhaustion and DH computation. The solution (or mitigation) is
the same in both cases: the routability cookie.
 

> > 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.
> 
> It makes huge difference. So big, that I guess that most of the
> implementations will still want to make it message 3, i.e they will do
> the cookie exchange before allowing any of those operations. 

I hope they won't. It is not necessary.
Do the cookie only when under attack (unusually high traffic).
You need this mechanism in place irrespective of the EAP-specialized
exchange

> 
> > >       - 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]
> 
> There might be other payloads than SAr1, and KEr in that packet, which
> need to get protection also, so the text needs to be different. I know
> it, as I wrote the other draft doing about the same thing for IKEv1...
> 
> I didn't say it is impossble, I said it is little bit harder. I also
> implemented my draft on IKEv1, and it required again little piece of
> interesting code. It is not impossible, but it is not trivial either. 

It is nothing major and worth the pay off: user's privacy

> 
> 
> > >       - 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...")
> 
> And this means that security gateway does not know which kind
> authentication it really should be using, if he have multiple
> identities. 

The initiator will tell the gateway that it expects a EAP exchange,
no need for the "me Jane" mechanism

> 
> > It's all about tradeoffs and here I see privacy as the winner. Don't you?
> 
> Actually no. I think You Tarzan, Me Jane is important feature
> for the remote access cases too. Also I think protection against the
> polling attack is more important than protection against active attack
> to initiators identity. Also this protection is not available when
> doing the normal certificate based authentication, nor it is available
> when doing the shared key authentication, why should it be there for
> the EAP?

Because remote access by users is the main scenario in which identity
protection makes sense. We would be allowing  the polling attack ONLY
against gateways that act as EAP servers. These are fixed address gateways
with no real need (or option) to hide their identities

 > 
> > As said above the Exchange Type can indicate that (or some other bit/octet in
> > SAi)
> 
> I do not like having more different exchanges, I would really like to
> keep the one exchange model we currently have.

I do not understand what the problem of having a different exchange type
for EAP is. After all, even now, this is a different exchange (with
different messages and flows)

 > 
> > > 	- 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.
> 
> I didn't notice there was second AUTH before I started looking the EAP
> stuff more because of the DHCP-over-IKE text. The current document do
> nee more text about the second auth payload. 
> 
> > 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.
> 
> As an implementator I still think that these changes are not small,
> and they do add more complexity to the system (as an toolkit vendor we
> do need to support almost all of the features, so I cannot just ignore
> this case because it does not concern me :-). 
> -- 

We are in the trade-off business.
You have valid points about the fact that "nothing is for free".
But weighting all the pro's and con's I see user's identity privacy
in the EAP eachange as a sufficient reason to incur in these
not-really-major costs (I am sure you will manage to offer your toolkits
even in this case, and you may even sell more of these since people will
love to protect the privacy of their identities when in the move...)
Personally, ,I believe that even a possible extra round trip is worth the
added privacy, but we do not even need the extra round.

Hugo

> kivinen@ssh.fi
> SSH Communications Security                  http://www.ssh.fi/
> SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
>