Frequently Asked Questions - Security

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.

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.

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.

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.

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 implementation of the Chargeable 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.

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.

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 un-configured 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 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.