Re: Authentication methods in IKEv2

[Jan Vilhuber <vilhuber@cisco.com>]

On Tue, 12 Nov 2002, Valery Smyslov wrote:

> ----- 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 I'm missing something. I quoth section 5.3 from the -03 draft:

5.3 Security Association Payload

   The Security Association Payload, denoted SA in this memo, is used
   to negotiate attributes of a security association.  An SA may
   contain multiple proposals. Each proposal may propose multiple
   protocols (where a protocol is IKE, ESP, AH, or IPcomp), along with
   a suite of cryptographic algorithms to be used by the protocols.

So, in theory anyway, authentication methods need to be negotiated via
cipher-suites within the SA payload, and thus the AUTH payload is
well-defined by nature of the cipher-suite both agreed to (rather than
adding another 2 bytes of 'type' to the AUTH payload).

he cipher-suites not contain the authentication type?

I would argue that cipher-suites (if we decide to stick with them)
must contain information about the authentication used for phase1
(which may be another nail in the coffin for cipher-suites'
combinatorial explosion). In fact, I'd say the defined cipher-suites
are a bit light and more discussion is surely in order. Do we really
just need two?

If we want to support legacy authentication in IKEv2, we definitely
need to be able to tell the 'client' that she's supposed to do legacy
authentication (at least in my idea of how legacy authentication needs
to work). So authentication-parameters for phase 1 need to be part of
the SA payload in some way (as part of the cipher suite or as an extra
value somewhere or whatever).

jan



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

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847

THE NETWORK WORKS,
NO EXCUS NFS server mastiff-fddi not responding still trying