[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Do ipsec vendors care about privacy?
Hugo Krawczyk writes:
> (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}
This will open the responders attack to polling attack.
> 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).
> 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 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.
> > - 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.
> > - 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.
> 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?
> 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.
> > - 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 :-).
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/