Frequently Asked Questions

This is the Frequently Asked Questions list for eduroam-US. As new questions are asked by individuals and institutions we will add them here. If you find anything missing please feel free to contact the eduroam-US team!

General (8)

eduroam is not a replacement to your guest network, it is a complement to make your guest network and your community compatible with other eduroam participants.

Enabling eduroam on your campus provides four main features:

1) it allows your campus to welcome eduroam enabled visitors in a strongly authenticated way (the strong authentication also provides a way to authorize users to different resources)

2) it allows your own users to travel to eduroam enabled locations around the world (some places only have eduroam as a guest Wi-Fi)

3) it saves provisioning time to your institution and to the visitors since authentication is automatic and access is immediate

4) it improves security since your visitors use a standard protocol (WPA2-enterprise, 802.1X) that encrypts traffic between their devices and the Wi-Fi infrastructure

A perfect use-case for eduroam is the iPhone.  Joining a traditional, web-based, visitor wireless network on an iPhone can be a trying endeavor.  First you have to determine what the visitor network's SSID is.  Then, after associating to the network you may, or may not, be able to surf, check email, etc. Opening a web-browser, zooming and moving around the web interface to read the user agreement and providing some degree of credentials is tedious enough on a mobile device.  Add to that the difference in configurations for each visited institution and this problem is greatly magnified.

With eduroam, on either an iPhone or a laptop, configuration of the device is simplified.  The user credentials can be stored locally, the eduroam SSID is broadcast, and joining it is automatic.

InCommon and eduroam are complementary federations satisfying different needs in the academic communities.  At this point an integration between the two is not complete. InCommon uses Web based authentication and authorization and eduroam uses EAP and RADIUS. 

For an end-user, joining eduroam should appear no different from joining any other encrypted (WPA/WPA2) wireless network, with the exception that they will be expected to verify a certificate provided by their home institution via the encrypted tunnel.  Their home institution can provide this certificate to the user in a number of ways, as outlined in the administrator's guide.

Soon we would like to be able to serve as your RADIUS server if your institution doesn't have the time, resources, or expertise to do so.  If you have a local directory service we hope to provide the RADIUS fabric to connect your wireless network to the directory while working with you.  We can also provide limited Directory Services for special events (conferences, etc...)

The short answer is as follows:  The supplicant (authentication client) on the eduroamer's computer creates an encrypted tunnel from her laptop all the way back to her home institution's RADIUS server, whether it is in the next room, or across an ocean.  The only party privy to the contents of that tunnel are the eduroamer and their home institution.  The home institution attempts to authenticate the eduroamer's credentials and replies, with either Accept or Reject, to the site from which the eduroamer is attempting to gain access.  If the provided credentials are accepted by the eduroamer's home institutions then the local institution grants access to the eduroamer, and they are able to access the network as if they were a local users.

The long answer involves 802.11i, 802.1x, RADIUS, and EAP all working in concert.

Anyone from a participating institution.  This facilitates productivity for visiting faculty, students, and employees while away from home, without any additional configuration to their computers or mobile devices.

Any Research or Education based institution can join eduroam. This includes: Universities, Colleges, Elementary-Middle-High schools, Research Labs, Research Departments of companies.

Security (7)

The security of RADIUS does not only rely on the shared secret but rather the IP addresses of the servers configured to use that secret.  A RADIUS server should not be configured to accept an authentication attempt from an unconfigured IP even using the correct RADIUS secret (please see the eduroam-US Best Pratices document in the Administrators Guide for more details).  It is possible to spoof the source-address of a UDP packet but this should be mitigated by properly configured border and upstream routers which will drop addresses originating from incorrect networks.  Moreover each instutition must take further local steps to prevent "rogue" users impersonating the local RADIUS server(s).

The use of RadSec mitigates any risk posed by shared secrets through the use of SSL/TLS certificates in place of RADIUS shared secrets, along with using TCP as the transport which makes spoofing more difficult.  For more information on RadSec please see that section of the Administrator's Handbook.

While PAP passwords remain in plaintext in the "inner-tunnel" the 802.1x SSL tunnel, in either TTLS or PEAP, exists from the users' supplicant all the way back to the home RADIUS server.  All EAP authentication traffic, including the plaintext password, is encrypted within the SSL tunnel which terminates on the RADIUS server itself.  At that point the only users who should have access to the un-encrypted traffic are local administrators/users on the RADIUS server itself.  From there the transit to/from the directory service (IdP) must be secured according to local policy.

With CHAP the security challenge rests in the secure storage of unencrypted passwords at rest, rather than in the transit of the credentials over the network.  This must be addressed by institution specific security policy.

Many of the same tools you have to address local users and security incidents are still available but "Blacklisting" of the users' MAC address is a common approach.  One may be inclined to simply stop allowing eduroamers from an entire realm from joining to address a single user abusing the local network.  In extreme circumstances this may be necessary and is a control applied at the RADIUS server itself.

In addition to traditional wireless access control mechanisms as described above, the eduroam-US team, along with others in the eduroam community are pursuing implemntation of the Chargable User Identity (CUI).  This unique identifier will allow an administrator to correlate a specific remote user with their login attempts at home.  An eduroam administrator who is dealing with such a problem can block the CUI locally and report the CUI back to the home institution.  The home institution may then can block the user's account locally, seek to remediate the problem if it is caused by malware, and if necessary pursue disciplinary procedures.

The same community trust fabric that makes eduroam responsive to brute-force attempts against eduroam institutions makes it responsive to other security incidents within the network.

Unlike other directory-service authenticated and publically accessible services eduroam is significantly more restricted and has advantages.  While a user with any internet connection can, in theory, attack a webmail portal or other internet accessible service, to do so with eduroam means that the user is associating to an eduroam-enabled institution's network.  The eduroam community is tightly-knit and getting communication between the appropriate institutions in the case of a security interest is of the utmost importance to the community as a whole.

Going forward the eduroam-US project plans to create a eduroam-US forum, mailing-list, or other mass communications medium for discussion between administrators.  This way admins will get to know one another before an incident arises.  Repore from such interaction will make even easier addressing any possible security incidents.

eduroam-US can aide participating institutions in getting in touch with their peers at other participating institutions in case of abuse generated by a visitor using the eduroam service -- either in the US or internationally.

Contact us directly by using the form on the website under "Send us a message". Your request will be forwarded to the appropriate person at the remote site. Please include the official complaint to support your request.

To protect users from Man-in-the-Middle (MITM) attacks it is critical that an institution's certificate is signed by a well-known Certificate Authority (CA), which is shipped with every user's Operating System.  Such well known signing authorirites include Verisign, Thawte, Comodo, and many others.

If your RADIUS server's certificate is not signed by a CA which ships with standard operating systems then users must import the signing CA's certificate into their local key-store before connecting to eduroam so that the eduroam RADIUS server's certificate can be validated.

In the case of Microsoft Windows with EAP-PEAP, if the signing certificate is not in the Certificate Store then the connection will fail silently.  An administrator may want to uncheck the "Validate server certificates" checkbox on his own computer to use with a set of temporary credentials.  If authentications succeeds then there is likely an issue with the Certificates and/or the Certificate Store.  If it continues to fail then the problem is likely in another subsystem.  In this way turning off validation can help to identify a root-cause of a EAP-PEAP failure but will expose the admin to potential MITM attacks.  For this reason it is not a satisfactory solution for end-users.

Certificate Authority certificates must be stored in users' local certificate stores.  This allows the user's supplicant to verify the authenticity of the certificate communicated to the supplicant at association/authentication time.  This combined with connecting to eduroam at their home institution before traveling abroad for both testing/debugging as well as being presented the RADIUS server's certificate helps to mitigate the risk of Man-in-the-Middle Attacks.

For further information on the subject please see the FAQ entry on Validating Server Certificates with the Microsoft Windows Supplicant.