[IPsec] Re: draft-smyslov-ipsecme-ikev2-downgrade-prevention

[Christopher Patton <[e-mail]>]

Jun,


> Ok, the attack with this procedure could work, however from Y point of
> view it is talking with A instead of X, so if there are additional actions
> on Y tied to peer’s ID, for example if Y install some firewall/ACL rules
> based on IDi, and only X is allowed to access some backend service via the
> installed firewall/ACL rule, this attack won’t get around that.
>

Very true, but before Y figures out it is talking to the wrong peer, X
might reveal sensitive information about itself to the adversary that it
would have only wanted to reveal to Y.

In general, I don't think we should count on whatever application we build
on top of IPsec to save us. When we build these applications, we reasonably
assume IPsec provides a secure channel between the endpoints. This attack
would seem to invalidate that assumption, since (1) the peers have not
actually authenticated one another (X believes it's talking to Y, but Y
believes it's talking to A) and (2) the adversary can decrypt all packets
exchanged between the endpoints. We could try to shove in some
post-handshake authentication, but that just pushes the problem to the
application. I think it's better to fix IPsec itself rather than rely on
ad-hoc, per-application defenses.



> And beside configure properly, another mitigation against this attack
> without introducing new protocol changes is just Y mandate use of PPK
> (RFC8784).
>

I have two thoughts here.

First, I imagine that mandating the use of a PPK isn't going to be viable
for all deployment scenarios. Otherwise, I don't know that there would be
any point in supporting digital signatures for authentication in IKEv2. If
you can distribute a PPK, then you can also distribute a MAC key.

Second, RFC8784 does indeed provide some protection here, but the attack
would still invalidate forward secrecy. That is, if an attacker ever learns
the PPK used in the handshake, it would then be able to decrypt the
traffic. RFC8784 only provides forward secrecy if the PPK is combined with
a fresh, strong key exchange, but the attack downgrades the key exchange to
one the attacker can break.

This second point is a bit more subtle, but it reveals something
fundamental about authenticated key exchange in general: the possibility of
downgrade attacks implies that whatever security property we think we're
getting from the protocol might not actually hold -- whether it's forward
secrecy or something else that our application needs.

Best,
Chris P.