Re: Authentication Mechanism Matrix (was L2TP vs IPSEC)

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

Consider this model:

You add anohter AV pair to whatever legacy authentication server you are
using today, like a IKE-Pre-Shared-Key attribute. Now, we fetch the
pre-shared key from the legacy authentication server, and do the IKE
pre-shared key authentication in a way that it is not vulnerable to
passive off-line dictionary attacks. This will do the authentication of
the user in a way that IPSRA wants.

Now you use L2TP to do the configuration/authorization/accounting. We can
turn off the authentication part in PPP at this stage, because we have
already authenticated the user, along with the SA parameters, and also the
DH.

I don't see why we need to go the path of doing a pre-IKE phase, where we
have to eactly do whatever the legacy systems have been doing since ages,
like even supporting even PAP and CHAP.

>From a customer/user perspective the above proposal provides the exact
security that PIC is trying to provide from a cryptographic perspective.

And I think this proposal has the minimum impact, because I think people
add new AV pairs atleast on a monthly basis, if not on a daily basis. This
proposal doesn't need any new protocols atleast from an IKE/IPSec point of
view, and may infact be considered a new way of implementing pre-shared
keys.

I guess the basic argument is that to let IKE do what it does best, the
authentication part, and let the legacy system do what it does best, which
is authorization/configuration/accounting.

    chinna

On Wed, 21 Jun 2000, Ben McCann wrote:

> Chinna:
> 
> [RANT ON]
> 
> > The best possible deployment path would be to use the legacy
> > authentication secret as the IKE pre-shared secret, and in this scheme,
> > the customer doesn't have to even write a new protocol, and then remove it
> > later on.
> 
> This is _not_ possible because legacy authentication servers (such as
> Radius or Ace) don't implement IKE authentication. The NAS or Security
> Gateway presents the users credentials to Radius or Ace and gets back
> PASS or FAIL. These credentials can include:
> 
> 1. Name and Password (i.e. for PAP)
> 
> 2. Name, Challenge, and Response (i.e. for CHAP or MSCHAP)
> 
> 3. Name, Password, and PIN (for Secure ID or other token cards).
>    (An ACE server for Secure ID can re-challenge and ask for the
>    next PIN thus _another_ PIN value has to obtained from the user).
> 
> None of these is possible with IKE because the original pre-shared
> key can _not_ be extracted from the HASH payloads exchanged by IKE
> and thus it can't be presented to a legacy Radius Server as a password.
> 
> It would be possible to add another authentication algorithm to Radius
> for IKE pre-shared keys where the Radius server computes the expected
> HASH from the user's ID, nonces, etc, but that violates the requirement
> of legacy authentication protocol compatibility. And, even if you did
> this, it would not be compatible with Secure ID due to the requirement
> to challenge for the NEXT pin number. Said challenge would require
> another round of IKE packet exchanges.
> 
> I also disagree with your statement:
> 
> > As I pointed out before, any customer who is still using a legacy
> > authentication system that is vulnerable to passive off-line attacks is
> > not going to migrate to IPSec anytime in the foreseeable future.
> 
> We have converted companies that had 1000's of remote access users 
> from dial-up RAS to VPN RAS. The legacy authentication system was fine
> for dial-up. The IPSRA group's charter (IMHO) is to make those legacy
> authentication systems secure for VPN too.
> 
> [RANT OFF]
> 
> -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