On Tue, 14 Aug 2018, Scott Fluhrer (sfluhrer) wrote:
They also do some number games about how many packets you need to
send and how fast, and I found their description confusing. I think they
change SPI (cookies) and so these would be "new" exchanges so this has to
be the DH component, but even if you break DH in IKEv2,you haven't broken
the AUTH payload
This is not a MITM attack, this is an impersonation attack.
If it is not a MITM, then the original connection will establish. If
they then send packets with non-matching SPI's, the packets would simply
be dropped or receive an INVALID_(_IKE_)SPI answer which would not give
them any kind of oracle at all ? If they use the same IKE SPIs then
what would they be attacking? They cannot send IKE_AUTH (or non-Quick
Mode) packets? I mean they can, but any sane state machine will just
drop them or send them an error that is completely independent of the
content of their packet other then the Exchange Type. So I don't
understand how they can learn anything from that.
And we all have rate-limits in place so getting even 50,000 packets (and thus
50,000 half-open SA's) tested before a connection is aborted is not really
feasable (although I guess it was for the vendors mentioned?)
If the IKEv1 exchanges error out, and hence are closed, they wouldn’t count as
half-open; that would make the attack more feasible. I don't know how real
IKEv1 implementations deal with it...
On the first packet sure, but not on a subsequent packet. That is why I
find the paper confusing. Messing up SPI's shouldn't get you anything
meaningful. It seems to conflate injecting the DH exchange and injecting
after the DH exchange?
And finally, this is all about RSA v1.5 and does not work with RSA-PSS which is
used when using RFC 7427 ?
Actually, going to an alternate RSA signature method doesn't protect you; it's
the public key encryption in IKEv1 that is what's critical for the attack (and
that you use the same RSA keys for both).
Yes, but everyone already knew now to use the same keypair for different
(v1.5 vs PSS) encryption types.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
