bugtraq - Re: Multiple vulnerabilites in vendor IKE implementations, including Cisco,

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Fri, 12 Dec 2003 23:15:05 -0500
From: Thor Lancelot Simon <tls@....tjls.com>
To: bugtraq@...urityfocus.com
Subject: Re: Multiple vulnerabilites in vendor IKE implementations, including Cisco,

[Another list response, with permission, to an off-list response to my
 original message.  I think this one will be generally interesting, thus
 the carbon to the list...]

On Fri, Dec 12, 2003 at 07:34:31PM -0500, Gary Flynn wrote:
> 
> 
> Thor Lancelot Simon wrote:
> 
> 
> >	ISSUE 2: USE OF THE IETF-REJECTED "XAUTH" IKE EXTENSION WITH
> >	IKE ITSELF AUTHENTICATED ONLY BY A PRESHARED KEY SHARED BY MORE
> >	THAN TWO PARTIES  (A.K.A. "THE 'GROUP PASSWORD' OR 'XAUTH' HOLE).
> 
> Hi,
> 
> One mitigation technique would be to install a certificate
> in a concentrator and configure the clients to only talk
> to a server with that certificate. Basically implementing
> half of a certificate based authentication system. I don't
> know if any concentrators support that though. Do you?

I've seen clients that support it, so I assume concentrators from the
same folks who wrote those clients do so.  However, unless I misremember
the XAUTH with certs Phase 1 specification, *both* sides have to have
a certificate to present, and that's what's used to secure the Phase 1
SA.  In practice, this means that nobody uses this, because if you're
going to build a CA for your clients, you might as well just use
certificate authentication and be done with it.

You _could_ dole out a single cert to all clients, and a single other
cert to the concentrator, then use XAUTH basically to discern which
authorized client you were talking to.  You would still forfeit many
desirable properties of IKE, but it would be less horrible than the
current botch.

Unfortunately, this approach may run afoul of the nasty habit of some
implementations to only validate that the cert is from the right CA,
not *which cert is actually is*, so that means problem #1 of my
message will cascade into problem #2.  If certificates are used
correctly, however, at least this way of using XAUTH is less suicidal
than the "preshared key shared between N > 2 parties" method.

Thor