No subject

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