Hi Paul, > >> Note that the IANA registry involved here was renamed since the > >> latest draft was written :) > >> > >> Notify Message Type -> Notify Message Status Type > >> > >> "IKEv2 Notify Message Types - Status Types" -> IKEv2 Notify Message > >> Status Type > > > > This is already fixed in my local copy (the IANA was so kind to remind > > me about this change in a personal message :-)) > > Good :) > > > > >> I wonder if it would make sense to somewhere explain that the > >> authentication method refers to the AUTH payload, > > > > Hmm... I'm not sure where to put this clarification and in which form. > > I think that there is a chance of over-specification, that might add > > confusion. > > You are talking only about signature authentication, and besides that > > we have PSK. In addition, IKEv2 doesn't require peer ID to match > > X.509 identity, since they are linked via the local security policy > > (i.e., it is the policy, which specify which IDs are acceptable and > > which X.509 identities they correspond to, so the strict matching of > > them is just a one particular case). > > > > If think that this is a real concern, then do you have any concrete text in > > mind? > > Maybe somewhere say it is the “authentication method used for the AUTH > payload”.
OK, then how about (Section 3): CURRENT: The receiving party may take this information into consideration when selecting an algorithm for its authentication if several alternatives are available. NEW: The receiving party may take this information into consideration when selecting an algorithm for its authentication (i.e., the algorithm used for calculation of the AUTH payload) if several alternatives are available. Does this help? Regards, Valery. > Paul= _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
