[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: xauth requirements: vulnerabilities
I can use public-key cryptography in a closed system without deploying PKI.
I can use public-key, or PKI AND XAUTH to suit certain requirements.
I can use per-user pre-shared secrets without knowing the client IP address.
I can use long, difficult pre-shared secrets without needed the client to
remember them.
XAUTH can be more secure than PKI.
PKI can be more secure than XAUTH.
I think XAUTH may be useful in the following ways:
1) per-user pre-shared secret, used with Aggressive mode, backed up by a
secure legacy authentication, e.g. SecurID tokens.
Main reason: Because the customer is happy with their investment in the
legacy method and wants to use the same method for traditional RAS and VPN.
The added benefit is that the token card can't be cracked off-line - it
doesn't know what the secret, so it can't tell it to you.
Now, this off-line exposure could be 'fixed' just with pre-shared, if the
client software did the right thing, i.e. challenge for a passphrase to
unlock the pre-shared, derive a key, unencrypt the pre-shared, and just use
whatever it recovers, without having anyway to verify it (e.g. hash
signature). This would mean that the client would not know when you had
answered the question correctly and prevent off-line hacking. The problem is
that this relies on the implementation.
But, the file containing the pre-shared secret could be worked-on off-line,
and I once I hit a string of ASCII, I have probably got the key.
2) per-user certificates, with XAUTH to reduce off-line cracking exposure.
Main reason: Customers that are concerned about the possible off-line
cracking exposure of
software-loaded certificates or Smartcards.
For the software-loaded case, I guess the client could provide the same
'dumb' attitude to the unlock passphrase, using whatever becomes of the
private key once processed with the passphrase to attempt Phase1
authentication. The problem is that the files containing the private key
could be worked-on directly, and I would know when I had the right answer
because there is a reasonable chance I get access to the matching public key
for verification, so the 'dumb' approach does not help for certificates
either.
For Smartcards that can defend themselves/self destruct, we may have a goer,
but there have been concerns expressed on this list about the security of
Smartcards. Basically, all the information to access the network is in there
somewhere....
3) whatever Phase1 authentication for 'device' authentication, and XAUTH for
per-user.
Main reason: This may be common, I guess. If there is no simple way for me
to load a private certificate into a borrowed or shared device, this is not
a bad answer. I have a private token card and can use shared devices.
Smartcards would fix this one, but at the moment, the customer has SecurID
tokens cards.
So, in conclusion, strong legacy auth does seem to offer help in the face of
off-line hacking, and point 3) just plain wants to carry on using old stuff
because it's convenient.
When I would not use XAUTH (with current IKE auth offerings):
1) with 'private public' key.
2) with 'secure' Smartcards devices that have a very low risk of being
cracked off-line, and ideally have some bio reader to prevent me having
passwords that could get written down.
Steve.
-----Original Message-----
From: Dan Harkins [mailto:dharkins@network-alchemy.com]
Sent: Wednesday, July 28, 1999 8:02 PM
To: Stephane Beaulieu
Cc: Scott G. Kelly; ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org; Roy
Pereira; Tamir Zegman
Subject: 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.