C. Bormann Universitaet Bremen TZI J. Rieckers Universitaet Bremen May 03, 2019 WiFi authentication: Some deployment observations from eduroam Abstract This short position paper looks at deployment considerations for network access authorization from the point of view of a campus network participating in the eduroam federation. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1 2. Participating in eduroam as an institution . . . . . . . . . 1 3. Deployment choices and vulnerabilities . . . . . . . . . . . 2 4. Turning off old versions . . . . . . . . . . . . . . . . . . 3 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Informative References . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction eduroam is a massive international federation of academic and research institutions that enables members of these institutions to access the Internet via WiFi networks of other institutions ("roam") with zero additional setup required -- users can carry their devices to those other institutions and they just work. [RFC7593] describes the architecture of eduroam and some adjustments to its structure that were motivated by a decade of operating this worldwide federation. This short position paper adds a few considerations from the point of view of an institution participating in the eduroam federation. 2. Participating in eduroam as an institution Universitaet Bremen has been participating in eduroam development from the outset, initially continuing with the VPN approach in use for inter-institution roaming in the federal state of Bremen. Today, eduroam is based on WPA2-Enterprise client software, access points that translate the EAP interactions into RADIUS, and a set of RADIUS servers that perform authentication and authorization of local users as well as interface with the international RADIUS server hierarchy that realizes the federation. Bormann & Rieckers Expires November 4, 2019 [Page 1] WiFi May 2019 In Europe, the federation is mostly run by NRENs (national research and education networks). Since academic institutions in Germany generally already are members of the local NREN (and generally also use it as their main ISP), considerations about design for choice (such as competitive provisioning of eduroam services) are less important. 3. Deployment choices and vulnerabilities Due to the design of EAP and WPA2-Enterprise, institutions are free to choose the EAP method(s) that are available to their members to authenticate to the institution's network access servers. Considerations about managing a highly dynamic 20000+ user population today essentially force us to rely on username/password authentication, which suggests the use of EAP-TTLS. Implementation problems that are listed in Section 7.1 of [RFC7593] make EAP-TTLS a much less secure protocol in practice than it could be. A popular elective assignment in one of our security classes is to build a rogue access point and collect username/password pairs from cooperating test users that configure their devices for the SSID used for the rogue access point in the same way they have configured it for eduroam. Reasonably modern implementations of EAP-TTLS can be configured to perform checks against man-in-the-middle attacks. Unfortunately, the default configuration user interfaces deployed with one major platform tend to install a configuration without these checks. The eduroam federation has reacted by providing a central website that automates proper configuration of devices, the Configuration Assistant Tool (CAT, cat.eduroam.org). Still, it is too easy to manually configure the access, leaving a configuration that is vulnerable to man-in-the-middle attacks. It does not help that another major platform does not always correctly install profiles generated by CAT, causing some mouth-to-mouth advice between students to go for the manual configuration (which, from the point of view of the students, then "works"). For a while, the computing center of the university tried to unify the credentials for general account access with those used for WiFi access. The result was that the easily gathered credential did not only provide free WiFi access, but could be used to completely subvert account security for institution members that used the vulnerable platform. Work is envisaged to add some fingerprinting for this platform to the authentication servers so that manually configured access can be prevented, giving the members some motivation to go for the more fool-proof automatic configuration. Also, members can opt to obtain special credentials for eduroam that Bormann & Rieckers Expires November 4, 2019 [Page 2] WiFi May 2019 are not shared with those for general account access. Unfortunately, for deployment considerations this password separation initially was provided only in an opt-in manner -- which probably was used mostly by people who also had used CAT to generate a less vulnerable configuration. Ironically, with the need for a configuration tool such as CAT to circumvent vulnerabilities in the EAP-TTLS implementations, we might as well have gone for a similar tool to generate and install client certificates for EAP-TLS. In effect, the design to enable the "seamless" use of existing client credentials was foiled by a persistent vulnerability in a major platform (only exacerbated by the problem this specific platform has in rolling out software updates) and sent us on a giant detour, while a proper design based on per- device client certificates would have resolved all these deployment issues. Of course, this persistent vulnerability could not have been planned for, so this can only be said with the benefit of hindsight. 4. Turning off old versions At the time eduroam was started, a number of clients were still relying on the interim security solution TKIP to access WPA- Enterprise. Only after more than a decade, most institutions now have turned off support for TKIP. We are still seeing approximately 9.7 % of all accesses using TLS 1.0 inside EAP-TTLS. Decisions on whether these older versions can be switched off would require some detective work to find out who these clients are and how their owners possibly can be contacted to motivate an upgrade. The same is also true of older ciphersuites -- we are even seeing a non-trivial amount of clients offering null encryption in their EAP-TTLS ciphersuites. It would be advisable to completely switch off support for such clients, however similar considerations as for TLS 1.0 apply. Turning off an older root certificate that will become invalid soon turned out to be a major deployment chore for institutions in Germany. In the end, the certificate change will require user action from every single eduroam user (ironically, except for those whose implementations are vulnerable to the man-in-the-middle attacks discussed above). Many institutions are using the certificate transition to also change the way outer identities (that are not protected against sniffing by the hosting institution) are distinct from the actual (inner) identities; this allows us to differentiate users that have performed the change from those that haven't. In the end, this might improve compliance with the mandate to use the CAT tool. Bormann & Rieckers Expires November 4, 2019 [Page 3] WiFi May 2019 5. Conclusion Relying on proper client-side implementation of a security protocol to protect important credentials proved foolish. This was exacerbated by our desire to simplify deployment by reusing credentials that already were used to protect much more valuable assets. Designing detailed fingerprinting into the server-side peers could probably have helped mitigate the problem. We are now seeing interesting differences in the behavior of client software, e.g., using the SNI option of TLS (~ 13 % of all accesses), or asking for OCSP stapling (~ 45 %) vs. not even signaling support for receiving staples (~ 55 %). Like the changes around outer identities discussed above, fingerprinting mechanisms might help us in addressing users that need to perform specific actions because of problems in the implementations they use. This of course disadvantages users of more rarely seen implementations. It also might cause false positives where fingerprinting is not selective enough. 6. Informative References [RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam Architecture for Network Roaming", RFC 7593, DOI 10.17487/RFC7593, September 2015, . Authors' Addresses Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 EMail: cabo@tzi.org Jan-Frederik Rieckers Universitaet Bremen EMail: rieckers@uni-bremen.de Bormann & Rieckers Expires November 4, 2019 [Page 4]