Hi Paul, On Mon, Apr 1, 2024 at 9:08 AM Valery Smyslov <svan@xxxxxxxx> wrote:
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 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 |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
