Hi Valery,
> While I agree that these prerequisites are not unrealistic, I > think that by Q-day (the day we believe the CRQC exists) all hosts must be > > already switched to the mode when PQ algorithms are mandatory, > with no exception for “old” systems. And before this day the attack is > impossible. > Agreed, we certainly hope that by then PQ key exchange is mandatory everywhere. > Do you think the working group would be open to a breaking change for the > draft that mitigates this attack? In any case, I think it ought to be > spelled out in security considerations. > > > > For the particular attack you described no breaking changes to the > protocol are needed to defend. I can propose the following modification. > > What the attacker does in this attack – modifies initiator’s > IKE_SA_INIT making it looking like initiator does not propose any PQ KE > methods at all. > > Note, that an attacker does not have access to responder’s > long-term authentication key and we can exploit this to detect this > modification. > > > > My idea is that responder can hash the received IKE_SA_INIT > message (actually, do a negotiated prf with some fixed or known key, since > > hash is not negotiated in IKEv2) and include the result into the > response IKE_SA_INIT using some new status notification. > > Responder’s IKE_SA_INIT message is directly included into the data > the responder authenticates, thus the attacker cannot change it unless > > responder’s private key is compromised or the attacker can break > the authentication algorithm. > > > > When the initiator receives the IKE_SA_INIT response, it can check > whether the content of this notification matches the IKE_SA_INIT message it > sent. > > If not – the attack is detected. Initiator that does not support > this extension will just ignore the unknown notification. > > > > Note that this does not protect against situation when responder’s > long-term key is compromised and initiator’s one is not. > > But in this case if the responder selects the hybrid key exchange > and the attacker then modifies its selection as if only ECDH is selected, > then the protocol will stuck – > > the responder will expect IKE_INTERMEDIATE as next exchange and > won’t accept IKE_AUTH that the attacker will initiate. > > > ^^^^^^^^^^^^^^ the initiator > > > > I’m not sure if the attacker can fix this situation (it seems to > me the answer is no, because even if it in between actively modifying > > all IKE messages, eventually it will have to authenticate all > these messages on behalf on initiator, which seems > > infeasible, since we assume that initiator’s key is not > compromised). > > > > And if both peers’ long-term keys are compromised and the attacker > can break ECDH, then no defense is possible. > > > > Your opinion, will this defense work? > This sounds like a partial solution. I think you'd also want the initiator to hash the responder's message as well. I believe we'd also want to include the intermediate key exchange messages to make this more robust. Also, I believe the mechanism itself is subject to the downgrade attack, unless it's marked as mandatory by the initiator. That is, if the responder doesn't respond with the hash, then the initiator would need to abort. Let's call this the "bootstrap" problem: The mechanism by which we prevent downgrading to ECDH only should not itself be subject to the same downgrade attack. I wonder what you think of the strawman I proposed upthread ( https://mailarchive.ietf.org/arch/msg/ipsec/EbgO8BkJVk-zlYasb9dUuOPmRzs/). Basically instead of just signing their own messages, each host also signs its peers messages. The idea being that a successful IKE_AUTH flow implies that the initiator and responder agree on the transcript of the conversation. This sounds a bit simpler than what you've sketched, but it also doesn't solve the bootstrap problem. Chris P.
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
