Re: Multiple vulnerabilites in vendor IKE implementations, including Cisco,
From: Thor Lancelot Simon (tls_at_rek.tjls.com)
Date: 12/13/03
- Previous message: Thor Lancelot Simon: "Re: Insecure IKE Implementations Clarification"
- Maybe in reply to: Thor Lancelot Simon: "Multiple vulnerabilites in vendor IKE implementations, including Cisco,"
- Next in thread: Sharad Ahlawat: "Re: Multiple vulnerabilites in vendor IKE implementations, including Cisco,"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 12 Dec 2003 23:15:05 -0500 To: bugtraq@securityfocus.com
[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
- Previous message: Thor Lancelot Simon: "Re: Insecure IKE Implementations Clarification"
- Maybe in reply to: Thor Lancelot Simon: "Multiple vulnerabilites in vendor IKE implementations, including Cisco,"
- Next in thread: Sharad Ahlawat: "Re: Multiple vulnerabilites in vendor IKE implementations, including Cisco,"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
