Hi Med, please, see inline.
> Mohamed Boucadair has entered the following ballot position for > draft-ietf-ipsecme-ikev2-downgrade-prevention-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-downgrade-prevention/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Hi Valery and Christopher, > > Thank you for the effort put into this well-written spec. > > Thanks Dhruv Dhody for the OPSDIR review. Thanks to the authors for the > follow-up. I saw that you added an ops cons section in your github copy. > Thanks. > > I have two straightforward points to discuss. Let me know if I missed > something: > > # IKE_INTERMEDIATE exchange > > CURRENT: > If peers > support the extension defined in this document, then they MUST treat > modified blocks of data to be signed (or MAC'ed) defined in Section 6 > as replacements for blocks of data defined in Section 2.15 of IKEv2 > [RFC7296], so that in case of IKE_INTERMEDIATE the IntAuth is added > to these modified blocks. > > Adhering to this requires RFC9242. I think that RFC should be listed as > normative. I understand your point, but it is questionable from our logic. Our logic is as follows - normative references must _absolutely_ be read to correctly implement the spec. If we make RFC 9242 normative, but (for some arbitrary reason) an implementer does not intend to implement it, wanting to only add a downgrade prevention to the core IKEv2, then reading RFC 9242 is not needed. Please, don't get me wrong - it's not a big deal to make RFC 9242 normative, but my internal feeling of consistency will suffer :-) We don't have conditional normative references, alas :-) Note that we previously published RFCs with sections describing interactions with other IKEv2 extensions and RFCs listed there were still listed as informative (even in presence of some normative language). See Section 4 of RFC 9593 and SEction 4 of RFC 9242 as examples. > # Resumption > > CURRENT: > The information of whether an implementation used the new > authentication logic for old SA MUST be stored in the ticket and the > implementation MUST act the same way when doing resumption. > > There is not ticket discussion in the base IKEv2 spec (or I missed it). Why > RFC5723 isn’t listed as normative here? For the same logic as above. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # Full symmetry > > CURRENT: > 1. The attacker must be on the path with the ability to intercept > communications between the peers and to modify their messages. > > I think the condition is even stronger as the attacker has to be on-path for > both directions and for the ** full ** exchanges. This is true, but does not the current text imply this? I mean that we do not add any restrictions on message direction etc,, thus, in my reading, it automatically means that an attacker must be able to read and modify messages in both directions and for the unlimited duration.Perhaps my reading is too liberal :-) > # Given the attack assumptions, how the initiator is expected to be behave if > the attacker blocks received messages with the extension. Is it usual to > disable some extensions when such failures are experienced by a peer? If so, > the benefits of the new extension can be nullified by such attacker behavior. If both peers support this extension, then the attacker cannot _force_ peers to establish IKE SA as if this extension is not supported. However, the attacker can always _prevent_ peers from establishing IKE SA. If the attacker is on the path an can block IKE messages then it is impossible to prevent this kind of attack, with or without this extension. > # Receiver side > > CURRENT: > If the responder supports this extension then it also includes this > notification in the response message regardless of whether it was > received in the request or not. > > ## What is the benefit of sending the extension back even if this is not > offered by the initiator? > > ## I suspect this is to ease implementations and avoid conditional handling at > the responder but I may be missing something here. No, this trick is the only way to prevent the attacker from disabling this extension. Note, that the attacker has a lot of capabilities for this attack - it can read and modify even encrypted IKE messages and can forge signature of one peer (but not both). This "strange" behavior, when the responder always sends notification even if it does not receive it makes it possible to prevent notification stripping by the attacker even for the current IKEv2 authentication - thus the attacker cannot force peers to not use this extension if they support it - otherwise SA won't be established. > # nits > > ## Conversation > > CURRENT: > on this protocol by having the peers confirm they have participated > in the same conversation. > > There is formally no such concept in the base spec. Do we refer to session? > Something else? Hmm... IKE SA establishment? Session is more like SA, but we are referring to the process of its establishment, which includes several exchanges. Do you think that "conversation" is not clear for readers? > ## > > CURRENT: > The details of how authentication is performed in IKEv2 are defined > in Section 2.15 of IKEv2 [RFC7296]. > > I would expect the same title is the cited RFC to be used here (and similar) > but seems that the we are mixing reference labels and RFC numbers. Tero always asks for adding short RFC title (sometimes informal) before references (that in most cases are RFC numbers). Just for readers' convenience. > ## I will send you a PR with some few suggestions [1]. Feel free to grab > whatever useful for you. Thanks! Regards, Valery (for authors). > Cheers, > Med > > [1] https://github.com/smyslov/ikev2-downgrade-prevention/pull/54 > _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
