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

Michael Stapelberg stapelberg at google.com
Mon Dec 12 23:56:55 PST 2016 

[re-sending my reply as plain text only for the mailing list]

On Tue, Dec 13, 2016 at 8:53 AM, Michael Stapelberg
<stapelberg at google.com> wrote:
>
> Thanks for your patience with my slow reply, and thanks for looking into this. Replies inline:
>
> On Sun, Oct 2, 2016 at 8:47 PM, Jouni Malinen <j at w1.fi> wrote:
>>
>> 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
>
>
> Here are the steps to reproduce the FreeRADIUS part of the network:
>
> (debian:stable is Debian 8.6, which contains FreeRADIUS 2.2.5.)
>
> $ docker run -t -i --net=host debian:stable /bin/bash
> root# apt update && apt install freeradius
> root# cat >/etc/freeradius/clients.conf <<'EOT'
> client openwrt {
> ipaddr = 10.0.0.254
> secret = secretkey
> nastype = other
> }
> EOT
> root# cat >/etc/freeradius/users <<'EOT'
> DEFAULT Auth-Type := Accept
> Tunnel-Type    = VLAN,
> Tunnel-Medium-Type  = IEEE-802,
> Tunnel-Private-Group-Id = 100
> EOT
> root# sed -i '0,/^\s*files/s//#files/' /etc/freeradius/sites-enabled/default
> root# freeradius -X -f
> […]
>
>>
>> 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.
>
>
> Interesting. Can you provide me a pointer to more details, or elaborate on why the key should not be used just yet please?
>
>>
>>
>> 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.
>
>
> Could you outline why a new configuration option is necessary? I.e., couldn’t we just unconditionally allow phase2 to be skipped if the server so wishes? Is there a security risk here which I don’t see yet?
>
>>
>> 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.
>
>
> Sure!
>
> Attached you can find the following wpa_supplicant logs, each created by running
> wpa_supplicant -c /tmp/wpa.conf -ddK -i wlp4s0 -Dnl80211, starting with the following configuration file:
>
> network={
> ssid="8021x"
> key_mgmt=WPA-EAP
> identity="bob"
> password="hello"
> eap=TTLS
> phase2="auth=PAP"
> }
>
> /tmp/2.6-vanilla-authpap.log.gz:
>   wpa-supplicant 2.6 (vanilla), with phase2="auth=PAP" (working)
>
> /tmp/2.6-vanilla-autheapmd5.log.gz:
>   wpa-supplicant 2.6 (vanilla), with phase2="autheap=MD5" (not working)
>
> /tmp/2.6-vanilla-autheapmd5cannedsuccess.log.gz
>   wpa-supplicant 2.6 (vanilla), with phase2="autheap=MD5" and
>     phase1="allow_canned_success=1" (not working)
>
> /tmp/2.6-patched-autheapmd5cannedsuccess.log.gz:
>   wpa-supplicant 2.6 (with my patch from the previous mail),
>     with phase2="autheap=MD5" and phase1="allow_canned_success=1" (working)
>
>>
>>
>> > 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
>
>
> I must have missed the hostap-history repository. Thanks for the pointer!
>
>>
>>
>>
>> > 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
>
>
> For the record, using phase2="auth=PAP", phase2="auth=CHAP" or phase2="auth=MSCHAP" indeed work.
>
>>
>> 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
>
>
>
>
> --
> Best regards,
> Michael




-- 
Best regards,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.6-patched-autheapmd5cannedsuccess.log.gz
Type: application/x-gzip
Size: 12064 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20161213/de27d64b/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.6-vanilla-autheapmd5.log.gz
Type: application/x-gzip
Size: 15710 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20161213/de27d64b/attachment-0005.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.6-vanilla-autheapmd5cannedsuccess.log.gz
Type: application/x-gzip
Size: 13149 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20161213/de27d64b/attachment-0006.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.6-vanilla-authpap.log.gz
Type: application/x-gzip
Size: 12080 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20161213/de27d64b/attachment-0007.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4851 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20161213/de27d64b/attachment-0001.p7s>

More information about the Hostap mailing list