Thank you for addressing my comments, apologies for my slowness. I don't have much left to ask, the remainder in line with [DC]. When you issue the new draft, I'll request IETF Last Call.
Deb On Mon, May 25, 2026 at 10:13 AM 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. > [DC] ah, I missed the words 'at least'... reading - fundamental... this is fine to remain as it is. > > 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? > [DC] this is ok as it stands too. > > > 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. > [DC] thanks, this is fine. > > 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. > [DC] thanks. > > > 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… > [DC] let's make this a bit more precise then, perhaps ' if the attacker instead has the responder's....' > > 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. > [DC] ok (hopefully that is common terminology) > > 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. > [DC] ok > > 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. > [DC] ok > > 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? > [DC] thanks to Songbo Bu for proposing the text. I do think it will be better. I can't quite see where the paragraph landed (I'll make a comment in the PR) > > 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”? > [DC] yes! and change 'keys to exchange' to 'keys into the exchange'. (another case of articles...and Russian not having them... your English is 100,000 times better than my Russian) > > 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. > [DC] I made a comment on that section in the PR. > > Nits: > Section 4, before second numbered list: 'In case the'/'In the case where > the'. > > > > Fixed. > [DC] perfect. > > > 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]
