UPDATE ......From Tuesday 8 April 2025 we have changed the way that Single Sign-on works on this wiki. Please see here for more information:
Update
...
| Name | Description | Status | Tools | |
|---|---|---|---|---|
| 1 | Physical signage | NRO advises member organisations to deploy physical signage in areas where eduroam is available (e.g. to assist visitors with medical prosthetics) | Should | Evidence: copy of documentation/web page |
| 2 | Published locations | NRO ensures all member venue location data is added to the eduroam database (for use in maps etc.) | Should | |
| 3 | Web presence | Publishes a site at (tld)/eduroam documenting eduroam activities and locations in their NREN | Should | Evidence: URL/screenshots |
| 4 | Maps | Website (3) includes graphical maps of accessible locations, noting additional services such as charging points | May | |
| 5 | Contact data | NRO has arranged 365 cover of all named contact points (mail and phone redirects for leave etc) | Should | |
| 6 | CAT enabled | NRO maintains a CAT adminstrator/config for its own staff and recommends CAT usage to all members | Should | |
| 7 | Training | NRO provides eduroam training to member organisations (either directly or through a third party) | Should | |
| 8 | Audit trail | NROs MUST ensure that they and their members retain authentication and DHCP logs for <period defined in central policy?> to enable the cooperative resolution of identity in the event of abuse of eduroam | MUST | |
| 9 | No sharing | NROs MUST ensure that all their members enforce the policy that credentials SHOULD NOT be shared between users (or devices where device authentication is used) | MUST | |
| 10 | Physical security | NROs must advise their members that WiFi APs and cabling SHOULD be be secured as much as possible (e.g. to restrict opportunities to introduce network taps or other tampering). All servers MUST be hosted in a secure environment. | MUST | |
| 11 | ||||
| 12 | ||||
| 13 | ||||
| 14 | ||||
| 15 |
3c. Technical requirements (MOL)
| Name | Description | Status | Tools | |||
|---|---|---|---|---|---|---|
| 1 | Firewall | A layer 4 firewall MUST separate the all internet-facing RADIUS server servers and the internal network. Access must be controlled and monitored. | MUST | |||
| 2 | Firewall ICMP | Firewalls MUST permit ICMP to allow centralised monitoring of RADIUS servers | MUST | |||
| 3 | Admin access | System administration (RADIUS and associated systems) MUST be preformed over a private internal network ONLY. | MUST | |||
| 4 | DMZ connectivity | All protocols permitted access to the servers MUST be risk-assessed (e.g. SMB and RDP may present security risks) | MUST | |||
| 5 | External port access | A deny-all policy MUST be applied, permitting only the minimum ports necessary for authentication (e.g. UDP 1812, Status-Server 18121, TCP 2083 if RadSec is used). UDP 1645 MUST NOT be used. | MUST | |||
| 6 | Internal port access | A deny-all policy MUST be applied, permitting only the minimum ports necessary for administration functions (e.g. TCP 3389 for RDP or TCP 22 for SSH) | MUST | |||
| 7 | Patch management | All server operating systems and applications MUST be kept fully patched and up to date (SysAdmins must apply risk assessment criteria to deciding whether to deploy early patches against zero-day exploits or to follow stable releases) | MUST | |||
| 8 | Consistent time | All servers MUST be configured against the same time-synched NTP server to minimise issues with log reconciliation. | MUST | |||
| 9 | Backups | All servers and configuration files MUST be regularly backed up (as a minimum after every configuration change) | MUST | |||
| 10 | Monitoring | Servers MUST be configured to detect and log rogue behaviour such as password brute forcing. Where automated defence is possible, it SHOULD be deployed (e.g. increasing authentication back-off times) | MUST | |||
| 11 | Authentication logs | All authentications to eduroam infrastructure systems MUST be logged. Such logs may constitute personal data and MUST be managed in a GDPR-compliant way. All such logs should be timestamped against a synced NTP source and held for a minimum of <central policy specified period?>. | MUST | |||
| 12 | Alerts | Servers MUST be configured to send alerts (with copies of logs) to SysAdmins so that incidents can be detected dn responded to in real time. Alert systems should be regularly tested for effectiveness. | MUST | |||
| 13 | Traffic interception | NROs MUST NOT deploy interception technology or otherwise monitor the content of visitor or roaming traffic (e.g. do not use TLS or SSL interception proxies) | MUST NOT | |||
| 814 | RadSec | If RadSec is used, X.509 certificates must be used to identify RADIUS servers | MUST (optional) | |||
| 915 | Network segmentation | Network segmentation SHOULD be considered, placing roaming users into a separate segment to local organisation users. | SHOULD | |||
| 1016 | VLAN spoofing countermeasures | the visitor network design should prevent devices from mailiciously placing themselves into unauthorised VLANs | SHOULD | |||
| 1117 | External penetration testing | NROs SHOULD regularly conduct vulnerability assessment of internet-facing eduroam infrastructure. | SHOULD | |||
| 1218 | Internal vulnerability testing | NROs SHOULD regularly conduct vulnerability testing from within the internal network of eduroam infrastructure. | SHOULD | |||
| 1319 | Non-eduroam guests | NRO and its members may offer a public guest Wi-Fi service for thsoe unable to access eudroam; such users SHOULD be provisioned onto a separate network from eduroam visitors, with its own authentication, monitoring, and anti-circumvention measures. | SHOULD | |||
| 20 | Redundancy | NRO-level RADIUS servers SHOULD be deployed in a redundant, diverse configuration to maximise availability and meet SLAs | SHOULD | |||
| 21 | Dedicated servers | NRO-level RADIUS servers SHOULD be dedicated to the task, not supporting other local or national services, in order to reduce their attack surface. | SHOULD (MUST?) | |||
| 22 | Hardened servers | NRO-level RADIUS servers SHOULD be hardened to recognised best practice standards (includes secondary/backup RADIUS, certificate servers etc.) | SHOULD | |||
| 23 | ||||||
| 24 | ||||||
| 25 | ||||||
| 26 | 14 | 15 |
4. References
| Reference: | URL | |
|---|---|---|
| 1 | eduroam Compliance Statement | https://www.eduroam.org/support/eduroam_Compliance_Statement.pdf |
| 2 | European Confederation eduroam policy | https://www.eduroam.org/wp-content/uploads/2016/05/GN3-12-194_eduroam-policy-for-signing_ver2-4_1_18052012.pdf |
| 3 | eduroam Service Definition | https://www.eduroam.org/wp-content/uploads/2016/05/GN3-12-192_eduroam-policy-service-definition_ver28_26072012.pdf |
| 4 | Jisc govroam code of practice: | 20171124 code of practice v2(4).pdf |
| 5 | UK NIST security standards | https://nvd.nist.gov/ncp/repository |
| 6 | UK CIS security standards | https://www.cisecurity.org |