FAQ

Internet2 Higher Education members do not pay the eduroam annual subscription fees directly; they are included as a benefit of Internet2 Higher Education membership. However, if you require changes to the legal agreement that are not state mandated, you will be charged the $700 registration fee. If there are no changes to the legal agreement, the $700 charge is waived. We may also waive the fee for changes that are mandated by state law, as determined by Internet2.

The registration fee covers the adminstrative work related to onboarding an eduroam subscriber. However, Internet2 will waive the registration fee for organizations that do not ask for changes in the eduroam Connector Agreement. When a change is requested by any subscriber, Internet2 incurs legal costs for reviewing the request. We may also waive the fee for changes that are mandated by state law, as determined by Internet2.

The cost is detailed on the eduroam fees page.

Eduroam is not a replacement for 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 for your institution and for your visitors since eduroam 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

WPA2-Entrerprise (aka 802.1x) is required to join eduroam. The RADIUS server of the joining institution that is used to operate WPA2-Enterprise locally will be connected to the national infrastructure.

A perfect use case for eduroam is the smart phone. In that case, joining a traditional, web-based, visitor wireless network can be a trying endeavor. First you have to determine the visitor network’s SSID. Then, after associating to the network you may or may not be able to access email or the web. 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, configuration of any device is simplified. The user credentials can be stored locally, the eduroam SSID is broadcast, and joining is automatic.

The connection of the institution’s RADIUS server to the national infrastructure takes an average of two hours. This step will allow users of that institution to visit other eduroam campuses. Making the local campus an eduroam hotspot takes more time since it involves the broadcasting of the network name across campus and some backend network engineering (subnets and firewall configurations). You will also want to allow for time to inform your community about the new offering and its local support.

One of the main rules of eduroam is that visitors have to first contact their home institution to seek support. This said, many places elect to support eduroam visitors locally since in many cases it doesn’t add much burden to the local help desk.

All eduroam users are authenticated in the form user@realm (e.g. username@institution.edu). In case of abuse, the local institution can block users the same way it is done locally (MAC address and username/realm filtering). For DMCA complaints, the request can be forwarded to the institution of the offending user directly.

No. Neither InCommon participation nor Internet2 membership is required for eduroam subscribers. InCommon and eduroam are complementary federations satisfying different needs in the academic communities. InCommon uses SAML and Web-based authentication and authorization and eduroam uses EAP and RADIUS. The InCommon Federation is intended for access to applications and services; eduroam facilitates access to wireless networks.

For the individual, joining eduroam should appear no different from joining any other encrypted (WPA/WPA2) wireless network. Behind the scenes, the device will need to verify a certificate provided by the home institution via the encrypted tunnel. Details are in the administrative guide.

The supplicant (authentication client) on the eduroamer’s device creates an encrypted tunnel from her device all the way back to her home institution’s RADIUS server, whether it is in the next room, or across an ocean. The only parties privy to the contents of that tunnel are the eduroamer and the 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, who can now access the network the same as local users.

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.

To facilitate stronger and more responsive engagement with the eduroam community, Internet2 sought out knowledgable, motivated volunteers to form the eduroam Advisory Committee. The eduroam-US Advisory Committee (“eAC”) is intended to be an advisory body to the Internet2 Community Architecture Committee for Trust and Identity (CACTI). Its role is to help formulate strategies and practices for US and global research and education roaming networks, report any findings, and make recommendations to CACTI and Internet2.

The eAC meets regularly as well as creating working groups as needed. You can view the committee’s charter, learn more about its mission, and view publicly available meeting minutes on its wiki page.

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 Practices 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 institution must take further local steps to prevent “rogue” users from 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 plain text 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 plain text 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 unencrypted 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 blocking 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, we are pursuing implementation 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.

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. It is very helpful if the user first connects to eduroam at the home institution for testing and debugging as well as being presented with the RADIUS server certificate. This helps to mitigate the risk of man-in-the-middle attacks.

The eduroam service in the U.S. is operated by Internet2. Internet2 operates the eduroam service for the U.S. Research and Education community. The global operator for eduroam is GEÁNT, which coordinates with Internet2 and other National Roaming Operators on matters of service policy and governance.