Re: l2tp as ipsra solution

[Ben McCann <bmccann@xxxxxxxxxxxxxx>]

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