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] Section 4: Consider making two subsections, one for each attack type, just to add clarity. 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? Section 4, second # list: Are there initiator proposed protocol extensions that can be removed/added to help the attacker? 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.' 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? 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.] 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. 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... 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. 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. 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. Nits: Section 4, before second numbered list: 'In case the'/'In the case where the'. Deb Cooley Sec AD
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
