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

Re: l2tp as ipsra solution



On Tue, 13 Jun 2000, Ricky Charlet wrote:

> "CHINNA N.R. PELLACURU" wrote:
> > 
> > I don't understand the importance given to "machine authentication". I
> > haven't seen any customer requirements that requires "machine
> > authentication". Can someone please explain why "machine authentication"
> > is required? If not for over reliance on machine authentication, loss of
> > laptops in certain agencies wouldn't have made national headlines.
> > 
> > There have always been multiple levels of authentication, like even if PPP
> > has it's authentication, the variours servers had their own
> > authentication, and the Windows network had it's own authentiction, and I
> > guess customers like this multiple levels of authentication, because it
> > makes good sense to no put all the eggs in one basket.
> > 
> >     thanks,
> >     chinna
> >
> 
> 	According to my (possibly flawed) prespective, this working group is
> chartered to find a way to authenticate end users and provide associated
> keying material to IPsec transforms WITHOUT using the current
> capabilities of IKE to employ user level certificates.

I would like to get a consensus on atleast "WITHOUT using the current 
capabilities of IKE" part, and why that is required.

> 	The reasons are entirely market driven, we vendors have felt pressure
> from customers uncomfortable with migrating so suddenly away from their
> radius data bases for user authentication to an organizational level PKI
> for user authentication.

That is why L2TP cleanly seperates IKE authentication with legacy
authentication. If the customers feel that they can't trust their PKI yet,
they can still have legacy authentication. As, customers understand PKI,
and trust their PKI more, they can ultimately decide not to do legacy
authentication.

> 	Now does this represent "over reliance on machien level
> authentication". Well, yes, I think so. But still, this is our task at
> hand to accomplish, because bunches of IT managers disagree and would
> prefer to not use the current user level authentication capabilites
> already in IKE without a smoother migration path from their legacy
> authentication infrastructures.
> 

I guess, where we draw the line between "machine level authentication" and
"user level authentication" is fussy. We cannot generalize that legacy
authentication always provides user level authentication. For example if
we are using plain old pap or chap, and atleast some popular dial up
clients provide the option to the user to save their username/password.
Once the user saves the username/password, then it essentially becomes
"machine level authentication" analogous to certs saved on the machines.
And like people have already pointed out, certs need not be considered
always "machine level" authentication, because if there is a password
based protection to use the private key, then it essentially can be argued
to be "user level" authentication. Even with some implementations of
legacy one-time passwords, the one time passwords are generated by
software running on the machine itself, and the access to these passwords
are only restricted by a 4 digit pin. Bottomline, we cannot generalize,
and it actually depends on the solutions on a case-by-case basis.

I agree with the observation that:

"The IETF has several existing, open authentication frameworks
that provide an opportunity for all vendors to participate. 
Before proposing a different framework, the onus should 
be the WG to demonstrate why existing frameworks cannot be used."

    chinna

> -- 
>   Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903
> 

chinna narasimha reddy pellacuru
s/w engineer