[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: l2tp as ipsra solution
>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.
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?
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
>