From patchwork Thu Feb 14 12:46:53 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mikael Kanstrup X-Patchwork-Id: 1042103 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.infradead.org (client-ip=2607:7c80:54:e::133; helo=bombadil.infradead.org; envelope-from=hostap-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=sony.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="hZHQ/WAN"; dkim-atps=neutral Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 440bl00Kl0z9s7h for ; Thu, 14 Feb 2019 23:47:24 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:Subject:To :From:Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=kqgc6iLCTxLLxZZ11eVOtdF7Urh11Zu1aI7HmhNY5qw=; b=hZHQ/WANMdozrr M926ZvC4XCjSieL6HDFICpX/otq61CCxDYkXr2MuQNS5DWsQXyZxBuMjA48ly3Kfg09PQIIklwWeG UqAyUyFSY8w1wGjvafL2IDtWWVdHlzdidHZq5Z3ECGrhlZc/Pr5TXrtxuiWue8O9o0l5AFf++jJDt LmLmWVgM4hcFk5bt7xHJUWo9tfWeypQimWcGrJQSRSoU18SstRqcjT1Xp5CJ3uvZlhYo8pJmtDsug PKlut3GzOb08wYSfVEpiII6z6VDd7k52zluZSq065vDYEuaIhVvhX293yQRJSgCXrkguHFhmzhpeH uCiP0W9pGpKhZhb2lADw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1guGQ4-0006Yo-8g; Thu, 14 Feb 2019 12:47:12 +0000 Received: from seldsegrel01.sonyericsson.com ([37.139.156.29]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1guGQ0-0006TO-Ve for hostap@lists.infradead.org; Thu, 14 Feb 2019 12:47:11 +0000 From: Mikael Kanstrup To: Subject: [RFC] PMF: Allow Key ID in big endian format to workaround faulty APs Date: Thu, 14 Feb 2019 13:46:53 +0100 Message-ID: <20190214124653.24793-1-mikael.kanstrup@sony.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190214_044709_169581_39036871 X-CRM114-Status: UNSURE ( 7.15 ) X-CRM114-Notice: Please train this message. X-Spam-Score: -2.3 (--) X-Spam-Report: SpamAssassin version 3.4.2 on bombadil.infradead.org summary: Content analysis details: (-2.3 points) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [37.139.156.29 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record X-BeenThere: hostap@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Hostap" Errors-To: hostap-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org From: Daisuke Niwa A few APs out on the market have got the byte order of IGTK key index wrong making PMF enabled connections fail to connect. The faulty APs request STAs to configure IGTK with key ID value 1024 or 1280. IEEE Std 802.11-2016 Chapter 9.4.2.55 "Management MIC element" define the key ID to be either 4 or 5. All other key IDs are reserved. Out of spec values get rejected by lower cfg80211 layer set key operation which in turn brings the connection down. Looking more closely into the values requested, 4 and 5 in 16-bit network byte order/big endian byte order happens to correspond to 1024 and 1280 respectively in wireless little endian byte order. As connect attempts using out of spec values will anyway fail detect and workaround the problem by reading the incorrect values in big endian format. Signed-off-by: Mikael Kanstrup --- src/rsn_supp/wpa.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/rsn_supp/wpa.c b/src/rsn_supp/wpa.c index 86593ab78..32b9b9326 100644 --- a/src/rsn_supp/wpa.c +++ b/src/rsn_supp/wpa.c @@ -1024,6 +1024,12 @@ static int wpa_supplicant_install_igtk(struct wpa_sm *sm, { size_t len = wpa_cipher_key_len(sm->mgmt_group_cipher); u16 keyidx = WPA_GET_LE16(igtk->keyid); + if (keyidx == 1024 || keyidx == 1280) { + /* Workaround incorrectly behaving APs that send Key ID in big endian format */ + wpa_printf(MSG_INFO, "PMF: Workaround - Allow Key ID in big endian format(%d)", + keyidx); + keyidx = WPA_GET_BE16(igtk->keyid); + } /* Detect possible key reinstallation */ if ((sm->igtk.igtk_len == len &&