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...
Cheers
updated patch follows
---
Signed-off-by: Daniel Golle <[email protected]>
---
package/network/services/hostapd/files/netifd.sh | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/package/network/services/hostapd/files/netifd.sh
b/package/network/services/hostapd/files/netifd.sh
index 8056080..cedf5d5 100644
--- a/package/network/services/hostapd/files/netifd.sh
+++ b/package/network/services/hostapd/files/netifd.sh
@@ -633,10 +633,21 @@ wpa_supplicant_add_network() {
append network_data
"private_key=\"$priv_key\"" "$N$T"
append network_data
"private_key_passwd=\"$priv_key_pwd\"" "$N$T"
;;
- peap|ttls)
+ fast|peap|ttls)
json_get_vars auth password
set_default auth MSCHAPV2
- append network_data "phase2=\"$auth\""
"$N$T"
+ phase2proto="auth="
+ case "$auth" in
+ "auth"*)
+ phase2proto=""
+ ;;
+ "EAP-"*)
+ auth="$(echo $auth |
cut -b 5- )"
+ [ "$eap_type" = "ttls"
] &&
+
phase2proto="autheap="
+ ;;
+ esac
+ append network_data
"phase2=\"$phase2proto$auth\"" "$N$T"
append network_data
"password=\"$password\"" "$N$T"
;;
esac
--
2.7.0
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
