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

RE: xauth requirements: vulnerabilities

Hi Scott,

XAUTH was never intended to solve the vulnerabilities which you have
enumerated.  I will attempt to clarify it's intent.

The purpose of XAUTH is to give a migration path to those people who have
huge infrastructures that rely on RADIUS and other authentication mechanisms
to do their day-to-day business.  These people would like to start using
IPSec, but can't (and won't) substitute their entire RADIUS infrastructure
overnight.  Some will deploy a PKI and still use some of the RADIUS tools to
do their accounting, logging, and even authentication.  Some will simply use
a shared secret along with XAUTH for authentication only.  To these people
we must say "Be extremely careful not to bypass IKE's security by choosing a
weak shared secret".  And I can assure you, this will be in our
documentation probably in bold and underlined three times.

So I would say that the requirements are not what you have listed below but
rather:
"Provide the customer with a mechanism which will allow the use of legacy
authentication schemes in conjunction with IPSec, while not diminishing the
security of IPSec itself."

Some have argued that XAUTH does diminish the security of IPSec by giving
security administrators a false sense of security, and allowing them to
choose a weak shared secret (which they could do with or without XAUTH).  To
prevent this, an implementation could easily restrict the network admin from
using a "global" shared secret.  You could also force them to use "good"
shared secrets with FIPS 112.  You could even go as far as forcing them to
change their shared secret every day... although I'm sure you'd hear about
it.

I don't want people to think that what we're trying to solve is what you've
listed below, although they are problems which I'm sure is of interest to
everyone on this list.

Regards,
Stephane.

> -----Original Message-----
> From: Scott G. Kelly [mailto:skelly@redcreek.com]
> Sent: Wednesday, July 28, 1999 12:27 PM
> To: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org; Beaulieu, Stephane;
> Pereira, Roy; Tamir Zegman
> Subject: xauth requirements: vulnerabilities
> 
> 
> Sorry to keep hammering on this, but we need to make sure we've fully
> specified the requirements before we can reasonably discuss 
> the efficacy
> of the proposed solution. I invite the various xauth and xauth/hybrid
> authors to contribute to this discussion, since you are the ones
> proposing solutions.
> 
> So far, the following vulnerabilities have been identified in 
> scenarios
> entailing using ipsec for remote access:
> 
> (1) A system containing either a password (preshared key) or 
> private key
> may be stolen, and the thief may now use the system to impersonate the
> owner, and access protected resources.
> 
> (2) A system containing either a password (preshared key) or 
> private key
> may be otherwise compromised in such a way as to give the attacker
> access to the password or private key, without the owners knowledge.
> This means that either a backup containing the information is
> stolen/copied, a copy of the system is somehow made without the owners
> knowledge, or the keys are somehow directly extracted. This 
> information
> could be used to access protected resources directly, or to mount a
> man-in-the-middle attack on subsquent remote access sessions.
> 
> (3) Rogue software may be installed on the system without the owners
> knowledge which monitors the user's typing and/or other aspects of any
> online session.
> 
> Are there other vulnerabilities?
> 
> Scott
>
Follow-Ups: