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

[Daniel Golle]

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).