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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
