Valery, On Thu, Jul 10, 2025 at 8:20 AM Valery Smyslov <[email protected]> wrote:
> HI Chris, > > > > thank you for your review. Please, see inline. > > > > Hi Valery, > > > > Thanks so much for the quick turnaround! The draft is nicely written, and > I'm happy that it addresses the broader problem. > > > > I just have two questions on the draft. > > > > First, I understand the intent of the extension to be to have each party > sign the entire transcript of the IKE_SA_INIT exchange. Is that what's > happening here? I ask because I'm not precisely sure what parts of the > transcript are specified here: > > > https://www.ietf.org/archive/id/draft-smyslov-ipsecme-ikev2-downgrade-prevention-00.html#section-6-5 > > > > RealMessage1 is the IKE_SA_INIT request and RealMessage2 is the > IKE_SA_INIT response. They are called in such a way > > in RFC 7296 when authentication of IKE SA is defined (Section > 2.15 of RFC 7296). As result - both IKE_SA_INIT messages are included > > into the blobs of data that are signed or MAC’ed by both peers. > Got it. In that case, why append NonceRData to InitiatorSignedOctets? Are these octets not already contained in RealMessage1 | RealMessage2? (Same question for ResponderSignedOctets.) Another minor note here: Why flip the order of the messages between initiator and responder? The initator signs RealMessage1 | RealMessage2 while the responder signs RealMessage2 | RealMessage1. Thinking about the implementation, it might be nice to sign the messages in the same order so that the signing and verification operations work on the same buffer. > What you described is a common behavior in IKEv2 for negotiation > of support for an extension – > > an initiator includes some notification in the request > indicating that it wishes to use an extension and > > a responder includes the same notification in the response _ > *only*_ if it sees it in the request. > > > > The draft intentionally uses a slightly different approach that > makes it impossible for an attacker to > > persuade peers that one of them does not support this extension > in case both support it. > > The approach is that both initiator and responder _ > *unconditionally*_ include this notification > > in their messages if they support this extension (major change > in behavior is for the responder – > > it _*always*_ includes this notification in the response *even* > if it was not present in the request). > > > > With this approach downgrade of this extension is not possible > if both peers support it (even if it is optional for them). > > Indeed, if an attacker removes this notification from the > IKE_SA_INIT request, then responder will > > send this notification in response anyway, but it will use old RFC > 7296 logic for authentication. > > The initiator will receive this notification and will think that > both peers support the new logic and will use it, > > thus the SA will fail. The same will happen if the attacker does > not modify the request, but removes > > this notification from the response. Note, that the attacker > cannot remove this notification from both request and response, > > because in this case it have to forge both initiator and > responder signatures, which is beyond the preconditions of the attack – > > it this case the attacker can do everything and no defense is > possible. > Ah, I think I see. The behavior is: if one host supports the extension _and_ its peer notifies it of support, then the host will use the new authentication logic. Very nice idea. Just to confirm: what happens if one host supports the extension but the other doesn't? Would it simply ignore the notification? At a high level, I'm trying to figure out if this can be incrementally deployed without breaking connectivity. Chris P.
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
