[PATCH] Remove data->phase2_success check for accessing EAP-TTLS key material.

[Jouni Malinen]

On Sat, Sep 10, 2016 at 07:28:59AM -0400, Michael Stapelberg wrote:
> This fixes the 4-way handshake when joining a WPA-EAP wireless network which is
> configured to return EAP-Success as soon as the inner EAP method is started
> within an EAP-TTLS tunnel.

How is the supplicant side network profile configured for this and how
does this terminate EAP-TTLS sequence? It should be noted that EAP-TTLS
has expectations on how the exchange is terminated and if wpa_supplicant
is configured with credentials that expect a specific response from the
server in Phase 2, the key should not really be used before that
response has been received.

EAP-TTLS does allow operations with Phase 2 skipped completely and
wpa_supplicant supports some of the possible cases for this. For this
specific use case, it might make sense to add new Phase 2 configuration
option that makes wpa_supplicant expect it to be skipped completely.
That would allow a clean setting of data->phase2_success = 1 in the
exchange to avoid having to make keys available in unexpected cases in a
manner than proposed in the patch here.

> Such a wireless configuration is common at Chaos Computer Club events (e.g. the
> yearly Chaos Communication Congress, or various smaller events which re-use the
> same wireless network configuration), where 802.1x is merely used to select
> VLANs and ensure individual users have different encryption keys, but NOT for
> authentication.

Would you be able to share a more detailed wpa_supplicant debug log with
-ddK on the command line (obviously without any private keys being used
here since -K will reveal them) showing how the protocol works? Or
alternatively describe what the supplicant side is expected to do after
the termination of Phase 1, i.e., when receiving TLS Finished message
from the server.

> data->phase2_success was checked in eap_ttls_isKeyAvailable and eap_ttls_getKey
> since 2008 at least (commit 6fc6879bd55a394f807cbbe927df736c190cb8ab is the
> earliest commit that is included in the git repository).

This was added with the commit message explicitly noting the addition in
2004:
http://w1.fi/cgit/hostap-history/commit/?id=0620112483fd93e8bc8a6f6248ff039f35cf501f

> Commit 7f7bfba919a76bb03a7f762eab0ac00d4f5c3184 (2015-02-01) introduced the
> allow_canned_success=1 configuration option, so I am assuming not removing
> data->phase2_success was an oversight of that commit.

Canned success is a case where the EAP authentication method is skipped
completely. This is quite different from the EAP-TTLS case and
allow_canned_success=1 is only for wired IEEE 802.1X cases without data
encryption. This does not give any justification for removal of the
data->phase2_success check from getKey().


> Debug log excerpt from before this commit:
> 
> […]
> wlp4s0: WPA: RX message 1 of 4-Way Handshake from 66:70:02:77:e2:70 (ver=2)

I'd need to see what happened before the start of this 4-way handshake
to be able to understand why the TTLS exchange did not complete
properly.

> diff --git a/src/eap_peer/eap_ttls.c b/src/eap_peer/eap_ttls.c
> @@ -1727,7 +1727,7 @@ static int eap_ttls_get_status(struct eap_sm *sm, void *priv, char *buf,
>  static Boolean eap_ttls_isKeyAvailable(struct eap_sm *sm, void *priv)
>  {
>  	struct eap_ttls_data *data = priv;
> -	return data->key_data != NULL && data->phase2_success;
> +	return data->key_data != NULL;

I think it would be better to set data->phase2_success = 1 at a suitable
location in the exchange for this special case rather than getting rid
of this check.

As a quick workaround, you might be able to configure EAP-TTLS with a
Phase 2 mechanism that does not expect a response from the server, e.g.,
EAP-TTLS/PAP or EAP-TTLS/CHAP. Those would allow the server to complete
exchange with EAP-Success. Assuming this works here, the cleaner
approach would be to add a network profile parameter for specifying that
no password is to be used and Phase 2 is to be fully skipped.

-- 
Jouni Malinen                                            PGP id EFC895FA