Hi Valery, Deb, On the detection-mechanism point, I think Valery’s explanation is useful and probably only needs a short paragraph to make the behavior explicit for implementers.
One possible wording: The mechanism defined in this document does not require a separate downgrade-detection procedure. Instead, the additional initial-exchange data is included in the input to the IKEv2 authentication calculation. When a peer verifies the peer’s authentication data, a modification to the protected initial messages is detected as an authentication failure. The peer is not expected to distinguish this failure from other authentication failures, such as use of an incorrect credential or a local configuration mismatch. The main thing I would want to preserve is that this is an authentication-failure path, not a new diagnostic signal that implementations have to expose differently. Best, Songbo Bu On Mon, 25 May 2026 17:12:59 +0300, Valery Smyslov [email protected] wrote: Hi Deb, thank you for the review. Please see inline. Thank you for your work on this draft. I found it to be well written and easy to read (and super nice to be able to read a technical draft that I understand!). I have a few comments that I’d like you to address: Section 1, para 2: Perhaps consider adding a phrase in the middle of this sentence to say what the goal of this specification is: ‘…the data to be authenticated in IKEv2 to prevent particular downgrade attacks, and thus.....’ [nothing else in the intro gives even a hint of the plan] Done. Section 4: Consider making two subsections, one for each attack type, just to add clarity. I’m a bit unsure whether this would help. First, the attacks are almost identical, with very minor difference. The prerequisites and the impact are different, but the attack steps are the same and for this reason only KCI attack is described in full details. Then, frankly we are not sure that this list of two attacks is exhaustive (and thus use “at least two attacks” wordings). Putting them into subsections will implicitly indicate that no other attacks are known. I’d rather hear from Chris and others whether this change is needed. Section 4, first # list, 3: Will either (initiator or responder) work? Or do we really need the attacker know/be able to break the initiator’s auth key? The attack is described for the case the initiator’s key is compromised, since this is the most straightforward downgrade attack. If the responder’s key is compromised (a mirror situation), then the negotiated algorithms cannot be downgraded. However, for some IKE extensions, when the responder sends its preferences first in IKE_SA_INIT response, not in a response to initiator’s proposals (e.g., Certificate Request, Auth Announce), the attacker can change them unnoticed. This seems not as severe, as the downgrade attack, but still. We have some text about this later. Do you think a clarification is needed in the list item? Section 4, second # list: Are there initiator proposed protocol extensions that can be removed/added to help the attacker? I don’t think so. The attack is applied to the core IKEv2, irrelevant to the proposed extensions. Section 4, third # list, step 6: The attacker either knows the initiator’s long-term auth key, or must be able to break it in real time. At the expense of brevity, I would add the additional phrase here. Perhaps ‘and knows or can break the initiator’s long-term authentication key.’ How about: The attacker is able to do this because it knows the session keys and either knows the initiator’s long-term authentication key or can break its authentication algorithm. This is a bit more accurate, since if attacker could be able forge the signature without breaking the key. Section 4, para after third # list: Is this in addition to knowing/breaking the initiator’s auth key? The attacker can still choose the weak key exchange if they know/can break the responder’s auth key? No, this is an alternative use case. The attacker knows only one long-term key – either the initiator’s one or the responder’s one. We described attack in detail for the first case, but mention here, that for the second case, while less severe, some attacks are also plausible. If the attacker knows both long-term keys and can break into session keys too, we are helpless… Section 4, second to last para: I’m assuming that the attacker is not required to be on the path for the whole session. If I am correct, consider a small addition ‘be able to passively read’. [if there is a more appropriate word for ‘passively’, I’m fine with that, it is just the way I think about it.] Done. Section 4, last para: Consider replacing ‘because peers would disable’ with ‘which encouraged peers to disable’, or something similar. I would remove ‘on the other hand’, as this is part of the discussion - uncertainty about whether algorithms are secure or insecure. During a migration period, it is harder to determine which algorithms are secure/insecure, which makes these attacks more relevant. Done. Section 5, second to last para: Not all attacks are a result of knowing/breaking the initiator auth key, there is at least one variant where the responder’s auth key is know/breakable. Consider changing ‘In particular, for the attacks’ to ‘For example, for the attacks… Done. Section 5 or 6: Spelling out the actual detection mechanism: Can we add something that says how the impersonated entity can determine that they have been attacked by determining that Message1 (or Message2) is different than what was originally sent? Presumably they have to construct the hash and then validate the signature. Yes, but not as some separate check. With this extension the way authentication data (e.g. signatures) is calculated in IKEv2 is modified, so that both initial messages are now included under signature. Thus we make sure that their modification will be detected at least by one peer when it verifies the IKEv2 authentication data sent by the peer . And if the verification fails, the peer cannot tell that it is due to the attempted impersonation attack or due to any other reason (e.g., misconfigured long-term keys). Should we add any clarification, and if yes, can you propose some text, please? Section 8, Note between para 3 and 4: This doesn’t read properly, ‘one of the long term authentication information’, but I can’t quite figure out how to suggest it be corrected. Perhaps “credentials”? Section 8, para 4 and 5: I would flip these paragraphs, start with ‘avoid using the same key for different purposes’, and then talk about what the risk is. OK. Nits: Section 4, before second numbered list: ‘In case the’/’In the case where the’. Fixed. Thanks again for your review! I created a PR: https://github.com/smyslov/ikev2-downgrade-prevention/pull/42 Regards, Valery. Deb Cooley Sec AD
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
