Skip to content

eduroam WiFi security audit or why it is broken by design

Edit on 9th July, 2015

This article seemed to inspire a student to write his Diploma thesis about the topic. After some coincidences, I was asked to help to write an academic paper about the investigation and results of the thesis. This paper was published at the ACM WiSec 2015 conference in NYC. If you are interested in the findings, I would suggest to you to read the paper "A Practical Investigation of Identity Theft Vulnerabilities in Eduroam" instead of this blog article. This blog article was just a quick look into the deployed eduroam network and not a researched study.

A last fun fact: We had also a demo at the ACM WiSec 2015 were we used a self-signed certificate for a rogue eduroam access point. Even there the results were that over 50% of the attendees had wrongly configured eduroam devices and were therefore prone to an easy identity theft attack.


Start of the original article

Over Christmas I got a TP-Link TL-WN722N USB WiFi device which is supported by hostapd and finally I could test what I always wanted to test: eduroam.

But first, what is eduroam? Eduroam is a WiFi network located at universities around the world with the goal to provide internet access to students and university staff on every university that supports eduroam ( https://en.wikipedia.org/wiki/Eduroam ). This means I can connect to the internet with eduroam at a university in France with my user credentials from my university in Germany. Sounds good, but how does it work? Well, the WiFi network uses WPA-Enterprise, which means you connect to an access point and the access point uses a radius server to authenticate you. Generally not a bad idea. But my tests have shown that the practical deployment of the eduroam network is broken by design.


In advance

First things first. Some of my notes that I took from my tests can be seen here. I will provide them as a "POC||GTFO". But I stripped them to not provide a step by step tutorial in "how to pwn eduroam".


The set-up

I configured a VM with Debian Wheezy with an installation of hostapd. I never had configured a radiusd and wondered how I can get the user credentials if a client device would authenticate to my rogue access point. Well, I found this cool project https://github.com/brad-anton/freeradius-wpe.git. This does everything for me and I do not have to patch the radiusd myself. But honestly, I do not trust this modified radiusd entirely and after I configured everything I turned of the network interface of the VM which provides an internet connection to prevent the radiusd from leaking something of my tests to the internet.


Test without a certificate modification

On my first test I just set everything up and started it. I started wpa_supplicant on my laptop and it does not connect to the rogue access point because the certificate is wrong. Ok, but what with my Android device. I activated the WiFi on my mobile phone and ... WTF I am connected to the rogue access point. In the log file of the rogue access point I can read my user credentials in PLAINTEXT. Ok, that is not good. But what went wrong? The certificate used by the rogue access point is still invalid. The configuration on my Android device is completly flawed. I configured my Android device like the tutorial on my universities website said. The tutorial said that I do not have to configure any CA and use PAP for the phase2 of the WPA-Enterprise authentication. Now you can say "Idiot, everyone can see that this is wrong!". But to my defense, I always thought that Android then uses its own installed CAs to check if the certificate of the access point is valid. Hell, even the network-manager on ubuntu warns you if you give no CA in the settings. And I used PAP (I knew it sends the user credentials in cleartext) because I thought of the tutorials of my university that eduroam does only support PAP for the phase2 authentication. But both thoughts were wrong.

After I installed the "Deutsche_Telekom_Root_CA_2" CA on my Android device and used it in the WiFi configuration it no longer connects to the rogue access point.

Also, when the wpa_supplicant configuration misses this line:


ca_cert="/etc/ssl/certs/Deutsche_Telekom_Root_CA_2.pem"
 


it also ignores the invalid certificate of the access point and just connects to it.

I wrote the helpdesk of my university about the wrong tutorial for using eduroam on Android devices. The helpdesk replied to me that they knew this problem with the CA but Android is not able to verify the certificate of the access point. This is obviously wrong. And the funny thing about this is, they used screenshots in their tutorial to make it easier for everyone to configure eduroam on Android devices. And on these screenshots you can see the "CA certificate" option which is just ignored. Also their reply told me some other interesting things about eduroam, which I checked in my next tests.

As a summary for my first test: always configure the CA for eduroam (and in general for all WPA-Enterprise WiFi networks) and always use MSCHAPv2 instead of PAP. Even if your device connects to a rogue access point the adversary only gets challenge-response values and has to brute-force this. When your password is strong enough, the adversary can not use your credentials (at least he has to spend time brute-forcing MSCHAPv2 ...).


Test with an own certificate

In the eMail reply of the helpdesk of my university they wrote me that when the user added the CA to his WiFi settings, this would destroy the idea behind eduroam (to be able to connect to every eduroam access point in the world). First, I wondered about the "destroy the idea behind eduroam" part but then I thought "They would not be so stupid, would they?". I always thought that they agreed to use the "Deutsche_Telekom_Root_CA_2" CA for eduroam. But this is not the case. A friend of mine was in Belgium and had to change the configured CA in his WiFi settings to connect to eduroam there. I searched through some websites for eduroam tutorials of universities of other countries than Germany and they all used different CAs. Normally, the access point is configured to use a specific radius server which will send the certificate to the client (I do not know if it is even possible to use WPA-Enterprise in any other way). This means that by not agreeing on one CA for the entire eduroam infrastructure, the user has to NOT configure any CA in his WiFi settings to be able to use eduroam in the way it was intended to. And with this, we have the first reason for eduroam being insecure by design.(*)

The eMail also stated that even if the user added the CA to his WiFi configuration, this would not help. An adversary could get a certificate signed by the CA and could therefore set up a rouge access point. This statement is true. But this holds for every public key infrastructure. For HTTPS for example a CA should not sign my certificate for "gmail.com" (unless I can prove that this is my domain/address). And at this point a question comes to mind. The client gets the certificate by the access point and then checks with the configured CA if it is valid. But valid for what address? Normally, the CN (common name) in the certificate is checked with the used address. But with what address is the certificate provided by the radius server checked?

A valid connection to the eduroam WiFi at my university with wpa_supplicant looks like this:


wlan0: Trying to associate with SSID 'eduroam'
wlan0: Associated with 00:25:45:b5:38:22
wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=3 subject='/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=Ruhr-Universitaet Bochum CA/emailAddress=rubca@ruhr-uni-bochum.de'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=radius.ruhr-uni-bochum.de'
wlan0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
wlan0: WPA: Key negotiation completed with 00:25:45:b5:38:22 [PTK=CCMP GTK=TKIP]
wlan0: CTRL-EVENT-CONNECTED - Connection to 00:25:45:b5:38:22 completed (auth) [id=0 id_str=]
 


The address given in the CN is "radius.ruhr-uni-bochum.de". But I never configured this anywhere. So in my next test I created my own CA and signed my own certificate with it. The certificate for the rogue access point and the CA got the following values:


CA:
C=DE
ST=Some-State
O=h4des.org
CN=sqall

certificate for rogue access point:
C=DE
ST=Some-State
O=h4des.org
CN=some-rogue-access-point
emailAddress=sqall
 


You can see, that the CN field got "some-rogue-access-point" as value, which is no address for a radius server at all.

First I tried wpa_supplicant with my newly created CA certificate in the configuration file:


ca_cert="./CA.cert.pem"
 


And what happened? wpa_supplicant connects with the rogue access point without any problems and discloses my user credentials as MSCHAPv2 challenge-response values. The output of wpa_supplicant shows that the radius server uses my newly created certificate.


wlan0: Trying to associate with SSID 'eduroam'
wlan0: Associated with b0:48:7a:88:fc:7a
wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=4 -> NAK
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=DE/ST=Some-State/O=h4des.org/CN=sqall'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=DE/ST=Some-State/O=h4des.org/CN=some-rogue-access-point/emailAddress=sqall'
EAP-TTLS: Invalid authenticator response in Phase 2 MSCHAPV2 success request
 


Next I tested it on my Android 4.0.4 device. I installed my own CA on the device and changed the eduroam WiFi settings to check for this CA. The device connects with the rogue access point without any problems and also discloses my user credentials.

As a summary for this test: the certificate for the rogue access point just have to be a valid certificate signed by the used CA. It does not matter for which address the certificate was issued, it just have to be valid. Normally, the problem for forging a valid host in an TLS/SSL connection (such as the HTTPS example for "gmail.com" I gave earlier) is, that a CA does not sign your certificate request unless you own the domain/address (or rather the CA should not). But if you can use any address in the CN, it is no problem to get a signed certificate. Here lies the second reason for eduroam being insecure by design. I do not know if the vendor got a service to sign your own certificates with the "Deutsche_Telekom_Root_CA_2" certificate. But normally they do. And if the vendor does, there is absolutely no problem to configure a rogue access point which can not be distinguished from a valid one.

It should be mentioned, that the address of the radius server can be configured in the iDevice profiles. But I have no iDevice and so I can not check if the CN of the certificate provided by the radius server is checked against the configured address. In wpa_supplicant for example I did not found any configuration option for the address of the radius server. But I found the option to match certain criteria of the accepted server certificate with "subject_match". Android 4.0.4 does not provide any such options.


Test with an own intermediate CA

After an arbitrary signed certificate was tested, the next interesting thing is a certificate signed by an intermediate CA. When we look at the wpa_supplicant output when connecting to a benign access point:


wlan0: Trying to associate with SSID 'eduroam'
wlan0: Associated with 00:25:45:b5:38:22
wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=3 subject='/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=Ruhr-Universitaet Bochum CA/emailAddress=rubca@ruhr-uni-bochum.de'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=radius.ruhr-uni-bochum.de'
wlan0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
wlan0: WPA: Key negotiation completed with 00:25:45:b5:38:22 [PTK=CCMP GTK=TKIP]
wlan0: CTRL-EVENT-CONNECTED - Connection to 00:25:45:b5:38:22 completed (auth) [id=0 id_str=]
 


we can see, that the certificate is signed by the CA of my university (and not the "Deutsche_Telekom_Root_CA_2" CA). Actually, the chain is "Deutsche_Telekom_Root_CA_2" -> "DFN-Verein PCA Global - G01" -> "Ruhr-Universitaet Bochum CA". So my idea at this point was, it could be difficult (and perhaps costly) to get a signed certificate by the "Deutsche_Telekom_Root_CA_2" CA, but a signed certificate by the university is very easy as student or university staff. So, I created my own intermediate CA signed by my formerly created CA and generate a new certificate for my rogue eduroam access point. The values for all these CAs and the certificate are:


CA:
C=DE
ST=Some-State
O=h4des.org
CN=sqall

intermediate CA:
C=DE
ST=Some-Other-State
O=h4des.org
OU=intermediate
CN=it is sqall again

certificate for rogue access point:
C=DE
ST=Some-Other-State
O=h4des.org
OU=intermediate certificate
CN=again sqall
 


Again, wpa_supplicant is tried first. The settings are the same as for the test before (this means wpa_supplicant uses the certificate of the CA to check the validity of the rogue access point). The output of wpa_supplicant shows, that the rogue access point offers my new certificate signed by the intermediate CA and that the client connects without any problems:


wlan0: Trying to associate with SSID 'eduroam'
wlan0: Associated with b0:48:7a:88:fc:7a
wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=4 -> NAK
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=DE/ST=Some-State/O=h4des.org/CN=sqall'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=DE/ST=Some-Other-State/O=h4des.org/OU=intermediate/CN=it is sqall again'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=DE/ST=Some-Other-State/O=h4des.org/OU=intermediate certificate/CN=again sqall'
EAP-TTLS: Invalid authenticator response in Phase 2 MSCHAPV2 success request
 


The log file of my modified radius server shows me the MSCHAPv2 challenge-response values:


mschap: Sat Jan 11 19:42:27 2014

        username: pawlxyz@ruhr-uni-bochum.de
        challenge: 43:cd:42:0f:a6:14:46:4e
        response: 0d:b8:47:c0:11:a6:c9:10:a2:14:99:af:1d:15:d6:ef:4a:89:d3:95:aa:ba:2d:2b
        john NETNTLM: pawlxyz@ruhr-uni-bochum.de:$NETNTLM$42cd490fa604464c$0db486c012a6c910a21379ef1d15d6ff4a89d395baba2d2c
 


Next I tested my Android 4.0.4 device. Like the wpa_supplicant client, it connects without any problems (because the access point is now considered valid).

As a summary for this test: the client accepts certificates that are signed by intermediate CAs. In this constellation, it is the third reason for eduroam being insecure by design. It might be difficult to get a signed certificate by the main CA. But when intermediate CAs are in place, it could be a lot easier to get a valid certificate. The "Deutsche_Telekom_Root_CA_2" CA signed the "DFN-Verein PCA Global - G01" intermediate CA and this signed the CA of my university. I think that the "DFN-Verein PCA Global - G01" intermediate CA signed a lot of university CAs. And a lot of universities (like mine) offer the service to sign your server certificate (when it is inside the namespace of the university). When you are able to get a certificate that is signed by anyone of the CAs in the chain, you can forge a valid eduroam access point.


Test with a server certificate signed by my university

Ok, all the talk about "uhh, it is insecure with this used public key infrastructure!" and "it is theoretically possible to ...", let's break it! I helped the university to set up some servers. So I have access to a certificate signed by the university CA. And I configured my rogue access point to use this certificate. This certificate obviously does not have "radius.ruhr-uni-bochum.de" as CN value. It is valid for other addresses which I censored out. We saw in the tests above that the value in the CN field does not matter.

First I tried wpa_supplicant. Now with the settings that should be used for a valid eduroam access point. This is the output:


wlan0: Trying to associate with SSID 'eduroam'
wlan0: Associated with b0:48:7a:88:fc:7a
wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=4 -> NAK
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=3 subject='/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=Ruhr-Universitaet Bochum CA/emailAddress=rubca@ruhr-uni-bochum.de'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/OU=xxx/CN=xxx'
EAP-TTLS: Invalid authenticator response in Phase 2 MSCHAPV2 success request
 


And we can see that the client thinks it is a valid eduroam access point. The log file of the modified radius server shows my MSCHAPv2 credentials:


mschap: Sun Jan 12 01:24:03 2014

    username: pawlxyz@ruhr-uni-bochum.de
    challenge: 28:f5:bf:4d:3f:fe:bf:a2
    response: 7a:ab:24:87:35:82:46:40:33:73:89:5a:77:bb:ee:c0:4b:56:8b:a8:67:af:e9:94
    john NETNTLM: pawlxyz@ruhr-uni-bochum.de:$NETNTLM$28f5bb4d8ffaafa2$7aab248735824641d373895a77dbeec04b568ba867afe994
 


The same goes for my Android 4.0.4 mobile phone. A client is not able to distinguish a benign eduroam access point from my rogue access point.

A fun fact that happened when I just started my rogue access point with the valid certificate: the mobile device of one of my neighbors connected instantly to my rogue access point (his or her login credentials are from a different university than mine). One has to love all the folks that have their WiFi always turned on :-)


Test with a client certificate signed by my university

My university has the service to provide any student with a client certificate signed by the university's CA. My idea was "most clients do not provide options for the radius server address, perhaps they do not check if the certificate is only for clients". Beforehand, I can tell you that wpa_supplicant and Android 4.0.4 do (I did not test others).

I used a certificate with this key usages and signed by my university's CA:


X509v3 Key Usage:
        Digital Signature, Non Repudiation, Key Encipherment
X509v3 Extended Key Usage:
        TLS Web Client Authentication, E-mail Protection
 


So, when I try to connect with wpa_supplicant I get this output:


wlan0: Trying to associate with SSID 'eduroam'
wlan0: Associated with b0:48:7a:88:fc:7a
wlan0: CTRL-EVENT-EAP-STARTED EAP authentication starte
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=4 -> NAK
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
TLS: Certificate verification failed, error 26 (unsupported certificate purpose) depth 0 for '/C=DE/O=Ruhr-Universitaet Bochum/CN=sqall'
wlan0: CTRL-EVENT-EAP-TLS-CERT-ERROR reason=0 depth=0 subject='/C=DE/O=Ruhr-Universitaet Bochum/CN=sqall' err='unsupported certificate purpose'
SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unsupported certificate
OpenSSL: openssl_handshake - SSL_connect error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
 


So we can clearly see, that wpa_supplicant checks the certificate purpose. The same goes for Android 4.0.4. It just tells me authentication error.

To summarize this part: this does not have anything to do with the design or security of the eduroam network. This is only an implementation thing of the used client software. I just tested it with the hope to find a "fuck up" of some WiFi clients, but was disappointed ;-)


Conclusion

In this part I conclude my short security audit of the eduroam WiFi network. In my opinion it has a huge design flaw which is not to fix without changing the whole public key infrastructure. For me it seems that when they were designing the whole eduroam network they just thought "We need some public key cryptography for eduroam. The protocol supports TLS/SSL for authentication. It is used by the internet. So let us just use it too!". Using different CAs in different countries which signed a lot of intermediate CAs is not a good idea when the clients do not/can not check the address of the radius server which provides the certificate. Every certificate that is signed by one of the intermediate CAs or the used top CA is valid for any client that tries to connect to the eduroam WiFi. Furthermore, the idea of eduroam was to provide a network to which a client from a different country could also connect (for example, a client from Germany could connect to an eduroam access point when he is in Belgium). This is not possible when different top CAs are used in each country (or perhaps even within a country). Or rather this is only possible when certificates are not checked. But when they are not checked, what is the point of using TLS/SSL?(*)

The next thing is, a lot of universities (like mine) provide flawed tutorials to configure WiFi clients for eduroam. Even when MSCHAPv2 is available, the tutorials often used PAP to authenticate the client. PAP sends all user credentials in plaintext whereas MSCHAPv2 provides a challenge-response procedure. Furthermore, a lot of tutorials do not set up the CA to check the server certificate. Without this setting the client connects to any eduroam access point without checking the validity of the server certificate. This means, when an user configured her client with the help of the flawed tutorials and uses eduroam, she could just as well shout out her credentials everytime she is connecting to the WiFi network.

The really bad thing about this is, when an adversary gets the user credentials of someone, he often has the user credentials for other services of the university as well because the same account is used (in the case of my university for the email account, the MSDNAA account, ...). I heared of some universities that even use these credentials to let the student subscribe/unsubscribe for exams of the offered courses.

The only way a client can protect herself against this attack is by using MSCHAPv2. When MSCHAPv2 is used, the adversary still has to brute force the password when he successfully forges an eduroam access point. This means the security comes from the strength of her password (and the strength of MSCHAPv2 ... which uses DES and can be cracked relatively fast with services like https://www.cloudcracker.com/ :/ ).

In my opinion, the only way to really fix this issue is to use an own public key infrastruture for the whole eduroam WiFi design. When an own CA is used for eduroam (perhaps with intermediate CAs for universities to use only for certificates that are used by the eduroam infrastructure) there is no way to forge a valid eduroam access point for an attacker, because he can not get a signed certificate for it. When the clients set up the CA in their eduroam settings, they would not connect to rogue access points. Even if the client is configured to use PAP instead of MSCHAPv2, the user credentials are secure in a way. But the own public key infrastructure would only work when the clients are configured correctly and this means that the universities have to fix their tutorials for the eduroam WiFi first.

I wrote my university about this issue and they fixed some tutorials (for example for Android). But not all are fixed (for example for wpa_supplicant) and I do not think that they will fix all of them. But even so, fixing the tutorials will not help when a lot of students and university staff already applied the flawed configurations.


Errata

(*)In the time of writing this article, I have not tested this statement. I just based it on the settings you can made in an access point, the statement of my university and the statement my friend had made. However, yesterday night I drove to the next city to test this statement at an other university (the TU Dortmund). Honestly, I did not expect this result:


wlan0: Trying to associate with SSID 'eduroam'
wlan0: Associated with 00:14:a8:14:86:f1
wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=3 subject='/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=Ruhr-Universitaet Bochum CA/emailAddress=rubca@ruhr-uni-bochum.de'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=radius.ruhr-uni-bochum.de'
EAP-TTLS: Phase 2 MSCHAPV2 authentication succeeded
 


The wpa_supplicant output shows that even when I am at another university in Germany and use eduroam there, the CA chain looks the same as at my university. This means that my WiFi client still connects to the radius server of my university. I did not expect that (and have not really an idea how this infrastructure works exactly). Unfortunately, I have no way to test it with an university in a foreign country. Nevertheless, my conclusion which states that an own CA should have been used for the eduroam infrastructure remains the same.


Update on 27 January 2014

@fadenb send me this link via twitter. It shows a nice compatibility matrix for eduroam WiFi clients. This site states (like this article) that Android is not able to check the certificate of the radius server against an address. Also a lot of other clients are tested.

I also want to mention that my university updated almost all tutorials for the eduroam client configuration on their website by now. Unfortunately, not many of them check the radius server address in their configuration. I send them my wpa_supplicant configuration file (which checks the certificate with "subject_match") and they uploaded it to their website. At least some people which use these tutorials have a secure configuration now.

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

Johannes Gilger on :

Interesting research. I was about to do that myself, but glad I just discovered your post on this topic. Here at the RWTH, the tutorial for both Android 4 and Network Manager mentions MSCHAPv2 as the desired option, so I guess that's good.

About Radius: Yes, that is how the system works. There is a radius server for local students and then there is a radius proxy (radsecproxy) which tunnels authentication requests to the home institutions of the students. That's also why there are two IDs than can be entered: anonymous[at]rwth-aachen.de and user-id[at]rwth-aachen.de. The first one is just to establish which Radius server to tunnel to, and the second one is the actual user id which is then used to authenticate against the home radius server of the user.

This has two interesting implications for an institution running an eduroam network: We can see our own students+ids which log in abroad (at other universities) and we can also see when there is a student from a foreign university connecting to our own eduroam, though we can not tell his user-id in this case.

sqall on :

I thought that the anonymous ID is used for the routing after I tested the eduroam connection at the TU-Dortmund. After all the client should not send the real ID without the SSL/TLS connection (one reason for my first assumption that the client will connect to the radius server of the university where the client connects itself).

David Chadwick on :

Hi Squall

Unfortunately you do not understand the underlying PKI trust model.

Every PKI client (whether laptop, mobile, tablet etc.)is responsible for configuring its own roots of trust. In the eduRoam case, it is the user's responsibility to say which CA is trusted to authenticate it's university's certificate. Each university should say in its instructions how its users should configure this CA into the wireless configuration of their client device.

EduRoam is not broken. Android is broken because it does not either allow users to configure in their roots of trust, or check certificates against the roots that have been configured in. Some university documentation may be wrong, in that it does not tell users how to correctly configure their devices with roots of trust, but this is wrong configuration of eduRoam, not that EduRoam is broken by design. So the title of your blog is misleading. You might wish to change it so that you do not make yourself look foolish :-).

sqall on :

I would not agree to this.

First you say:

"Every PKI client (whether laptop, mobile, tablet etc.)is responsible for configuring its own roots of trust. In the eduRoam case, it is the user's responsibility to say which CA is trusted to authenticate it's university's certificate."

The problem I have with this statement is, that this goes for all PKIs. This means also that every user should be responsible for all the CAs he has in his browser. But there is no way that a normal user can do this (or even understand what a PKI is ;-) ). It goes so far, that incidents like the one with "DigiNotar" (which was a misuse of the PKI) let some people state that the PKI system we have in our browser is totally broken. But still, a PKI works if it is used correctly.

"Each university should say in its instructions how its users should configure this CA into the wireless configuration of their client device."

I would say this too. But just a short internet search had shown me that a lot of universities do not do this. I would even say that most of the ones responsible to set up the eduroam network at the university do not understand the need of the correct configuration. For myself, I worked at the RWTH-Aachen as a system administrator some years ago. And a lot of people I met there (that worked as system administrators too) would not see this problem until you tell them.

"EduRoam is not broken. Android is broken because it does not either allow users to configure in their roots of trust, or check certificates against the roots that have been configured in."

Ok, this is correct. But we can do this both ways. Why does eduroam not use an own CA system (like I suggested in my article)? Why would state a design to use a PKI which needs to check the address of radius server when there are broken clients which does not support this? This would solve a lot of problems with broken clients that do not support an address to check the certificate against. For me it is not carefully thought out.

Nevertheless, with all the universities that misconfigure their eduroam WiFi networks or give out wrong tutorials for their normal users (which I also include in the name "eduroam") I will keep the title of the article ;-)

Stefan Winter on :

Hi there,

my name is Stefan Winter. I led the eduroam R&D efforts in Europe for some 8 years, and would like to make a few important points.

1. the university in question is violating the eduroam Service Definition. We state very clearly:

"An IdP MUST provide sufficient configuration instructions for their end users so that a unique identification of
the IdP is possible for the end user at all times."

This is section 6.3.2 of this document: https://www.eduroam.org/downloads/docs/GN3-12-192_eduroam-policy-service-definition_ver28_26072012.pdf

I have escalated this matter to the eduroam National Roaming Operator in Germany, DFN.

2. Commenter 2.1 speaks about CAs in browsers. It should be made clear that the use cases *and the trust model* between browsers and in the IEEE 802.1X (i.e. "eduroam") case are very different: for browser trust, you don't know which CA a web site operator chose for his web server setup. As a consequencem, a large number of CAs has to be pre-loaded in the browser. This is different with IEEE 802.1X: you know *exactly* which authentication server, with which certificate, you expect to answer to your login request. You need to install exactly one CA, and configure exactly one expected server name, and then at connection time verify that this is indeed the correct server answering.

3. Self-signed CAs are indeed a security win when dealing with deficient devices such as Android < 4.3. (This is the only real bit of truth in the OP; that and the assessment in the errata that you have no idea how this infrastructure really works ;-) ) We have a corresponding recommendation for Identity Providers.

Check out this:

https://confluence.terena.org/display/H2eduroam/EAP+Server+Certificate+considerations

This explains all the reasoning, and also has a few reasons why it is sometimes not a good idea to run your own - it is quite complicated because many supplicants require many subtleties in the peoperties of the certs. Just naively thinking "oh well, why not just 'openssl ca' ?" is thought too short.

4. Why doesn't eduroam run their own CA? Quite simple: there are several thousand Identity Providers in eduroam world-wide. If we had one CA for all, each IdP could impersonate each other. For clients which don't check the actual name, the sheer number of certs to issue would put us on the same level as a typical commercial CA. So the choice is much rather: either do it correctly yourself, or ask someone else to do it for you.

5. About many universities not doing this. There are some; as soon as we in eduroam Operations are made aware of it we take appropriate action. But luckily, many participants use our automated tools for *secure* setup by making use of our provisioning tool eduroam CAT: https://cat.eduroam.org (for all countries except Germany; for German IdPs, the tool is at https://edit.dfn.de ). The tool does not yet support Android because Android's Enterprise WiFi implementation on versions < 4.3 simply - in plain words - sucked badly. We are working on a provisioning app for versions 4.3 and above.

sqall on :

Wow, thanks for the detailed reply. Did not thought that so much people would read my post (but I also never thought that someone would post it on reddit).

To point 2:
I made this comparison to point out that a normal user do not have any idea which CA is used. And the reason for this is your point 1 ;-)

To point 3:
All I did was testing eduroam from the outside and basing my assumptions on the results (and unfortunately on the false statement of a friend). Therefore I added the errata. I never claimed to know the infrastructure, the recommendations or the rule set that the eduroam organization gives.

To point 4:
This is an interesting issue. But it seems to me that at this point there is the same problem only on a smaller scale. (Again, I do not know the infrastructure) From what I have seen the universities in Germany use a CA chain like this:

"Deutsche_Telekom_Root_CA_2" -> "DFN-Verein PCA Global - G01" -> "university CA"

For me it looks like that the IdPs in Germany could still impersonate each other (because the "Deutsche_Telekom_Root_CA_2" is at the top). When a CA chain like this

"eduroam CA" -> "university CA"

is used, the problem will be at larger scale, this is true. But problems with a broken client that can not check for the address of a server or tutorials that do not use this check would be mitigated. For me it seems that the latter problem is more pressing than the former one.

Thanks again for giving the inside and giving this important links :-)

Dan Lukes on :

Yes, you are true. This method of credentials leaking can be avoided.

As former bank security officers I feel eligible to claim that credentials will leak. No countermeasure can avoid it at all.

Unfortunately, Eduroam has been carefully tweaked to be cheaters friendly.

The service provider is not allowed to know an id of user connected to the network. So SP can recognize or reject no particular user. (Note the official policy requests SP to block particular user despite it's not possible - but it's another story).

All users of particular SP network may use just one pair of stolen credentials and SP have no chance to detect it.

IdP are not interested to detects stolen or misused credentials. They are not affected by issue caused by users in other networks, thus they motivation is true zero.

In short, SP provide resources and take risks, but is not allowed to take countermeasures against stolen/lost credentials. IdP take no countermeasures because they have no motivation to do so. So credentials, once leaked, can be used for long time. And it's known that some IdP cancel no obsolete account, thus particular credential pair may be considered valid very long time.

Well, misused credential may become blocked because of an activity that cause complain. SP may complain and IdP are obliged to solve complaints. Even such mechanism doesn't work well.

There is no generic way to identify person responsible for particular realm. Thus SP may not identify where the complain should be send at all.

As administrator of SP Eduroam network I would like to claim that I recognize Eduroam to be dangerous and risky network.

I'm in permanent fear an Eduroam user (using either own credentials or the stolen one) will use our network for an unlawful purpose - like sending threats, especially as part of kidnapping or so and we will be unable to identify an user of our network.

Don't respond such risk is related to any network. We can identify users of our other network. They are using our resources, so we should know them. And we have countermeasures that help us to recognize lost credentials.

Eduroam is rather like public cafeteria than well designed network.

sqall on :

Mh, that is interesting. Never thought about accountability regarding roamed hosts. But now that you mention it, it seems a bit risky when thinking about how easy it is to steal other user credentials.

Thank you for your comment :-)

Stefan Winter on :

Dan,

eduroam was carefully tweaked to be privacy-preserving for users, not to make cheater's lives easier. That is a huge difference.

It is true that this does make accountability a less easy job compared to when we'd just deliver our users' personally identifiable information on a silver platter without reason.

Privacy support and accountability are conflicting with each other, no doubt. A former bank security officer would undoubtedly swing towards the latter, but we uphold privacy as a significant value. And being an international consortium where information about users would need to cross international borders, preventing unnecessary (and unlawful!) leakage of user data is even a required design cornerstone.

All that said: we /also/ carefully tweaked eduroam to enable Service Providers to be able to block users and contact IdPs; it just requires effort to do so.

In essence, what you state above simply isn't true in many respects; at least for SPs and IdPs in Europe (I don't know where you operate):

* the RADIUS attribute "Chargeable-User-Identity" (CUI) is a recommended asset in authentication transactions - SPs are encouraged to request such an identifier, IdPs are encouraged to deliver it to SPs. This attribute allows the unique identification of a user account at an SP location without actually spilling the true user account (you can compare this to the SAML world's notion of a "targeted ID" [this is European policy].

* Even in the absence of a CUI identifier, SPs can block users by blocking the entire realm (domain name) when a user from that domain misbehaves. That is unfair to the innocent /other/ users from that domain at the hotspot, but it does block effectively the user in question [this works globally]; and for more fine-grained control, see CUI above.

* It is of course possible to contact the person responsible for a realm. All realms with the contact data of their responsible personnel are listed in the global eduroam Operations Database. As an SP or IdP admin, you likely don't have access to those (again, also the SP/IdP operators across the globe have a right to privacy), but that's why the escalation procedure for issues always points you to your *national roaming operator* - and those guys have access to the Operations database, and can make contacts to the required people to resolve the issue.

In short: accountability is possible. It's intentionally /difficult/ for good reasons.

Dan Lukes on :

"eduroam was carefully tweaked to be privacy-preserving for users, not to make cheater's lives easier. That is a huge difference."

True, it's not the same. Eduroam has been tweaked to be cheaters friendly even in the case the privacy can be maintained.

You mentioned "Chargeable-User-Identity". Yes, if used properly (e.g. it must be mandatory and must not be constand for same user and SP) it may give SP a control with no privacy threat to user.

But IdP is not obliged to use CUI and we don't know it's constant even in the case they are using it. So all our users still may used one credential pair at the same time with no chance to detect it.

Federation can CUI to be mandatory - of course constant CUI, but it's not willing to do so. So Eduroam remain cheaters friendly and privacy is no reason.

You mentioned it is possible to contact responsible person of a realm. At the same time you confessed the SP administrator have no access to such information. No one asked for realm's administrator name, weight or number of their children. I asked for generic address of responsible person of particular realm. Nothing private.

It's no privacy threat to make it accessible to SP. But it's not accessible. And privacy is no reason.

IdP may be obliged to monitor account usage, but they aren't.

So don't claim "good reasons".

You disclosed true reason in the response. It's "it just requires effort to do so".

I'm saying the same. No one have motivation to solve SP's risks. No one considered SP's responsibility over resources the Eduroam's users are using. No one considered issues the SP may face.

So there's no effort to solve those issue. Privacy is just attempt to hide true reason. Sorry to saying it.

Someone may ask what the hell such upset may is speaking about ? It just works for years as is, isn't it ?

We had user sending kidnapping threads from our network in the past. Police has contacted us and we provided them account owner identity within few minutes. Such thread has been identified as fake then, but imagine real kidnapping. Every minute count here.

Imagine the same issue on Eduroam. Despite user is used our resources, no one can identify them. It take few days to contact remote realm administrator (remember - at the first we neet to ask NRO for contact address), but even then he may not disclose the identity.


But forget kidnapping. Imagine more common case - user is running a P2P system on their notebook distributing a copyrighted material - we are unable to take immediate countermeasures. We can block realm only - e.g. so many users. It's reason enough to claim "it's poorly designed".

But I don't care "design". I just wish not to explain to a reporter of Evening News how it's possible the public University provide network service to unknown user, unable to neither identify them nor block it's access - and moreover we even have no contact to anyone who know the identify the user.

Your own users and students are obliged to follow Network Operating Rules. At the same time, we are just public cafeteria for others.

I can disclose the country I have experience with. I'm administrator of MFF UK in Prague. I'm the administrator which get "we have no idea" response from NRO (I asked for responsible person of a Spanish realm). Note than my generic contact email address is netadm@ms.mff.cuni.cz (yes, administrator's contact address may be published with no privacy affected).

Be sure I tried to raise question related to risk management and accountability. Their response ? Very negative - they claim they are not willing to spend their valuable time to solve my issues. Of course - it's not their risk.

And it's I claimed in my previous message. There are SP who provide resources and take risk. They are not allowed to do risk management. And there are IdP, NRO, Federation - no one taking risk and no one interested in those issue. Thus there's no effort ...

Your response is just confirming my previous conclusions. Solutions are known, but there's "no effort".

That is it.

But it's part of overall Eduroam design. The poor design.

Stefan Winter on :

In general: I despise of your accusations that we are using privacy as a cover-up for laziness or wanting to help criminals. eduroam has a decade-long history, and privacy support for end users has been a major consideration from day 1.

Regarding specifically your other post about CUI:

Reading and understanding RFCs is sometimes non-trivial. CUI is a good example. The quote you gave was:

"The assertion should be temporary -- long enough to be useful for the external applications and not too long such that it can be used to identify the user."

This means the longevity of the value depends on the application.

In our case, the application is "Wi-Fi Roaming".

So, the RFC states just fine that the identifiers need to stay the same for as long as its useful for roaming purposes.

We are not mandating that the value be unchanged forever. The statement in policy that "The value of Chargeable-User-Identity attribute returned in the response MUST have a constant value for one user and one Operator-Name attribute value." is to be interpreted as "within the limits of RFC4372" of course, because we are NOWHERE in the business of violating RFCs. So please stop claiming that we are doing that.

The only operationally relevant requirement is that it's valid long enough so that its stated goals (accountability) can be achieved.

It's up to interpretation how long that really is; something between many weeks and several months is probably good enough. As the international coordination body, we can only tell people to do it right; the exact "right" duration is much dependent on the national jurisdiction on privacy laws and processing and storage of personally identifiable information. It's the responsibility of the NRO to satisfy national laws.

Yes, we did think about this topic for a long time. The RFC text you quote does not at all come as a surprise to me.

On identifying users in the absence of CUI: this is still possible and does get your SP out of harms way:

As the SP, you know the timestamp of authentication and the realm of the user. Your eduroam NRO can lookup the persons responsible for the realm. That person on the other side is required to have logs matching those from your side, and can thus find out which user exactly was misbehaving and can take appropriate action.
We had a number of incidents which were resolved with this procedure. So, if law enforcement requires you to identify a user, you can give them sufficient information so that the person can (later, by someone else) be identified.
It may come as a surprise to you, but this is a tried procedure; it actually works in real life.

That's why CUI is only a recommendation, not a requirement: you can achieve the goal without it.

On the topic of contacting an IdP:

I'm sorry I have to say this, but much of your post is a rant which essentially says that your national roaming operator does a bad job. That may be true or not; if it is, then that's a national problem you will need to sort out nationally.

FYI: many of the contact mails of personnel in the eduroam Operations database are *personal* email addresses, and yes, we do have a privacy problem with announcing those publicly. We are working on a system which would eventually allow admins to send messages to the respective other side with a web form, which does not disclose the mail address, but delivers near-instant communication anyway. Hope you are going to like it.

If the Czech NRO is not performing as it should, then this is something to take seriously. Do you want me to escalate this to the international coordination level?

I can say from personal experience that the Spanish NRO is very helpful and they go out of their way to help track down issues when they are made aware of.

So, sorry to say it, but when reading how you write "they claim they are not willing to spend their valuable time to solve my issues." then the problem clearly seems to be near your end of the escalation hierarchy.

Dan Lukes on :

Well, here is not the platform we can solve those issues. I'm glad to meet you here as you are only person willing to discuss those things so far.

I'm aware of Eduroam's history and be sure I'm happy that it has not been used for severe criminal act yet.

But you missed. I assume neither laziness nor intentional help to criminal. I assume poor design of Eduroam. It's designed the way that those who are affected by risk can do nothing with it. And those who can do something have motivation to do nothing.

It seems my English is not good enough to express what I believed to say.

I would not like to discuss other's intentions. I just claimed conclusions.

CUI is just optional, so SP can't rely on it. IdP are not obliged take any countermeasures and have no motivation to take countermeasures related to stolen/leaked credentials voluntarily.

Eduroam is cheaters friendly.

"Complaint from SP to realm's responsible person" is only way to solve issues, but contact addresses are considered secret.

Eduroam is tweaked to make complain hard. So it's rogue users friendly.

You just confirmed conclusions I said. Yes, you explained it's for the sake of unlimited privacy, but it doesn't change the matter.

I had no other intention that name the Eduroam is unbalanced badly and I did it already.

----------------------

Be sure I will bless any system that will allow me to send contact directly.

------------------------

And thank you for the kind offer. You properly recognized I had very bad experience with Czech NRO in the past.

I can take to be "L'Enfant-terrible" of Czech Eduroam - if it will help to make it better. But I have no faith an escalation can help. I would like not be "bad guy" - for nothing.

I learned how not to depend on NRO's help.

Despite I believe the Eduroam will not be used for a severe criminal or terrorists act, the question rather "when" than "if". And Eduroam is not ready for threat where every minute of delay make things much worse. It take days to discover contact address of RA then receive response from RA. I regret SP who will be affected by it as it will cause big shame.

On the other side, I fully recognize Federation sovereignty to make decision and to declare priorities.

I just named the results I see.

Dan Lukes on :

Just short technical quite taken from RFC4372 (CUI):

------------
When the home network assigns a value to the CUI, it asserts that this value represents a user in the home network. The assertion should be temporary -- long enough to be useful for the external applications and not too long such that it can be used to identify the user.
------------

Thus, CUI, if implemented properly, can't be user as persistent inter-session ID. Thus it's not suitable for blocking of particular user.

Yes, Eduroam may FORCE IdP to use other implementation CUI than RFC suggests. Such implementation may be suitable for blocking. As far as I know, it didn't happened. Thus SP can't depend on it (not counting the CUI is optional at all).

The author does not allow comments to this entry

Add Comment

Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
Form options

Submitted comments will be subject to moderation before being displayed.