RE: l2tp as ipsra solution

["Glen Zorn" <gwz@xxxxxxxxx>]

Moshe Litvin [mailto://moshe@xxxxxxxxxxxxxx] writes:

> > > As for tunneling, IPsec tunnel mode is more efficient than
> > L2TP+IPsec
> > > transport mode. I don't think that tunneling  non-IP
> > protocols is in the
> > > scope of this working group, so the ability of L2TP to tunnel non-IP
> > > protocol is irrelevant.
> >
> > So "remote access" is defined narrowly as "remote access to IP-based
> > networks"?
>
> In the context of ipsra - yes! (ipsra = IP Security Remote Access)

I must be mistaken -- I thought that I had seen discussions of a requirement
to carry non-IP protocols over IPSec (perhaps encapsulated in GRE) on this
list.  Sorry.

>
> >
> > >
> > > As for legacy authentication, it was already noted that
> > > authenticated IPsec
> > > keys must exist before the PPP authentication. Some have
> > > suggested the idea
> > > of machine keys used to authenticate IKE exchanges, and then a
> > > separate step
> > > of authenticating the user. The main benefit of this
> > separation is that we
> > > can easily solve this problem. But the general case there
> > is no separation
> > > between machine and human credentials.
> >
> > So "remote access to IP-based networks" does not include e.g.
> > a dial on
> > demand connection from a router on a home office network to a
> > central office
> > network?
>
> The question has two answers:
>
> 1. Remote access does not equal dial-up. I think that the
> problems of remote
> access are mainly from the way human interacts with the system
> then the way
> the machine connection to the internet is established. The
> problem of a user
> using dial up and of a user uses a cable modem which is connected 100% of
> the time are more similar than a dial-up user and dial on demand router.

I would think that the cable modem and dial on demand scenarios would be
much more similar, since from the point of view of a user they are both 100%
connected...

>
> 2. From the charter of the workgroup "The authenticated entity must be a
> human user, i.e. human interaction is required during the authentication
> process."
>
> >
> > >
> > > A different solution to this problem is to use the hybrid
> > mode to create
> > > one-way authentication to the IPsec keys, and then use PPP
> > authentication.
> > > This solution is forbidden according to the charter, but if we
> > > don't want to
> > > use it (or something similar) the PPP authentication abilities
> > > are useless.
> >
> > I see. So "User authentication" is useless?  Why are we talking, then?
>
> I didn't say the user authentication is useless. But the user user
> authentication of PPP in the combination L2TP+IPsec is done AFTER
> the SA are
> established. If a complete authentication was done in IKE then farther
> authentication is useless. If no authentication (or weak
> authentication) was
> done in IKE, then the PPP authentication is open to attacks, so it is
> useless (or at least have VERY limmited use).

Hmm. The only widespread implementation of L2TP/IPSec tunneling of which I'm
aware uses public key authentication in IKE.  Are you saying that this
leaves PPP authentication open to attacks?  If so, we have _big_ problems!
L2TP treats IPSec as a means to protect IP traffic on the wire; apparently
this is considered to be inappropriate and/or dangerous?

>
> There is a way to do the server authentication in IKE and the user
> authentication in PPP. But unfortunatly this method does not appear in the
> IKE RFCs and quoting again from the charter "The WG strongly prefers
> mechanisms that require no changes to AH, ESP or IKE protocols. If such
> changes are deemed necessary, the IPSec WG is contracted to carry out such
> changes"

Can you tell me what changes to IKE would be required to allow L2TP/IPSec?

> (by mistake I wrote the the charter forbeeds changes. I
> am glad to
> see that that it does not.)

I wasn't aware that the use of IPSec to protect traffic (whether
authentication-related or not) violated any RFCs, but for that matter, I
didn't know that the IKE RFCs completely defined all acceptable
authentication methods.

>
> Regards,
> 	Moshe
>
>
>