WiFi authentication: Some deployment observations from eduroam
slides-dedrws-wifi-authentication-some-deployment-observations-from-eduroam-00

                                                              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,
              <https://www.rfc-editor.org/info/rfc7593>.

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]