Bugtraq mailing list archives
Re: Multiple vulnerabilites in vendor IKE implementations, including Cisco,
From: Thor Lancelot Simon <tls () rek tjls com>
Date: Fri, 12 Dec 2003 23:15:05 -0500
[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
Current thread:
- Multiple vulnerabilites in vendor IKE implementations, including Cisco, Thor Lancelot Simon (Dec 12)
- Message not available
- Message not available
- Re: Multiple vulnerabilites in vendor IKE implementations, including Cisco, Thor Lancelot Simon (Dec 13)
- Message not available
- Message not available
- Re: Multiple vulnerabilites in vendor IKE implementations, including Cisco, Sharad Ahlawat (Dec 13)
- Re: Multiple vulnerabilites in vendor IKE implementations, including Cisco, Thor Lancelot Simon (Dec 13)
- Re: Multiple vulnerabilites in vendor IKE implementations, including Cisco, Chris (Dec 19)
- Re: Multiple vulnerabilites in vendor IKE implementations, including Cisco, Sharad Ahlawat (Dec 19)