Hi Valery, Thanks for engaging with me on this. Your answers/suggestions below address all my comments and concerns.
Regards, Rifaat On Mon, Apr 1, 2024 at 11:45 AM Valery Smyslov <s...@elvis.ru> wrote: > Hi Rifaat, > > > > I snipped parts where we are in agreement. > > > > Hi Valery, > > > > See my replies below. > > > > Regards, > > Rifaat > > > > > > […] > > > > > * "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. > > > > It is described in the IKE fragmentation document (RFC 7383). > > I’ve added a reference to it in the -07 version. > > > > > > > # 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? > > > > Yes, it is possible. NULL authentication is just the easiest way > for an attacker to do it. > > I can add the following text in the Security Considerations > (right after the NULL authentication discussion): > > > > Similarly, if an attacker on the path can break some of the announced > > authentication methods, then the attacker can encourage peers to use > > one of these weaker methods by removing all other announcements, and > > if this succeeds, then impersonate one of the peers. > > > > Does this help? > > > > Regards, > > Valery. > > > > > > Regards, > > Rifaat > > > > > > Regards, > Valery. > >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
