eduroam-US Best Practices

Below is a compliation of best-practices for eduroam-US participating institutions.  These are meant to be guidelines which will enable members of eduroam-US to stay up-to-date and secure with little extra work by RADIUS administrators.

  • Configure RADIUS servers by DNS name rather than IP to facilitate changes in infrastructure without reconfiguration of local or top-level servers.
  • RADIUS server certificates should be signed by a Certificate Authority with signing certificates already in the trusted store of most operating systems.  Examples include Comodo, Thawte, and Verisign.  This will ease configuration of user devices.
  • RADIUS secrets should be of the same complexity as strong passwords and greater than 12 characters.  Since these will change somewhat infrequently and are only typed when first created or changed the extra complexity should not burden the administrators.
  • Make your client specification as specific as possible and avoid wildcard handlers so that only TLRSs can forward requests to your server with the shared secret.
  • Be sure not to forward sub-domains i.e. eduroamer [at] subdomain.realm.edu, or requests to your main domain, to the TLRS as the request will be dropped.  This is to prevent routing loops and generally is the result of a misconfiguration.  This can be troublesome for users attempting to test their own forwarding if they are unaware of the filter.
  • Configure your eduroam SSID such that only usernames of the form user [at] institution.edu are accepted.  Often schools will allow simply "user" without a realm for their local users, but when those users travel they cannot join since their configuration does not conform with the eduroam standard.  Forcing all local users to include their realm means less debugging later.
  • Configure your RADIUS server to include the Framed-MTU attribute.  This attribute should be set to, or slightly less than, the MTU of all hardware which will be passing your EAP traffic.  This includes your wireless, or wired infrastructure, any passive (inline) firewalls, IPS, or IDS, and your upstream connection.  For example, most hardware has an MTU of at least 1500 bytes.  If an eduroamer visiting your institution comes from a school whose RADIUS server's SSL certificate is 2048 bit, then with its encoded overhead in EAP, the frames resulting from transmitting it will be larger that 1500 bytes, and will be silently dropped.  If you include the appropriate Framed-MTU attribute the certificate will be appropriately fragmented in the Access-Challenge frame, and succeed.
  • Make sure that any firewalls/router allow fragmmented UDP packets to/from the eduroam-US servers and your servers.
  • Make sure to set your proxy timeout to 10 seconds. We try to guarantee that the eduroam-US servers will always respond within 10 seconds.