From patchwork Thu Oct 31 09:18:58 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Wetzel X-Patchwork-Id: 1187278 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) 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=fail (p=quarantine dis=none) header.from=wetzel-home.de Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ey+8Wmkd"; dkim=fail reason="signature verification failed" (1024-bit key; secure) header.d=wetzel-home.de header.i=@wetzel-home.de header.b="DZWqZ5xT"; dkim-atps=neutral Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 473fwk1G94z9sP4 for ; Thu, 31 Oct 2019 20:22:14 +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:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=p5UmFKP/EthH2Pl7gZ+Chw1vc+WegUCe3C2czXinpYM=; b=ey+8WmkdGFw1iY WKXzqVeDMpaLVq1nW1U9Ed28t1xyrSOaUqrDfG409a1a5NHbglRWbA9PaEFmTNil1WbJ7Y5581aGK ZSqNA0UEhhbfoVl2ko/n0OPDv3iZ1jDLcMBOl54VEuDWCquqdeHGwlZhg7+p8w9WyQqhKzWzlZQRL iSglgbJrAXflfGFnzW7MMBSoLQVpRJLW4M3qt73BmghSrZsZ3aTzr8XzCKJre/RulXUli18m7jilC QFRD/7OSqi/LroV7p/gAUOP534ZkKlPXuGWxU0iehB4VzR+IDnuHIZ3unVOmw/ldrvZqEU71jL3dB KI2mmwRhmTXsSYrkRh7A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iQ6eg-0001s6-KQ; Thu, 31 Oct 2019 09:22:10 +0000 Received: from 1.mo69.mail-out.ovh.net ([178.33.251.173]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iQ6cV-0006m8-5y for hostap@lists.infradead.org; Thu, 31 Oct 2019 09:19:59 +0000 Received: from player756.ha.ovh.net (unknown [10.108.57.76]) by mo69.mail-out.ovh.net (Postfix) with ESMTP id AC0366E15E for ; Thu, 31 Oct 2019 10:19:52 +0100 (CET) Received: from awhome.eu (p4FF914F9.dip0.t-ipconnect.de [79.249.20.249]) (Authenticated sender: postmaster@awhome.eu) by player756.ha.ovh.net (Postfix) with ESMTPSA id 042E8AC8C613; Thu, 31 Oct 2019 09:19:48 +0000 (UTC) From: Alexander Wetzel DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wetzel-home.de; s=wetzel-home; t=1572513587; bh=CewQmJGvoZ/XGhyPVaaVe4QT/MNDAOCab6VnMH0bQR4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=DZWqZ5xTnRqHPKOQfIfRmQWeTc5ilByPqbyk2QZ4lWLxgAbqKl+bAWHCLRwbGWG4j J0UPhH8+FOaVFEz3CQ/ihNNR2+WR3XBBzT3/ggGw6mvmpzO0xOFDwbWwryZ1Z8S93Z 1M4goR65jibzAZUKoTu2ETz47kW11VWtvKngDZIM= To: j@w1.fi Subject: [Patch v8 12/15] AP: FILS Extended Key ID support Date: Thu, 31 Oct 2019 10:18:58 +0100 Message-Id: <20191031091901.2889-13-alexander@wetzel-home.de> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191031091901.2889-1-alexander@wetzel-home.de> References: <20191031091901.2889-1-alexander@wetzel-home.de> MIME-Version: 1.0 X-Ovh-Tracer-Id: 12049380807205068028 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedruddthecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecu X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191031_021955_383841_D7557A47 X-CRM114-Status: GOOD ( 19.53 ) X-Spam-Score: -0.2 (/) X-Spam-Report: SpamAssassin version 3.4.2 on bombadil.infradead.org summary: Content analysis details: (-0.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [178.33.251.173 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-BeenThere: hostap@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alexander Wetzel , hostap@lists.infradead.org, luca@coelho.fi, johannes@sipsolutions.net Sender: "Hostap" Errors-To: hostap-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org IEEE 802.11ai - 2016 is missing any instructions how to handle FILS in combination with Extended Key ID. There are two obvious ways: 1) FILS connections can only use keyid 0 and the STAs decide on rekey if they can use Extended Key ID or not. 2) FILS also checks if Extended Key ID can be used by both STAs and adds the KeyID KDE when it's used to the initial handshake without the normally required eapol handshake. The latter seems to be closer to the intent of 802.11ai and since there are no other implementations for Extended Key ID we could become incompatible to this patch implements option 2) for now. Signed-off-by: Alexander Wetzel --- Now this is a very free interpretation of how to handle Extended Key ID in combination with FILS. Technically it's the same issue as we have for FT, so I'm using the same (arguable) solution here: We bypass the 4-way handshake and Extended Key ID is therefore mostly irrelevant. Neither FILS nor FT mention Extended Key ID but both have a mechanism to hand over/get the GTK ID: Which of course could also handle the (unicast) KeyID required for Extended Key ID support... Now the patch series is rigorously sticking to the key install mode used at the initial connect: When either the AP or the STA tries to use anything else than for the initial connect we kill the connection. By also adding the KeyID to the others KDEs these checks work basically out of the box and the Extended Key ID flag in the RSN capabilities serves a purpose. Alternatively we could relax the checks and accept that we either still set the Extended Key ID bit in RSN but just assume the keyid is always zero for the initial connect with FT or FILS or even drop the bit in the RSN capabilities - creating a discrepancy to the beacon - and relax the sanity checks for FILS and FT accordingly. Since not Extended Key ID capable STAs won't care either way and there are no other Extended Key ID implementations we have to stay compatible with I decided to first try what I consider the cleanest way. Therefore Unicast KeyIDs have been added to the frames transporting also the GTK ID. Based on the feedback we either keep or change it. src/ap/wpa_auth.c | 12 ++++++++++-- src/ap/wpa_auth_ft.c | 6 +----- 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/src/ap/wpa_auth.c b/src/ap/wpa_auth.c index 6a1cd4f6a..67db61d6a 100644 --- a/src/ap/wpa_auth.c +++ b/src/ap/wpa_auth.c @@ -2685,6 +2685,15 @@ static struct wpabuf * fils_prepare_plainbuf(struct wpa_state_machine *sm, wpabuf_put_u8(plain, WLAN_EID_EXT_KEY_DELIVERY); wpa_auth_get_seqnum(sm->wpa_auth, NULL, gsm->GN, wpabuf_put(plain, WPA_KEY_RSC_LEN)); + + hdr[1] = 0; + if (sm->use_extended_key_id) { + hdr[0] = sm->keyidx_active & 0x01; + tmp = wpabuf_put(plain, 0); + tmp2 = wpa_add_kde(tmp, RSN_KEY_DATA_KEYID, hdr, 2, NULL, 0); + wpabuf_put(plain, tmp2 - tmp); + } + /* GTK KDE */ gtk = gsm->GTK[gsm->GN - 1]; gtk_len = gsm->GTK_len; @@ -2701,7 +2710,6 @@ static struct wpabuf * fils_prepare_plainbuf(struct wpa_state_machine *sm, gtk = dummy_gtk; } hdr[0] = gsm->GN & 0x03; - hdr[1] = 0; tmp = wpabuf_put(plain, 0); tmp2 = wpa_add_kde(tmp, RSN_KEY_DATA_GROUPKEY, hdr, 2, gtk, gtk_len); @@ -2756,7 +2764,7 @@ int fils_set_tk(struct wpa_state_machine *sm) klen = wpa_cipher_key_len(sm->pairwise); wpa_printf(MSG_DEBUG, "FILS: Configure TK to the driver"); - if (wpa_auth_set_key(sm->wpa_auth, 0, alg, sm->addr, 0, + if (wpa_auth_set_key(sm->wpa_auth, 0, alg, sm->addr, sm->keyidx_active, sm->PTK.tk, klen, KEY_TYPE_PAIRWISE)) { wpa_printf(MSG_DEBUG, "FILS: Failed to set TK to the driver"); return -1; diff --git a/src/ap/wpa_auth_ft.c b/src/ap/wpa_auth_ft.c index cf854a027..4a887e286 100644 --- a/src/ap/wpa_auth_ft.c +++ b/src/ap/wpa_auth_ft.c @@ -2785,8 +2785,7 @@ static int wpa_ft_set_key_mgmt(struct wpa_state_machine *sm, return -1; } sm->pairwise = wpa_pick_pairwise_cipher(ciphers, 0); - - return 0; + return handle_extended_key_id(sm, parse->capabilities); } @@ -2898,9 +2897,6 @@ static int wpa_ft_process_auth_req(struct wpa_state_machine *sm, return WLAN_STATUS_UNSPECIFIED_FAILURE; } - if (handle_extended_key_id(sm, parse.capabilities)) - return WLAN_STATUS_UNSPECIFIED_FAILURE; - use_sha384 = wpa_key_mgmt_sha384(parse.key_mgmt); pmk_r1_len = use_sha384 ? SHA384_MAC_LEN : PMK_LEN;