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@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
