[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Authentication methods in IKEv2



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


> 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.

Exactly. It can be achived, for example, by adding field "Authentication
Data Type"
into Authentication Payload.

Regards,
Valery Smyslov.

> ----- 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
>
>