Re: Authentication methods in IKEv2

["David Faucher" <dfaucher@lucent.com>]

Even in the absence of negotiating the authentication
method I think there is value in specifying which method
an endpoint has used, rather than leaving it up to the
receiving end to determine the structure of the "auth"
blob of data.

----- Original Message -----
From: "Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>
To: "Valery Smyslov" <svan@trustworks.com>; <ipsec@lists.tislabs.com>
Sent: Monday, November 11, 2002 11:28 AM
Subject: Re: Authentication methods in IKEv2


| At 11:45 AM +0300 11/11/02, Valery Smyslov wrote:
| >I have some doubts about using of authentication methods in IKEv2.
| >In IKEv2 negotiation of authentication methods was completely
| >removed - each side simply uses his/her favourite method.
| >I think this may lead to the lack of interoperability and extensibility
| >in case one of the endpoints supports more than one method of
| >authentication.
|
| Two endpoints that trust each other need to know *how* they trust
| each other before setting up a secure channel. IKEv1 blurred this
| rule by giving the option of saying how each side was going to
| authenticate. IKEv2 tightens this up.
|
| >For example. Let's initiator support RSA and DSS and has certificates
| >of the both types. Let's responder support only RSA. In this case,
| >responder has no means in the protocol to explicitly indicate,
| >that it will accept only RSA certificates.
|
| Exactly right. The two sides must know in advance why they trust each
other.
|
| The worst-case scenario is that the responder tells the initiator "I
| don't trust you", and the initiator tries again with a different
| authentication mechanism.
|
| For the rare case where the two endpoints don't really know each
| other *and* are going to trust each other *and* have multiple
| authentication mechanisms, we have eliminated a confusing option from
| IKEv1. That's exactly what IKEv2 was designed to do.
|
| --Paul Hoffman, Director
| --VPN Consortium