[OpenWrt-Devel] [PATCH v3] wpa_supplicant: fix generating phase2 config line for WPA-EAP

[Felix Fietkau]

On 2016-01-17 13:52, Daniel Golle wrote:
> Hi Felix!
> 
> Thanks for reviewing my suggestion!
> 
> On Sun, Jan 17, 2016 at 11:36:48AM +0100, Felix Fietkau wrote:
>> ...
>> > This will allow to simply add new options for auth to the list in LuCI:
>> > EAP-GTC, EAP-MD5, EAP-MSCHAPV2, EAP-PAP.
>> What about supporting multiple auth variants simultaneously? I see some
>> configurations using that, but I'm not sure if it's necessary or for
>> which cases it's relevant. Your code does not cover it, but it should be
>> easy enough to add. Do you think it's worth it?
> 
> I also saw and considered it, as you have also previously mentioned
> that. While it's possible to configure wpa_supplicant to cover all
> WPA-EAP methods, I believe that this option is dangerous when exposed
> to users as it could possibly be exploited by an attack to downgrade
> the authentication method used and trick the user into leaking
> credentials and/or perform MitM. This is particularly relevant if
> users do not pin/set the certificate and/or don't verify it against
> the CAs in /etc/ssl/certs. So I'd rather force users to at least pin-
> down the EAP method...
> The available phases have some interdependencies, ie. depending on the
> outer protocol, a different set of inner (phase2) methods are
> available.
> Also, for EAP-FAST and EAP-PEAP the inner-EAP methods which in the case
> of EAP-TTLS are stated using phase2="autheap=..." are now expected to
> be passed using phase2="auth=...", supposedly because these outer
> protocols already contain the EAP layer. And there are weird things
> like EAP-PEAP/EAP-TLS which supposedly offers the same functionality
> EAP-TLS also does, why ever one would want the additional overhead...
> I attached an updated version of my patch to this mail which now also
> takes that into account and also takes initial steps for handling
> EAP-FAST/EAP-*.
> I reckon the dependencies of phase2 on phase1 methods should be
> modelled on the UI level (-> LuCI).
> 
> From the test-cases provided by hostapd/wpa_supplicant, this seem to
> be the sane combinations possible:
>                  EAP-FAST           EAP-PEAP            EAP-TTLS
> CHAP                                                    Y !
> MSCHAP                                                  Y !
> MSCHAPv2                                                Y
> PAP                                                     Y !!!
> EAP-AKA          Y                  Y                   Y
> EAP-GTC          Y                  Y                   Y
> EAP-MD5                                                 Y ?
> EAP-MSCHAPv2     Y                  Y                   Y
> EAP-TLS                             Y
> 
> Some of the legacy phase2-methods available should really only be used
> if the TLS certificate is verified properly, as they could otherwise
> easily be exploited (at least those marked by at least one '!').
> Obviously, this becomes even more of a problem on clients without an
> RTC...
> 
> Anyway, as the overall security of WPA(2)-EAP heavily depends on the
> choice of phase1 and phase2 methods, I believe we should require users
> to specify the exact methods to be used.
> As setting up WPA-EAP has always been a bit tricky, guidelines (eg. for
> eduroam) usually explicitely mention the exact outer and inner
> authentication methods to be used on a certain network.
> I reckon it also makes sense to allow users to set eap_workaround=0 in
> order to enable more secure Strict EAP conformance mode at the cost of
> loosing interoperatibility with broken authentication servers.
> 
> For EAP-FAST there's a need for two more configuration options exposed
> to the user:
> Whether or not to set phase1="fast_provisioning=1" and allow the user
> to set the location of pac_file (or upload).
> Once I get to actually play with and test EAP-FAST, I might come up
> with the needed additions to the netifd handler.
> 
> It is true that it would be nice to allow the user to scan/probe all
> EAP parameters, ie. allow a single interactive connection attempt when
> clicking on a WPA-EAP-secured network in the scan results, and for
> that use a safe catch-all config as used in
> http://w1.fi/cgit/hostap/tree/tests/hwsim/test_ap_eap.py#n4112
> Once connected, extract the exact methods used and the certificate
> presented (if any) and save the results. In that way, at least all
> follow-up connection would be as secure as the first connection was
> and MitM on the first connection attempt would at least leave traces.
> However, this seems a bit more complicated and is beyond the scope of
> what I wanted to solve for myself now...
Makes sense. Please submit a new patch with proper description, and I
will merge it.

- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel