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

Re: xauth requirements: vulnerabilities

  Stephane,

  Your description of XAUTH is very disingenous.

  Since the whole point of someone using XAUTH is because they do not
want to deploy a PKI let's dismiss forever the notion that the IKE SA can 
be authenticated with a certificate and the two parties can proceed to
XAUTH. You even admit this. It's for people who "can't (and won't) deploy
a PKI". So that means you're stuck with pre-shared keys to authenticate
the IKE SA.

  You can say in the largest font possible and underlined as much as you
want, "Be extremely careful not to bypass IKE's security by choosing a
weak shared secret" but the very use of this pre-shared key will make
it weak! There is a fundamental limit in IKE that to use pre-shared
keys (with Main Mode) means that the pre-shared key is bound to an IP
address. Since you cannot know the IP address of these remote clients
a priori you MUST use a shared group secret. That is by definition weak.

  FIPS 112 deals with passwords that are personal. You cannot use a FIPS 112
password in this environment. You also cannot go around changing the password
every day because you'd orphan all the people out on the road (unless you
somehow announced to all what the new "secret" was so they could update 
their laptops but the problem with that is, I hope, obvious). I don't know
how you can say such things as "an implementation could easily restrict the 
network admin from using a 'global' shared secret" when you know that that 
is impossible.

  If a requirement of XAUTH is to provide legacy authentication without
"diminishing the security of IPSec itself" please tell me how you intend
to do this? 

  The real problem I see with XAUTH is that it promotes and encourages
and legitimizes an insecure use of IKE and IPSec.

  Dan.

On Wed, 28 Jul 1999 13:30:18 EDT you wrote
> 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.
Follow-Ups: References: