Re: [Last-Call] Genart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

[Paul Wouters <paul@xxxxxxxxx>]

I can live with that.

Paul

Sent using a virtual keyboard on a phone

On Apr 2, 2024, at 03:10, Valery Smyslov <svan@xxxxxxxx> wrote:



Hi Paul,

 

On Mon, Apr 1, 2024 at 9:08 AM Valery Smyslov <svan@xxxxxxxx> 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

 

--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call