Re: On ipsra authentication options

["CHINNA N.R. PELLACURU" <pcn@xxxxxxxxx>]

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