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

Re: L2TP is ipsra solution (?)



On Sun, 25 Jun 2000, Hugo Krawczyk wrote:

> 
> 
> On Fri, 23 Jun 2000, CHINNA N.R. PELLACURU wrote:
> 
> > On Fri, 23 Jun 2000, Hugo Krawczyk wrote:
> > 
> > > 
> > > On Thu, 22 Jun 2000, CHINNA N.R. PELLACURU wrote:
> > > 
> > > > Since I did not get much response to my questions requiring clarifications
> > > > of ipsra requirements, I take the liberty to guess them, based on the fact
> > > > that PIC was acceptable to the requirements.
> > > > 
> > > > If PIC was acceptable to the ipsra requirements, then I beleive L2TP/IPSec
> > > > meets those requirements too, and infact I beleive L2TP/IPSec is a better
> > > > way of meeting those requirements than PIC.
> > > 
> > > My understanding is the following:
> > > 
> > > >From the charter and discussions in the list there seem to be
> > > two ipsra requirements that most people agree with:
> > > 
> > > 1. Do not change IKE
> > > 2. Solutions based on legacy-user-authentication-ONLY MUST be provided.
> > 
> > Thankyou for clarifying them. I wasn't fortunate enough to get any
> > clarifications for my questions.
> 
> 
> Sorry, I have the feeling that you are not listening.
> The clarifications are there, you just DON'T WANT to get them.

Please see my other mail. I feel that the requiremnt that you were based
on in designing PIC is not a requirement at all.

> 
> Most answers to the issues you raise are included in previous messages
> sent to the list and in the one I sent a few minutes ago.
> 
> As for the comparison between the strength of authentication provided by l2tp
> vs PIC I prefer to leave any detailed explanations (if still required)
> to after we agree on the basic requirements discussed in my previous note.
> In any case, for the record, let me say that the comparative analysis you
> made is wrong. There is no such authentication-strength advantage to the
> l2tp solution.
> 

It is as clear as black and white. In PIC, the AS does authenticate itself
to everybody unconditionally, and to it is not a big hassle as far as an
attacker is concerned. So, the attacker has to attack the legacy
authentication system only. Now, if an attacker is succesful in guessing
the password (which should be releatively easy, because this it is a human
memorizable password, and has the disadvantages associated with such
passwords), he would get a certificate, and a key pair to do the IKE
authentication, and proceed.

In IPSec/L2TP, IKE authentcation provides security for legacy
authentication, and so, if an attacker cannot attack IKE authentication,
he cannot even see the legacy authentication. If an attacker breaks the
IKE authentcation, then he can see the legacy authetication, and so he has
to now start attacking the legacy authentication, after doing a full
phase1 and a full phase2. This is clearly the most secure way of
supporting legacy authentication mechanisms in an IPSec remote access VPN.

IPSec/L2TP is the cleanest path of deployment of PKI, because it provides
the flexibility to use PKI or not, and there is no change to the client or
the server (not even one line of code). If the user decides that he no
longer needs to do legacy authentication, it can be turned of, via
configuration. It is the most flexible mechanism, and the most modular
architecture. And it improves the security of the whole system, by
independantly doing legacy authentication, in addition to IKE
authentication, instead of solely relying on legacy authentictaion.

People have been doing legacy authentication, authorzation and accounting
for a long time, and the IPSec/L2TP architecuture preserves both the IPSec
and legacy remote access architecutures in a clean modular way. This will
be the architecture with the least possible impact, if IPSec remote access
VPNs want to leverage legacy remote access infrastructure.

There is no need to design a certificate enrollment protocol, and do the
enrollment over the Internet. I guess, certificate enrollment protocols
are not a topic for this WG, and whatever certificate enrollment protocol
the PKI groups comeup with will be used anyway.

    chinna

> But I do agree with you (and I said that myself) that the getcert/PIC 
> solutions have a performance cost especially regarding the number 
> of authentication messages exchanged before an ipsec SA is established.
> This cost comes from two properties that people like:
> (1) do not change IKE 
> and 
> (2) provide a clean deployment path towards user-certs. 
> 
> It is up to the WG to decide on the trade-offs...
> 
> Hugo
> 
> 
> 

chinna narasimha reddy pellacuru
s/w engineer