From patchwork Sun Jan 22 10:26:12 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jouni Malinen X-Patchwork-Id: 137221 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 DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "maxx.shmoo.com", Issuer "CA Cert Signing Authority" (not verified)) by ozlabs.org (Postfix) with ESMTPS id D6745B6FA5 for ; Sun, 22 Jan 2012 21:26:29 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by maxx.maxx.shmoo.com (Postfix) with ESMTP id F34B79C206; Sun, 22 Jan 2012 05:26:24 -0500 (EST) 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 pGN5hD7FBrzU; Sun, 22 Jan 2012 05:26:24 -0500 (EST) Received: from maxx.shmoo.com (localhost [127.0.0.1]) by maxx.maxx.shmoo.com (Postfix) with ESMTP id C6B7D9C207; Sun, 22 Jan 2012 05:26:20 -0500 (EST) 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 CF3F29C207 for ; Sun, 22 Jan 2012 05:26:19 -0500 (EST) 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 b8nRkmd8V-LU for ; Sun, 22 Jan 2012 05:26:15 -0500 (EST) Received: from jmalinen.user.openhosting.com (w1.fi [128.177.27.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by maxx.maxx.shmoo.com (Postfix) with ESMTPS id 2575F9C206 for ; Sun, 22 Jan 2012 05:26:15 -0500 (EST) Received: from jm (a88-112-110-150.elisa-laajakaista.fi [88.112.110.150]) (authenticated bits=0) by jmalinen.user.openhosting.com (8.13.8/8.13.8) with ESMTP id q0MAQCdK013591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 22 Jan 2012 05:26:13 -0500 Received: by jm (sSMTP sendmail emulation); Sun, 22 Jan 2012 12:26:12 +0200 Date: Sun, 22 Jan 2012 12:26:12 +0200 From: Jouni Malinen To: hostap@lists.shmoo.com Subject: Re: hostapd: RSN 4-way handshake issue with Cisco WET200 client Message-ID: <20120122102612.GB5805@w1.fi> Mail-Followup-To: hostap@lists.shmoo.com References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: hostap@lists.shmoo.com X-Mailman-Version: 2.1.9 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, Jan 16, 2012 at 02:19:00PM +0100, Helmut Schaa wrote: > I've got a strange problem with a Cisco WET200 wireless bridge connecting > to a hostapd AP. The AP is configured as WPA2-CCMP and the 4-way HS > looks like this: > > 1of4: KeyDescriptor=2 (RSN) > 2of4: KeyDescriptor=2 (RSN) > 3of4: KeyDescriptor=2 (RSN) > 4of4: KeyDescriptor=254 (WPA) ??? Well, that sucks. It's unfortunate if that type of broken implementations are deployed in large number. > Of course this appears to be a pure client issue but other APs accept that > strange 4of4 message. Anything based on hostapd prior to May 2009 would have accepted that.. > Jouni, would it be ok to relax the constraints a bit and allow a WPA > descriptor type to be used also for WPA2? It looks like we need to do that taken into account that this issue has apparently been reported with number of deployed devices. I would have preferred not doing this, but well, since lack of the validation should not open security issues, I committed the following change as a workaround for interoperability issues. Could you please confirm that it resolves the issue with the station device you tested with? commit 74590e710f65134522b9a654609ac38d0ce54852 Author: Jouni Malinen Date: Sun Jan 22 12:23:28 2012 +0200 Work around interop issue with WPA type EAPOL-Key 4/4 in WPA2 mode Some deployed station implementations seem to send msg 4/4 with incorrect type value in WPA2 mode. Add a workaround to ignore that issue so that such stations can interoperate with hostapd authenticator. The validation checks were added in commit f8e96eb6fd960a017793942cff0eb43b09f444c6. Signed-hostap: Jouni Malinen diff --git a/src/ap/wpa_auth.c b/src/ap/wpa_auth.c index 9da5609..c4d77bf 100644 --- a/src/ap/wpa_auth.c +++ b/src/ap/wpa_auth.c @@ -795,7 +795,14 @@ void wpa_receive(struct wpa_authenticator *wpa_auth, } if (sm->wpa == WPA_VERSION_WPA2) { - if (key->type != EAPOL_KEY_TYPE_RSN) { + if (key->type == EAPOL_KEY_TYPE_WPA) { + /* + * Some deployed station implementations seem to send + * msg 4/4 with incorrect type value in WPA2 mode. + */ + wpa_printf(MSG_DEBUG, "Workaround: Allow EAPOL-Key " + "with unexpected WPA type in RSN mode"); + } else if (key->type != EAPOL_KEY_TYPE_RSN) { wpa_printf(MSG_DEBUG, "Ignore EAPOL-Key with " "unexpected type %d in RSN mode", key->type);