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

Re: On ipsra authentication options



comments inline.

> On Mon, 26 Jun 2000, Stephane Beaulieu wrote:
>
> > Whether or not the Charter mandates it, I think that the solutions that
Hugo
> > is talking about have a lot of merit.
> >
> > Putting aside L2TP vs. XAUTH vs. ULA vs. PIC vs. Hybrid vs. CRACK
vs......
> >
> > The ability to have the remote user authenticate himself *securely* via
> > legacy systems without having to use and deploy an additional shared
secrets
> > or digital certificates seems to be very desirable.
>
> AFAIK, there is no proposal that does this yet. PIC mandates a public key
> operation (signature), to authenticate the Authentication server. This
> means that the user should know atleast the public key of the
> Authentication server, to achieve this.

Yes, of course it would require public key operations.  I wasn't trying to
suggest otherwise.

However, there are proposals which don't require the purchase and/or
distribution of "user" or "machine" certs for remote users.  All the remote
user would need is the public key of a trusted party (most likely a CA)
which can be used to verify the signature of the Gateway.

This saves time and money and headaches for the customer trying to deploy
it.

SSL was/is a huge success and it is based on this authentication model.  A
big reason why was because of how easy it was to deploy to users.

>
> Xauth relies on the Phase1 in IKE.
>

Yes it does.

> >
> > Forcing the customer to deploy IPsec with either certs + legacy auth, or
> > shared secret passwords + legacy auth, when all they want to do is have
> > legacy auth+IPsec, causes a of hassle in deployment and cost (in the
case of
> > certs).
> >
>
> I think you are ignoring those customers who want to do a "machine
> authentication" in addition to a legacy "user authentication". Inorder to
> acheive true "machine authentication" in addition to the legacy "user
> authentication", you will need to have two independant authentication
> steps, that don't rely on each other.
>

No I'm not ignoring them at all !!!!

They are important as well, and have legitimate requirements that MUST be
addressed.  I was just pointing out that there may be other requirements
which seem to be ignored.  I believe that this type of authentication (gw
uses cert, client uses legacy) is an important requirement, especially for
people wanting to do mass deployments.

> > I would like to see us provide these capabilities to the customer;
> > especially since we know it is possible.  Hybrid, CRACK and PIC (please
> > forgive me if there are others) address this issue now.  However, even
if we
> > decide to go with another protocol, I'm sure that we can make this
behavior
> > work in just about any model.  However PIC seems to be the only way to
make
> > this work without modifying IKE.
> >
>
> L2TP addresses this issue "now" (and even better, because it is an IETF
> protocol that is already implemented by many vendors), because we can do a
> legacy authetication without modifying IKE.
>

No it doesn't.

I think you are confused as to what I'm talking about.  Hopefully my
comments above have clarified this.

Stephane.

>     chinna
>
> > ----- Original Message -----
> > From: "CHINNA N.R. PELLACURU" <pcn@xxxxxxxxx>
> > To: "Hugo Krawczyk" <hugo@xxxxxxxxxxxxxxxxx>
> > Cc: <ietf-ipsra@xxxxxxxx>
> > Sent: Monday, June 26, 2000 12:45 PM
> > Subject: Re: On ipsra authentication options
> >
> >
> > > I think it is clear to everyone that, people want to do both "user
> > > authentication" and "machine authentication". The PIC type of protocol
> > > can't acheive that.
> > >
> > > IPSec/L2TP cleanly seperates IKE authentication with PPP/legacy
> > > authentication. So, people can use different authentications at
diffrent
> > > steps.
> > >
> > > The goal is:
> > >
> > > "- to define a standard mechanism to accomplish human user
authentication
> > > to an IPSec device running IKE, using legacy authentication
mechanisms."
> > >
> > > Please see inline:
> > >
> > > On Sun, 25 Jun 2000, Hugo Krawczyk wrote:
> > >
> > > >
> > > >
> > > > On Fri, 23 Jun 2000, CHINNA N.R. PELLACURU wrote:
> > > >
> > > > > In L2TP/IPSec, a possibly low entropy password based legacy
> > autentication
> > > > > is protected by a standard IKE phase1, which could be any of the
> > standard
> > > > > authetication modes.
> > > > >
> > > > > I don't see the need to design yet another protocol.
> > > > >
> > > > >     chinna
> > > > >
> > > >
> > > > I'll try one more time:
> > > >
> > > > Please consider the following IPSRA REQUIREMENT as I mentioned in my
> > > > previous message:
> > > >
> > > >  > Solutions based on legacy-user-authentication-ONLY MUST be
provided
> > > >
> > > > or in other words:
> > > >
> > > >   The ipsra wg MUST provide a user authentication solution that DOES
NOT
> > > >   ASSUME that the client (either user or machine) has a strong
secret.
> > >
> > >
> > > This is not an ipsra requirement. ipsra requirement is "tandard
mechanism
> > > to accomplish human user authentication to an IPSec device running
IKE,
> > > using legacy authentication mechanisms". And this is the requirement
that
> > > I see from our customers too.
> > >
> > > There is no requirement that IKE authentication done in Phase1 should
be
> > > made useless.
> > >
> > >
> > > > If you do not agree with this requirement just say that and try to
get
> > > > WG consensus on eliminating it. In the meantime I am assuming this
IS
> > > > a requirement.
> > > >
> > >
> > >
> > > I do not agree that what you are saying is the requirement.
> > >
> > >
> > > > My arguments (as I already explained) are strongly based on this
> > > > requrement (and, again, this reqt does not exclude solutions that
> > > > accomodate strong-secret authentication, all what the reqt is saying
> > > > is that there MUST be a solution for the case where the strong
secret
> > > > does not exist).
> > > >
> > > > Now, the following is an absolute fact, not a personal opinion
> > > > or anything subject to WG agreement:
> > > >
> > > >    THERE IS NO IKE MODE THAT CAN PROVIDE A SOLUTION THAT SATISFIES
> > > >    THE ABOVE REQUIREMENT
> > > >
> > >
> > >
> > > This is not the requirement. The requirement is to support all legacy
> > > authentication systems. I wonder if ipsra cares about the authorzation
and
> > > accounting part?
> > >
> > >
> > > > Note that your proposal to run regular IKE and then L2TP assumes
that
> > one
> > > > of the cuurent authentication modes of IKE can be used in this
context.
> > > > Since all the IKE modes assume a strong secret at BOTH sides then
your
> > > > solution is NOT fulfilling the above requirement.
> > > >
> > >
> > > The above requirement is not an ipsra requirement.
> > >
> > > > So, if you want to keep your proposal on the WG's table you have to
> > > > CONVINCE THE WG TO EITHER:
> > > > * drop the above requirement (i.e. convince the WG to MANDATE that
all
> > > >   ipsra authentication uses a strong secret at the client)
> > >
> > > This was never a requirement. IKE authentication is independant of
legacy
> > > authentication. There are no assumptions. Customers will choose to use
> > > whatever IKE authentication they want, and will choose to use whatever
> > > flavor of legacy authentication they want to use in that step.
> > >
> > > These two steps should be independant, there is no requirement to
develop
> > > a certificate enrollment type of protocol to get the certs
(credentials),
> > > and then use the certs for IKE authentication.
> > >
> > > > OR
> > > > * to accept changes of IKE (by adding a new one-way-authentication
mode
> > to
> > > >   phase 1)
> > > > Hugo
> > > >
> > > >
> > > >
> > > >
> > >
> > > AFAIK, this has never been a requirement, in either IPSec WG or ipsra
WG.
> > >
> > >
> > >     chinna
> > >
> > > chinna narasimha reddy pellacuru
> > > s/w engineer
> > >
> > >
> > >
> >
>
> chinna narasimha reddy pellacuru
> s/w engineer
>
>
>