From patchwork Wed Jul 8 15:00:57 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: David Woodhouse X-Patchwork-Id: 492973 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from maxx.maxx.shmoo.com (maxx.shmoo.com [205.134.188.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 73A9A1402B5 for ; Thu, 9 Jul 2015 01:01:27 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by maxx.maxx.shmoo.com (Postfix) with ESMTP id D49349D26F; Wed, 8 Jul 2015 11:01:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at maxx.shmoo.com Received: from maxx.maxx.shmoo.com ([127.0.0.1]) by localhost (maxx.shmoo.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zq3CfNZJnNl2; Wed, 8 Jul 2015 11:01:24 -0400 (EDT) Received: from maxx.shmoo.com (localhost [127.0.0.1]) by maxx.maxx.shmoo.com (Postfix) with ESMTP id A2D3617C14B; Wed, 8 Jul 2015 11:01:09 -0400 (EDT) X-Original-To: mailman-post+hostap@maxx.shmoo.com Delivered-To: mailman-post+hostap@maxx.shmoo.com Received: from localhost (localhost [127.0.0.1]) by maxx.maxx.shmoo.com (Postfix) with ESMTP id 67BEE17C147 for ; Wed, 8 Jul 2015 11:01:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at maxx.shmoo.com Received: from maxx.maxx.shmoo.com ([127.0.0.1]) by localhost (maxx.shmoo.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhXiaAnQyfZj for ; Wed, 8 Jul 2015 11:01:01 -0400 (EDT) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by maxx.maxx.shmoo.com (Postfix) with ESMTPS id D7F499D26A for ; Wed, 8 Jul 2015 11:01:00 -0400 (EDT) Received: from i7.infradead.org ([2001:8b0:10b:1:225:64ff:fee8:e9df]) by casper.infradead.org with esmtpsa (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZCqqI-0001DU-89; Wed, 08 Jul 2015 15:00:58 +0000 Message-ID: <1436367657.15083.45.camel@infradead.org> Subject: Re: Unable to connect to WPA2-Enterprise since 2.4-r1: WPA_ALG_PMK bug? From: David Woodhouse To: Jouni Malinen , hostap@lists.shmoo.com, dcbw@redhat.com Date: Wed, 08 Jul 2015 16:00:57 +0100 In-Reply-To: <20150504204621.GA11344@w1.fi> References: <553E3168.9030005@ramses-pyramidenbau.de> <20150427133417.GA19612@w1.fi> <553E5D67.2030700@ramses-pyramidenbau.de> <20150503191444.GA29243@w1.fi> <5547A57D.9000705@ramses-pyramidenbau.de> <20150504204621.GA11344@w1.fi> X-Mailer: Evolution 3.16.3 (3.16.3-2.fc22) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html X-BeenThere: hostap@lists.shmoo.com X-Mailman-Version: 2.1.11 Precedence: list List-Id: HostAP Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hostap-bounces@lists.shmoo.com Errors-To: hostap-bounces@lists.shmoo.com On Mon, 2015-05-04 at 23:46 +0300, Jouni Malinen wrote: > On Mon, May 04, 2015 at 06:59:41PM +0200, Ralf Ramsauer wrote: > > Freeradius 2.2.6 fails to connect with > > > > May 04 17:43:03 lefay wpa_supplicant[642]: nl80211: Unexpected > > encryption algorithm 5 > > That message has nothing to do with this issue. The real error is > identified by the "RSN: no PMKSA entry found - trigger full EAP > authentication" message following the EAP exchange. In practice, this > indicates that the authentication server and wpa_supplicant derived > different MSK from the EAP authentication. Right. Almost certainly because it has the same problem as FreeRADIUS 2.2.6, and uses the wrong PRF for TLS 1.2. Since Fedora updated to wpa_supplicant 2.4, I'm now getting reports from across the company that access to the corporate wifi is failing. I've internally shipped a version of wpa_supplicant with commit 35efa2479f reverted for now, to get people working. I believe we're using Cisco ISE; I'm talking to the IT people to confirm that, and the version — obviously with a view to getting it fixed, but this being Cisco it could take *months* before we even manage to get them to reproduce it in-house and accept that it's a problem¹. > > But keep in mind, in most cases people do not have access to the wifi > > backend :) > > Maybe so, but the real issue here was in the authentication server and > there is not really much that the client side can do to fix that. Well.... this "works": Now, obviously I'm not suggesting that as a viable solution. But perhaps it points to a potential workaround. What if we calculate *both* the incorrect and the correct PMK, and add *both* to the PMKSA cache in wpa_supplicant_get_pmk()? Then it'll silently work with both broken and sane authenticators. Obviously that's *horrid*, and I'm going to have to autoflagellate for even thinking it. We'd only even want to contemplate it if the problem really is widespread enough to warrant such. There really *is* a lot of merit in saying "Your kit is crap. Get something better from someone who actually provides decent support." A variant on this workaround idea is that we don't just add the 'wrong' one to the PMKSA cache, but we add some kind of 'poison' instead, which if matched will trigger a fallback to TLSv1.1. But given that falling back to TLSv1.1 will cause us to use the old PRF *anyway*, it's not clear that there's any real benefit in doing it that way instead... --- a/src/crypto/tls_openssl.c +++ b/src/crypto/tls_openssl.c @@ -2648,7 +2648,7 @@ int tls_connection_prf(void *tls_ctx, struct tls_connection *conn, const char *label, int server_random_first, u8 *out, size_t out_len) { -#if OPENSSL_VERSION_NUMBER >= 0x10001000L +#if 0// OPENSSL_VERSION_NUMBER >= 0x10001000L SSL *ssl; if (conn == NULL) return -1;