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

Re: xauth requirements: vulnerabilities



Stephane and the rest,

Hello.

I am an implementor trying to decide whether or not I need to support RADIUS
Authentication in IKE via XAUTH.  I have been reading this entire thread (and
sub-threads, and ancillary threads) with great interest.

Marketing tells me that I need to support XAUTH, particularly with SecureID, and
so I might have to implement it anyway, but standardization should have higher
bar.

I personally don't see how supporting XAUTH/RADIUS provides an easy migration
path when I still have to specify an entropy-filled shared secret for each
user.  How is this less work than just specifying that entropy-filled shared
secret once?

If, however, the argument is made that supporting XAUTH/RADIUS *and* the
entropy-filled shared secret is more secure, then I can understand.  And I think
that's what Scott is trying to do.

But as much as I'd like to, I just can't see the "migration path" argument,
unless you use a global shared secret for phase 1.  If we're migrating to PKI,
and XAUTH is not more secure than pre-shared secrets, then the proper migration
path is to use pre-shared secrets and gradually phase in PKI.  Why add the extra
infrastructure of XAUTH if it doesn't buy you anything?

I think we need to really start a discussion on our requirements, and I think
Scott has started us down that path.

Stephane Beaulieu 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.
>
> 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
> >
begin:vcard 
n:Fox;Daniel
tel;fax:978-263-1099
tel;work:978-263-2002
x-mozilla-html:FALSE
url:http://www.ennovatenetworks.com
org:Ennovate Networks
adr:;;330 Codman Hill Road;Boxborough;MA;01719;USA
version:2.1
email;internet:dfox@ennovatenetworks.com
title:Senior Software Engineer
fn:Daniel Fox
end:vcard

References: