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 – 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 – 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 – 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 -- [email protected] To unsubscribe send an email to [email protected]
