I agree - mandating use of PPK may not work. However, suggesting use of PPK, i.e., as a (negotiable?) option would be a very good thing: those who have the ability to employ it, and want better security - would opt in. While those who don’t care or for various reasons cannot manage the distribution - could opt out.
Comments? — Regards, Uri Secure Resilient Systems and Technologies MIT Lincoln Laboratory > On Jul 31, 2025, at 05:40, Christopher Patton > <[email protected]> wrote: > > > This Message Is From an External Sender > This message came from outside the Laboratory. > 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 -- [email protected] > To unsubscribe send an email to [email protected]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
