HI Roman! > Hi Valery! > > Thanks for -05. Reducing the thread down to areas of discussion. > > > -----Original Message----- > > From: Valery Smyslov <[email protected]> > > Sent: Thursday, October 26, 2023 11:51 AM > > To: 'Roman Danyliw' <[email protected]>; [email protected] > > Subject: Re: [IPsec] AD Review of draft-ietf-ipsecme-ikev2-auth-announce-04 > > [snip] > > > > ** Section 5. Please add the Security Considerations of the specifically > > negotiated auth methods apply. > > > > This is not a negotiation, this is announcement, just to help the other > > side to > > correctly choose among several possible methods. Since this is a hint, > > implementations may use it as other hints that are already available (e.g. > > CAs > > from CERTREQ). Thus I'm not sure what specifically should be added to the > > Security Considerations section. Do you have some proposed text? > > I was looking primarily for a reminder that the different methods being > suggested each have their own > security considerations.
I think we can add the following text: Security properties of different authentication methods varies. Refer to corresponding documents, listed in [IKEV2-IANA] for discussion of security properties of each authentication method. Note, that announcing authentication methods gives an eavesdropper additional information about peers capabilities. If a peer advertises NULL authentication along with other methods, then active attacker on the path may force to use NULL authentication by removing all other announcements. Note, that this is not a real attack, since NULL authentication should be allowed by local security policy. Regards, Valery. > > > ** Section 6. The “Notify Message Types - Status Types” registry has > > > three fields. Please formally say that this document should be the > > > reference. > > > > Done. > > > > I also have off-the-list conversation with Daniel Van Geest, who made some > > good proposals, which I would also like to include in the draft if the WG > > agrees. > > > > 1. Specify that auth announcements are included into the > > SUPPORTED_AUTH_METHODS notification > > in the order of their preferences for the sender. This doesn't break > > anything > > (the receiver is free to ignore the order), > > but might help it to make the best choice. > > > > 2. Clarify that peers may send the SUPPORTED_AUTH_METHODS independently > > of whether it was received > > (this is not a negotiation). This is what actually the draft says now, > > just stress > > this for clarification. > > > > 3. Specify interaction with RFC 4739 (Multiple Authentication Exchanges in > > the > > Internet Key Exchange (IKEv2) Protocol). > > In particular. allow sending multiple SUPPORTED_AUTH_METHODS > > notifications in a message > > (also add a clarification that if multiple SUPPORTED_AUTH_METHODS > > notifications are included in a message > > and the receiver doesn't know why, the all included announcements form > > a > > single list). > > I see this proposed text is in -05. > > WG chairs: can you please check that this has consensus of the WG. > > Thanks, > Roman _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
