Re: L2TP is ipsra solution (?)

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

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.

> 
> While the second req't does not exclude solutions where authentication is
> complemented or strengthened via machine authentication (in ADDITION to 
> user authentication) the latter (i.e., machine authentication) cannot be
> mandated.  In this case, i.e. authentication via user's secrets and no
> machine secrets, there is no way to provide a solution *without changing
> IKE*.  The reason for this is that such an authentication requires a
> one-way authenticated phase 1 (in which only the server/gateway
> authenticates to the client and not viceversa) and there is
> NO such a mode in IKE.  Adding it means "changing IKE". 
> 

I feel, mutual bi-directional authentication is superset operation to a
uni-directional authentication. So, if IKE only provides bi-directional
authentication, then it should definitely satisfy a requirement for
uni-directional authentication.

You don't have to change IKE inorder to do "user authenticaiton". You can
use L2TP after IKE to do it, and this doesn't need any change to IKE. The
IKE authentication provides security to the L2TP user authentication
phase, and can be considered an independent authentication step.

Why does "user authentication" have to be one way authentication? In any
kind of authentication, that deals with shared secrets, both the parties
are can be mutually authenticated, like we do in IKE.

The requirement for a one-way authenticated phase1, seems un-necessary to
me. If we can authenticate both parties in one-shot, then why not do it?!


> If you believe that you can do authentication via l2tp/ipsec without
> adding a new IKE mode please explain in detail how you do that.
> 

First, we do IKE phase1 using any of the standard modes, then we do phase2
to protect L2TP traffic, and then as part of L2TP we do legacy
authentication.

The legacy authentication done in L2TP is completely independant of the
Phase1 authentication. IE. if someone breaks IKE phase1 authentication,
then that doesn't help him in any way to break the legacy authentication
in L2TP.

But, in PIC, if someone breaks the legacy authentication in the pre-IKE
phase, then he will get a certificate, and key-pair, that make the real
IKE authentication useless.


> Besides, the advantages of l2tp/ipsec that you mention below 
> relative to PIC do not hold. PIC has all these properties
> if we add to it machine authentication; see below where I also 
> explain how machine authentication is added to PIC.
> 
> 
> > 
> > This is because, 
> > 
> > 1. In L2TP/IPSec we have the flexible framework to do a possibly stronger
> > authentication (using digital signatures) in IKE before, a possibly weaker
> > authentication(using simple password based mechanisms), with legacy
> > authentication systems. But, in PIC, the stronger authentication is
> > predicated by a weak authentication(because credentials needed for the
> > stronger authentication are provisioned based on the weaker
> > authentication), which makes the stronger authentication useless.
> > 
> 
> The stronger authentication is not useless, it complements and strengthens
> the user authentication. While identifying "weakest links" in security 
> systems is very important it does not mean that you should give up 
> on providing  multiple lines of defense.
> 
> Moreover, a user's memorizable secret is in some cases harder to find than
> a strong secret key stored in a machine. The latter can be found if you 
> steal a machine while for finding the user's secret you may need to use a
> gun...
> 
> These measures are complementary and their combination adds to the 
> security of a system.
>  

I guess, here we are debating fundamental cryptographic priniciples.
If you are protecting the stronger authentication based on a weaker
authentication, then if the attacker breaks the weaker authentication,
then there is no use of the stronger authentication. But, if these are
independent, IE, if you do weaker authentication, independently to a
stronger authentication, in a totally unrelated step, then I agree that
the whole system is atleast as strong as the stronger authentication, if
not a little bit more, because of the weaker authentication too.


> > 2. L2TP/IPSec solution has the flexible framework of not mandating the use
> > of PKI, to do legacy authentication. This is because, any standard form of
> > authentication supported by IKE can be used. But, in PIC, since it is
> > based on the signature authentication method in IKE aggressive mode, the
> > customer is mandated to have a PKI, which I feel is missing the basic
> > purpose of customer dissatisfaction, that lead to formation of another WG:
> > ipsra. I guess, if ipsra also mandates PKI, then customers will force us
> > to form yet another WG to deal with the fact that they are not yet ready
> > for the PKI pill.
> 
> You do not need "public-key infrastructure" for PIC.
> You need public-key operations; and that is not something people
> are complaining about or having difficulty upgrading to.
> And how is that different in your envisioned l2tp/ipsec solution?
> 

Needing to do public key operations without a PKI only translates to a
deployment/management nightmare, and that is the main cause of
frustration, because, it doesn't scale without PKI and PKI as it exists
today sucks. 

In L2TP/IPSec solution, we can do any standard IKE authentication method,
and this could mean pre-shared keys.

> > 
> > 3. In PIC, since the whole process of authentication is predicated on the
> > first authentication, and this first authentication can be considered as
> > "user authentication" based on legacy authentication systems, there is no
> > real scope for a good "machine authentication" (I am assuming the common
> > sense definitions of "user authentication" Vs "machine authentication", as
> > opposed to the cryptographic one, which I am not aware of). Since, in
> > L2TP/IPSec, the two stages of authentication are independent to the most
> > part (although the second authentication is protected by the first), we
> > could do "machine authentication" in IKE, and do "user authentication" in
> > L2TP.
> 
> PIC with added machine authentication provides, at least, as good
> authentication as l2tp/ipsec, and contrary to l2tp/ipsec it achieves
> the good authentication:
> 
> * without changing IKE
> * without adding any new layers to the ipsec network-layer protocols
> * allowing for a clean deployment path towards PKI-based user certificates
> 
> Hugo

PIC is a protocol that only exists with a minimal/incomplete/vague
specification in an IETF draft.

L2TP is well defined, well understood, RFC, and has been already
implemented by multiple vendors. I don't want to dive it this too much,
because the L2TP guys can provide relevant details better than me.

In terms of migration to PKI, the migration to PKI, provided in IKE via,
pre-shared keys still holds in the case of L2TP/IPSec. It is just that,
L2TP provides an additional legacy authentication step, that can be
considered as a 2 step, double independant authentications mechanism.

If you want to do public key operations without PKI, then IKE as it exists
today, supports that too.

> 
> PS: here is a succint explanation about how to achieve machine
> authentication in PIC:
> 
> The curent description of the PIC protocol in draft-ietf-ipsra-pic-00.txt
> starts with messages:
> 
>    1. The Client sends: HDR, SA, KE, Ni
>    2. The AS sends: HDR, SA, KE, Nr, IDr1,[ CERT, ] SIG_R
> 
> To provide optional machine authentication one has to add an optional 
> third message of the form
> 
>        The client sends: HDR, [ CERT, ] IDi1, SIG_I,
> 
> Where IDi1 and CERT are machine's attributes. If you want to provide
> machine's identity protection change HDR to HDR*.
> 
> The rest of the protocol is untouched.
> 
> 
> 

Yeah, previously you needed that only the server needs to authenticate
using public key operations, so people have to provision the public key of
the server on all the clients, and if they want to verify the public key
via a cert, then all the clients have to have the certificate of the CA
server (which could be the AS), and the AS.

Now, if they want to do this additional optional step, then you need to
have the public keys of all the clinets on the server, before hand, and if
certs are used, then you need the certs too.

Now, the client has to first verify that he is talking to an AS, via the
signature of the AS, and then he will use an optioanl authentiction step
to authenticate himself to the AS with another signature, and then he will
get his cert if he doesn't have one, and then the client will authenticate
to the legacy athentication server, and then the server and client will
again authenticate themselves in Phase1 of IKE, possibly using another set
of signatures!

Yes, I agree PIC doesn't change IKE, but it is duplicating the IKE
standard, and adding legacy authentication to it.

    chinna

chinna narasimha reddy pellacuru
s/w engineer