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.
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
