From patchwork Tue Jan 5 21:49:54 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jouni Malinen X-Patchwork-Id: 563637 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 5A51F140157 for ; Wed, 6 Jan 2016 08:50:29 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1aGZUi-0002oP-96; Tue, 05 Jan 2016 21:50:20 +0000 Received: from mail.w1.fi ([212.71.239.96] helo=li674-96.members.linode.com) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1aGZUg-0001dQ-A7 for hostap@lists.infradead.org; Tue, 05 Jan 2016 21:50:19 +0000 Received: from jm (178-55-77-165.bb.dnainternet.fi [178.55.77.165]) by li674-96.members.linode.com (Postfix) with ESMTPSA id 559AE11077; Tue, 5 Jan 2016 21:49:55 +0000 (UTC) Received: by jm (sSMTP sendmail emulation); Tue, 05 Jan 2016 23:49:54 +0200 Date: Tue, 5 Jan 2016 23:49:54 +0200 From: Jouni Malinen To: Adam Jacobs Subject: Re: EAP-TLV: Earlier failure - force failed Phase 2 Message-ID: <20160105214954.GB8326@w1.fi> References: <62A311B4-3C2C-489C-97F2-66DE8EBFF818@mocana.com> <20160101142838.GA25558@w1.fi> <50DADDE6B33B1B47904E685AAFDC1824489C75E3E9@yugi.mocana.local> <20160104232955.GA21230@w1.fi> <50DADDE6B33B1B47904E685AAFDC182448CF2B40F9@yugi.mocana.local> <20160105190431.GB6916@w1.fi> <50DADDE6B33B1B47904E685AAFDC182448CF2B411B@yugi.mocana.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <50DADDE6B33B1B47904E685AAFDC182448CF2B411B@yugi.mocana.local> User-Agent: Mutt/1.5.21 (2010-09-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160105_135018_540259_1706C386 X-CRM114-Status: GOOD ( 14.99 ) X-Spam-Score: -1.9 (-) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-1.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: hostap@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "hostap@lists.infradead.org" Sender: "Hostap" Errors-To: hostap-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org On Tue, Jan 05, 2016 at 12:01:57PM -0800, Adam Jacobs wrote: > Complete log attached. Thanks! This is a bit long for the mailing list, so I'll drop the message from the moderation queue. Anyway, I do have the log and it was indeed quite helpful. This confirms that the cryptobinding works fine with TLS v1.2 in the initial authentication. Furthermore, I was able to find what the server did here with the keys exposed in the log. The difference here is in the server going through the Phase 2 method (EAP-MSCHAPv2) even though TLS session resumption is used. This is against the [MS-PEAP] specification from Microsoft.. That seems to be pretty clear on fast reconnection (= TLS session resumption) not using inner EAP authentication. Because of this, wpa_supplicant followed the specified derivation of CMK rather than what the server wanted to do here.. If I make wpa_supplicant use the style used in the no-fast-reconnect case during fast-reconnect where inner EAP method is used, I get matching Compound_MAC with the one shown in your log. Would you be able to run a test with wpa_supplicant modified with the following changes and provide a debug log from such a run? The main change is in adding the additional !data->phase2_eap_started condition for using the fast-reconnect style CMK derivation (which would be a one-liner, but I think it's useful to add the debug entry here to make it easier to see what happens here if some other servers implement PEAPv0 fast-reconnect differently). diff --git a/src/eap_peer/eap_peap.c b/src/eap_peer/eap_peap.c index 503d4b0..bf420cc 100644 --- a/src/eap_peer/eap_peap.c +++ b/src/eap_peer/eap_peap.c @@ -253,6 +253,7 @@ static int eap_peap_derive_cmk(struct eap_sm *sm, struct eap_peap_data *data) { u8 *tk; u8 isk[32], imck[60]; + int resumed; /* * Tunnel key (TK) is the first 60 octets of the key generated by @@ -263,8 +264,12 @@ static int eap_peap_derive_cmk(struct eap_sm *sm, struct eap_peap_data *data) return -1; wpa_hexdump_key(MSG_DEBUG, "EAP-PEAP: TK", tk, 60); - if (data->reauth && - tls_connection_resumed(sm->ssl_ctx, data->ssl.conn)) { + resumed = tls_connection_resumed(sm->ssl_ctx, data->ssl.conn); + wpa_printf(MSG_DEBUG, + "EAP-PEAP: CMK derivation - reauth=%d resumed=%d phase2_eap_started=%d phase2_success=%d", + data->reauth, resumed, data->phase2_eap_started, + data->phase2_success); + if (data->reauth && !data->phase2_eap_started && resumed) { /* Fast-connect: IPMK|CMK = TK */ os_memcpy(data->ipmk, tk, 40); wpa_hexdump_key(MSG_DEBUG, "EAP-PEAP: IPMK from TK",