[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
