Hi Med, we decided to change the text in Section 7 to avoid using the normative language, so that the problematic references can be left informative. We hope this resolves your DISCUSS.
New version: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-downgrade-prevention/08/ The diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-downgrade-prevention-08 Regards, Chris & Valery. > 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]
