General Principles
eduroam use for the mobile user should be familiar and seamless whether they are at their home institution or at another eduroam-enabled site. It should complete the authentication process and once signed on allow internet access with as little filtering as possible[1]. If any port filtering occurs, the acceptable minimal set of ports is outlined in the eduroam Policy Service Definition[2].
Specifications and Operational Requirements: Service Providers
For specific details, CAF references section 6.3.3 of the eduroam Policy Service Definition[3] document, starting on page 32.
Notable exceptions to this are:
- NAT is allowed if sufficient capability to back trace a user is enabled.
- WPA/TKIP is no longer supported
No Use of Captive Portals
Associating to the eduroam SSID must not require passage through a captive portal. The authentication uses 802.1x protocols at OSI layer 2 and given that the device has yet to receive an IP address, attempting this would be extremely problematic. It would also violate the principle of end-to-end encryption of the user’s credentials[3] and would result in a security risk to the service.
No Pre-registration of MAC or ‘Allowed’ eduroam Domains by the Site Operator
Service quality of eduroam is severely hampered and rendered ineffective if any site requires MAC addresses to be registered before gaining access to eduroam or if a visiting domain must be registered in advance of using eduroam (there are over 17,000 domains and growing).