RE: l2tp as ipsra solution

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

On Thu, 15 Jun 2000, Andrew Krywaniuk wrote:

> >From an elegance point of view, I think the nicest solution would be to
> modify the legacy authentication database to provide an interface to
> retrieve the credential for the session (or some transform of the
> credential). Then we could directly authenticate the user during the phase 1
> exchange without having to use machine certificates or pre-shared keys.
> 
> But of course that is not a realistic solution. Hybrid authentication
> provides basically this same functionality at the expense of some DoS
> resistance in AM.

It is not the same functionality as Hybrid authentication that is being
proposed. The above proposal does bi-directional authentication using
Standard IKE, and doesn't need anohter phase like Xauth to do the other
half of user authentication.

> 
> XAuth, when used in non-Hybrid mode, will authenticate both the user and the
> machine. What is the proposal for doing this with user certs? Sign with
> both?
> 

How can XAuth be used to authenticate the machine?

    chinna


> Andrew
> --------------------------------------
> Beauty with out truth is insubstantial.
> Truth without beauty is unbearable.
> 
> 
> > -----Original Message-----
> > From: owner-ietf-ipsra@xxxxxxxxxxxxx
> > [mailto:owner-ietf-ipsra@xxxxxxxxxxxxx]On Behalf Of Ben McCann
> > Sent: Wednesday, June 14, 2000 9:47 AM
> > To: Dan Harkins
> > Cc: Sara Bitan; Ricky Charlet; IPSRA list
> > Subject: Re: l2tp as ipsra solution
> >
> >
> > Dan Harkins wrote:
> > >
> > > On Tue, 13 Jun 2000 10:28:19 EDT you wrote
> > > >
> > > > I also agree that IPSRA must provide a mechanism to
> > incrementally deploy
> > > > PKI in a customer base that has a substantial investment
> > in older user
> > > > authentication mechanisms such as Radius or Secure ID. To
> > this end, IPSRA
> > > > needs to identify a spectrum of user authentication
> > environments that must
> > > > be supported. I'd like to suggest the following set of
> > options that any
> > > > IPSRA candidate protocol must support. ('Machine' is the
> > remote user's
> > > > PC and 'user' is the remote user himself).
> > > >
> > > > Option                Machine Authentication
> > User Authentication
> > > >
> > > >   1                   None                            Password
> > > >
> > > >   2                   None                            Secure ID
> > > >
> > > >   3               Certificate                         Password
> > > >
> > > >   4               Certificate                         Secure ID
> > > >
> > > >   5               Certificate                         Certificate
> > > >
> > > > I included option 5 based on your earlier email.
> > > >
> > > > Note that option 1 and 2 do _not_ require machine
> > authentication. My
> > > > customers are often satisifed by that because its really
> > the _user_ that
> > > > they wish to authenticate. I believe IPSRA must support
> > options 1 and
> > > > 2 in conjunction with IKE until the customer deploys
> > machine certificates.
> > >
> > > Options 1 and 2 do not provide any authentication of the
> > keying material,
> > > are probably unidirectional, and are probably susceptible
> > to a man-in-the-
> > > middle attack because without doing "machine
> > authentication" you're left
> > > with an unauthenticated Diffie-Hellman exchange over which
> > you pass a
> > > password or token card response.
> > >
> > > Your customers may be satisfied with that but satisfying
> > these types of
> > > customers is not in the charter of this working group.
> > >
> > >   Dan.
> >
> > I specifically did _not_ address authentication of the
> > security gateway.
> > Yes, options 1 and 2 provide unidirectional authentication of the USER
> > but that does not imply the user's machine is unable to authenticate
> > the security gateway. The beauty of Hybrid Auth is that it is
> > _asymmetric_.
> > The remote user's machine uses the security gateway's certificate to
> > authenticate the security gateway.
> >
> > You are correct that a man-in-the-middle attack can be
> > mounted that can
> > not be detected by the security gateway. This is discussed in
> > the Hybrid
> > Auth draft which states that the remote user's machine _must_ drop the
> > session if the security gateway (i.e. the man-in-the-middle attacker)
> > fails to prove it possesses the private key.
> >
> > -Ben McCann
> >
> > --
> > Ben McCann                              Indus River Networks
> >                                         31 Nagog Park
> >                                         Acton, MA, 01720
> > email: bmccann@xxxxxxxxxxxxxx           web: www.indusriver.com
> > phone: (978) 266-8140                   fax: (978) 266-8111
> >
> 
> 

chinna narasimha reddy pellacuru
s/w engineer