Hi Paul,
On Mon, Apr 1, 2024 at 9:08 AM Valery Smyslov < <mailto:s...@elvis.ru> s...@elvis.ru> wrote: I've added the following sentence to the Introduction: Since IKEv2 doesn't allow to use multiple authentication methods and doesn't provide means for peers to indicate to the other side which authentication methods they support, it is possible that in these situations the peer which supports wider range of authentication methods (or authentication token formats) improperly selects the method (or format) which is not supported by the other side. I wouldn't phrase it like it, since if we are talking about the peers using different authentication methods (eg client EAPTLS and server X.509 cert) then there are "multiple authentication methods". Also, the server could have multiple configurations for the same peer so a peer could come in using X509 or PSK. I think the core case is that the peers cannot dictate the auth method the peer must use. But this document allows them to inform the peer or what they are going to allow? Although a bit limited because in IKE_SA_INIT, one does not have the peer's identity yet, and different peers might only be allowed specific auth methods. I believe the issue Reese raised was: why we didn’t modify IKEv2 so that each peer was able to try to authenticate with all auth methods it had credentials for – with signature(s), PSK etc., and the SA would be established if at least one of these methods succeeded. I agree that the wording above is imperfect and imprecise. Perhaps: Since IKEv2 requires that each peer uses exactly one authentication method and doesn't provide means for peers to indicate to the other side which authentication methods they support, it is possible that in these situations the peer which supports wider range of authentication methods (or authentication token formats) improperly selects the method (or format) which is not supported by the other side. This is still imprecise since with EAP the server actually authenticates itself with two methods. But perhaps we can leave with this? Or can you propose a better wording? Regards, Valery. Paul
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
