Re: L2TP is ipsra solution (?)

[Hugo Krawczyk <hugo@xxxxxxxxxxxxxxxxx>]

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.

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

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.

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

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

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.