Re: Authentication methods in IKEv2

["Valery Smyslov" <svan@trustworks.com>]

----- 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 8:28 PM
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.

I've been thinking that they trust each other because they both trust the
same CA.
But that CA may easily issue certificates of both types, RSA and DSS.
Imagine the situation: security gateway serves as access point for
two distinct groups of clients. One group of clients supports only RSA,
while the other - only DSS. All clients have certificates issued by the same
CA
(of course, of different types). Gateway supports both RSA and DSS and
trusts the same CA. Situation probably a bit weird, but not unrealistic.

The question: how gateway would unambiguously determine in every particular
case
which of his certificates (RSA or DSS) to use (apart from heuristic
methods)?
By client's ID? Possible, but not scaleble - he must keep and
maitain database of all client IDs. By client's certificate? Possible,
but a bit heuristic and precludes asymmetric authentication,
that could be useful sometimes (legacy authentication, for example).

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

By the way, notification AUTHENTICATION-FAILED is missing
in the document...

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

The problem is that protocol seems to become less robust in that - it will
sometimes fail when it may (and should) succeed. The problem is relatively
easy
to fix - let each party include a list of supported authentication
mechanisms
into his/her first message, so that the other side may choose among them.

> --Paul Hoffman, Director
> --VPN Consortium

Regards,
Valery Smyslov.