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. > * "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. > # 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. Regards, Valery. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
