Hi Valery, See my replies below.
Regards, Rifaat On Mon, Apr 1, 2024 at 9:37 AM Valery Smyslov <s...@elvis.ru> wrote: > Hi Rifaat, > > thank you for your review. Please, see inline. > > > Reviewer: Rifaat Shekh-Yusef > > Review result: Has Issues > > > > # Section 3.1 > > > > * The description of the exchange seems odd, as it starts with the > responder, > > instead of the initiator. I suggest that the description of the exchange > starts with > > the initiator, followed by the responder. > > OK, I've added the following sentence: > > The initiator starts the IKE_SA_INIT exchange as usual. > > > * I think it would make it easier for the reader if you explicitly > describe the new > > notify payload. How about adding the following text to the beginning of > section 3.1? > > > > "This specification introduces a new IKE_SA_INIT packets Notify payload > of type > > SUPPORTED_AUTH_METHODS. This payload is utilized to convey the supported > > authentication methods of the party sending the message, thereby > facilitating the > > negotiation of authentication mechanisms during IKE SA establishment." > > Text in the Section 3 is changed to: > > When establishing IKE SA each party may send a list of authentication > methods it supports and is configured to use to its peer. For this > purpose this specification introduces a new Notify Message Type > SUPPORTED_AUTH_METHODS. The Notify payload with this Notify Message > Type is utilized to convey the supported authentication methods of > the party sending it. The sending party may additionally specify > that some of the authentication methods are only for use with the > particular trust anchors. Upon receiving this information the peer > may take it into consideration while selecting an algorithm for its > authentication if several alternatives are available. > > Thanks! That's much better. > > * "Since the responder sends the SUPPORTED_AUTH_METHODS notification in > > the IKE_SA_INIT exchange, it must take care that the size of the response > > message wouldn't grow too much so that IP fragmentation takes place." > > > > Is this limited to the responder? or should the initiator too take that > into > > considerations? > > It is not limited to the responder in general, but in the context of this > document > it is the responder who is going to send a message that could be > fragmented at IP level. > Usually the response is smaller than the request. In this case it can be > larger > and thus the responder should take care of IP fragmentation. > > Got it. I am assuming that the fragmentation issue with the initiator request is captured in a different document. If that is the case, then I think it is reasonable to leave this text as is. > > # Section 5 > > > > Second paragraph: I guess the potential for downgrade attack is not > limited to the > > NULL use case. If one of the supported methods is consider to be weaker > than the > > others, then an active attacker in the path could force the parties to > use that > > weaker method. > > This is not a "downgrade" in a common sense. Downgrade assumes that there > is a negotiation between the peers and an attacker may influence this > process forcing > peers to use weaker option. In IKEv2 authentication methods are not > negotiated. > This specification doesn't provide negotiation too, since each party > still chooses what it thinks is appropriate on its own. It only allows > peers > to select authentication method more consciously. > > Thanks for the clarification, as I am not an IKE expert. Having said that, I wonder why you are specifically calling out the NULL use case. Would not the NULL use case be also applicable to weaker authentication methods? Meaning that the attacker in the middle would be able to remove the stronger methods and leave the weaker ones? Regards, Rifaat > Regards, > Valery. > >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
