The KRACK vulnerability allows a Man-in-the-Middle (MITM) attack on a WPA2 protected WiFi network enabling encryption to be turned-off or obtaining keys to decrypt messages, which allows for eaves-dropping and also injection of data into messages in both directions between the user device and network service (e.g. web server).
(A WiFi MITM attack requires the attacker to be physically located within wireless coverage (e.g. the ‘eduroam hotspot’) and operate a ‘rogue Access Point’.)
KRACK takes advantage of a weakness in the WPA2 specification, hence the vulnerability is wide-spread. Support from WiFi hardware and software vendors is important to resolve this issue.
For WiFi networks (e.g. at a visited R&E institution, accessible via eduroam), the “WPA2 protocol” includes encryption to protect transmitted messages. Given an attacker’s easy access to the ‘wireless channel’, (i.e. physical location in a WiFi hotspot with their WiFi access kit), such protection from eaves-dropping is important for privacy of any information transmitted via unprotected protocols e.g. HTTP. Note that many network communications use protocols that provide a second layer of protection from eavesdropping e.g. VPN & web-sites using the HTTPS protocol which provide SSL/TLS encryption.
This is not an “eduroam” issue per se, rather it’s a WiFi issue.
There is one additional facet to this vulnerability that may impact eduroam:
If an attacker goes to the trouble of setting up a rogue wireless access point to exploit KRACK, they may also go to a simpler step of deploying a rogue RADIUS server to impersonate the home institution RADIUS server, which may result in revealing institutional credentials if home RADIUS server authentication is not performed.
KRACK enables an attacker to eavesdrop WiFi communications, e.g. to obtain your credentials or other sensitive information, and may also be used to ‘inject’ data (e.g. malware) either to or from your device via a ‘packet replay’ mechanism.
Note, if you’re using WiFi to access remote servers via VPN, or accessing HTTPS web-sites, your messages will still be protected via TLS encryption.
For the initial ‘remote authentication’ step of eduroam access, the WiFi WPA2 protocol is used, however credentials are TLS encrypted between the end-user device and the home RADIUS server using the “Protected EAP” or “Tunneled TLS” protocol. If institutions use the MSCHAPv2 authentication protocol (a challenge-response protocol), a user’s password is never actually transmitted. However if the PAP authentication protocol is used, the user’s password is transmitted and relies on TLS encryption provided by the home institution RADIUS server.
It is important that eduroam “identity provider” institutions educate their users to authenticate the home institution (identity provider) RADIUS server during eduroam authentication. If supplicants are manually configured, this typically requires configuring “validate server certificate”. For supplicants that connect natively to 802.1x networks, e.g. iOS devices, users should check the certificate details in the “Trust this Certificate?” dialog which appears if a RADIUS server presents a certificate different to one already trusted. Inform your users of the “Issuer” and “Subject” common-name values for the certificate they should expect, and only to accept the certificate if the information matches. (and to report the presentation of a certificate with different values).
Recommended actions for eduroam participating institutions:
Acknowledgement: Thanks to SURFnet for information used in creating this advisory.