I do agree. The value or importance of the downgrade attacks is that they show us some attacking scenarios which we may have not known before at the IKEv2 protocol design level.
Yes, when some secrets or KE algorithm compromised, we shall loss some or even most of security properties. However, what will be the worst cases? Back to a simple case, the forward security (FS). We still would like to keep the secrecy of the session key k (and then the confidentiality of data encrypted by using k), under the condition that the FS KE algorithm is secure, even all long term secrets of both parties have been compromised. So, here we have asked more that we shall loss all security once all long term secrets compromised. The amazing cryptography makes this possible! Guilin 发件人：Scott Fluhrer (sfluhrer) <[email protected]<mailto:[email protected]>> 收件人：Michael Richardson <[email protected]<mailto:[email protected]>>;'ipsec' <[email protected]<mailto:[email protected]>> 时 间：2025-08-01 05:16:29 主 题：[IPsec] Re: draft-smyslov-ipsecme-ikev2-downgrade-prevention If Eve can break the authentication on both sides, then she can perform a straight-forward MITM attack; Eve pretends to Bob when talking to Alice, and pretends to be Alice when talking to Bob. Eve can forward the information on, or manipulate it, as she sees fit. Neither Alice nor Bob have any way of determining that they're not talking to each other directly, because neither of them have any way of authenticating the channel (because Eve holds all the authentication information). Because of this straight-forward attack, the draft needs to assume that the private authentication information (signature private key) on one of the two sides is actually secure. ________________________________ From: Michael Richardson <[email protected]> Sent: Thursday, July 31, 2025 5:07 PM To: 'ipsec' <[email protected]> Subject: [IPsec] Re: draft-smyslov-ipsecme-ikev2-downgrade-prevention Valery Smyslov <[email protected]> wrote: > To be able to force peers to not use this extension, the attacker has > to remove the new notification from both the IKE_SA_INIT request and > the IKE_SA_INIT response. If the attacker does this, then both peers > will use the current IKEv2 authentication logic - the initiator will > sign only the IKE_SA_INIT request and the responder will sign only the Yes. It's an active on-path attack. The attacker impersonates both peers. > IKE_SA_INIT response. Note, that each peer will sign unmodified > IKE_SA_INIT message (with the new notify), but will verify the modified > one (w/o the new notify). For negotiation to succeed the initiator must > be able to forge _both_ signatures, otherwise the modification of > IKE_SA_INIT messages will be detected either by initiator or by the > responder. And if it can forge both signatures (e.g., _both_ peers use > weak _authentication_ algorithm or _both_ authentication keys are > compromised) then no defense is possible. But, again, your starting assumptions include: 3. The attacker must either have a long-term authentication key for one of the peers or MUST BE ABLE TO BREAK AUTHENTICATION ALGORITHM USED BY ONE OF THE PEERS IN REAL TIME. I guess if we limit things to *ONE* peer, then, yes, the downgrade attack against the Notify itself would be detected. But, why would such an attacker be limited in this way? Why can't they break both peers keys in real time? Again, the "bug" is that the responder's policy allows to negotiate only a quantum-unsafe algorithm (OR a hybrid algorithm, OR multiple authentications). We want this policy because we want to incrementally deploy. We get bitten if there is a CRQC before we are finished deploying, or more likely, because we forgot to turn that policy off. I suggest we come up with a latching process. This probably does not require any actual protocol changes, just implementation clue. But maybe there are new error conditions, and I'm concerned about site-to-site VPN where one ends initiates 99% of the time, and then things go wrong the 1% when it goes the other way. So once end latches to quantum-safe algorithms, it probably needs to let the other end know... that's probably just a single Notify. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
