Hi, Valery and Chris, About, NonceRData and NonceIData, yes, I also think they can be moved from Valery's new draft for preventing downgrading atrack. However, keep them can make the change seemingly simpler, as just nneding to add RealMessage1 or RealMessage2 to the AUTH data. Otherwise, two changes at each side, namly adding one of the those two messages and clearly keeping nonce data alone.
From view points of regorous proofs and response-challenge security protocol design, using nonces in protocol and keeping them in the AUTH data is crucial. So, original IKEv2 (RFC 7296) is well designed by including nonces in AUTH data. Otherwise, some routine attacks could be mounted by reusing of messgaes in different sessions. It is also good to change the order of RealMessage1 and RealMessage2 when preparing AUTH data. It keeps such a logic: The info sent by the entity is put in the first position. This will prevent a message sent from a responder being explained as a message sent by the entity but in the role of initiator. Also, if MAC is used by a PSK shared by the two parties, this way can guarantee that the MAC values generated by the two parties will be definitely different, as AUTH data are different, even the key used is the same. Guilin 发件人：Valery Smyslov <smyslov.i...@gmail.com<mailto:smyslov.i...@gmail.com>> 收件人：'Christopher Patton' <cpat...@cloudflare.com<mailto:cpat...@cloudflare.com>> 抄 送：ipsec <ipsec@ietf.org<mailto:ipsec@ietf.org>> 时 间：2025-07-11 09:52:51 主 题：[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00 Hi Chris, 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.) This is an interesting point, thank you for bringing it. My initial idea was to make changes as small as possible. I agree that explicitly including nonces in this case seems to be not needed. Perhaps it’s safe to remove them. On the other hand, I heard a lot of times from cryptographers that explicit inclusion of some data into some calculation makes their life easier �C they could be sure that all the needed data is included regardless of protocol message format. Thus, I think that it is better to leave explicit nonces so that SIGMA proofs remain untouched. 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. I don’t have a strong opinion on this. I was only thinking a bit about the order. My gut feeling is that if we make initiator’s an responder’s blobs to sign always different then it is generally preferable from cryptography point of view, but I cannot find any attack where this is exploited in case of IKE (it seems that selfie attack is already impossible due to different SK_pi/SK_pr keys). What about the same buffer �C sure it depends on implementation, but usually incoming and outgoing messages are kept in two different buffers (just because they appear at different times), thus I don’t think there is a (noticeable) performance penalty. 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 �C 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. Exactly. 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. The standard IKE behavior is to ignore unknown status notifications, thus no problems with incremental deployment, Regards, Valery. Chris P.
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
