...
Number | Name | Description | Status | Tools |
---|---|---|---|---|
1 | policy (Ch 6) | NRO has signed the appropriate version of the policy | MUST | OT checks in official archive |
policy (before Ch 6) | NROs should appoint at least one representative to the eduroam SG | SHOULD | OT checks meeting participation | |
policy (before Ch 6) | Scheduled maintenance work performed by the NRO within the respective federation should be announced two (2) days in advance through the SG mailing list. For unscheduled maintenance the announcement should preferably be made 24 hours in advance. A ticket on TTS should be opened by the respective NRO representative, and closed with a short comment on the performed action. | SHOULD | OT checks SG mailing list archive and TTS as well as outages in the FTLR connections from the monitoring systems | |
policy (before Ch 6) | NROs should regularly report to the OT about the number and type of security incidents | SHOULD | OT cross-checks its archives with other security incident archives | |
policy (before Ch 6) | Malfunction in a member federation should be announced through the SG mailing list. A ticket on the TTS should be opened by the respective NRO representative and closed with a short comment on the performed action | SHOULD | OT checks mailing list archives and possible other sources (including social media) regarding malfunction reports. | |
policy (before Ch 6) | Participating federations are encouraged to check send VLAN attributes (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID) , and to investigate whether the sender is sending these attributes inadvertently or not, and then take appropriate action. | SHOULD (encouraged) | OT checks sent VLAN attributes and contact institutions directy to check if the NRO has been in contact regarding this. | |
policy (Ch 6) | Violation of the Policy declaration MUST be reported to the OT, and MUST be presented to the SG and escalated to the NREN PC in serious cases. | MUST | Check forums and social media etc and cross-check with OT and SG mailing list archives & meeting minutes. | |
policy (Ch 6) | Establish the necessary infrastructure for eduroam, and ensure that it is maintained according to the eduroam service requirements and best practices | MUST | Check RADIUS server configuration and version number | |
policy (Ch 6) | Establish user-support service for its end users, as explained in Section 5.1, “User Support Processes” | MUST | Check reported cased to identify the flow | |
policy (Ch 6) | Participate in the work of the SG | MUST | Check if presence on mailing lists. | |
policy (Ch 6) | Provide the information for the eduroam database | MUST | Check eduroam database | |
policy (Ch 6) | Establish and maintain a website, including information with respect to the participating institution, as well as practical information on how to use eduroam. | MUST | Check if website is present | |
policy (Ch 6) | The national eduroam website should be available in English | SHOULD | Check if website is present | |
policy (Ch 6) | Provide trustworthy and secure transport of all private authentication credentials (i.e.passwords) that are traversing the eduroam infrastructure. | MUST | Check server configuration | |
policy (Ch 6) | Ensure that user credentials stay securely encrypted end-to-end between the user’s personal device and the identity provider when traversing the eduroam infrastructure. A rationale for this requirement can be found in Appendix A of the eduroam policy. | MUST | Check server configuration | |
policy (Ch 6) | Ensure that eduroam servers and services are maintained according to the specified best practices for server build, configuration and security, with the purpose of maintaining a generally high level of security, and thereby trust in the eduroam Confederation. | MUST | Check server configuration and practices used. | |
policy (Ch 6) | AAA server: RADIUS datagram processing to and from the ETLRS, as per RFC2865 or any other of the recommended transports (e.g. RADIUS/TLS). The server MUST be able to proxy RADIUS datagrams to other servers based on contents of the User-Name attribute. | REQUIRED/MUST | Check server configuration | |
policy (Ch 6) | AAA server: RFC3580 (EAP over RADIUS). The server MUST proxy EAP-Message attributes unmodified, in the same order as it received them, towards the appropriate destination. | REQUIRED/MUST | Check server configuration | |
policy (Ch 6) | AAA server: The server MUST generate F-Ticks and send them to the monitoring infrastructure. | REQUIRED/MUST | Check received F-ticks and/or server configuration | |
policy (Ch 6) | If dynamic RADIUS routing (see eduroam policy Section 2.1.1.2) is used by the individual SPs, then it is the responsibility of the respective NRO to ensure that appropriate F-Ticks are sent to the monitoring infrastructure, either by enforcing that the SPs send them to the monitoring infrastructure themselves, or by collecting information of the authentication events and sending these on to the monitoring infrastructure on the SP’s behalf. | REQUIRED/MUST | Check issued certificates for dynamic routing and F-Ticks from corresponding SPs | |
policy (Ch 6) | The server MUST be setup to allow monitoring requests from the monitoring service | MUST | Check server configuration and monitoring results | |
policy (Ch 6) | All relevant logs MUST be created with synchronisation to a reliable time source (GPS or in its absence NTP/SNTP) | MUST | Check server configuration | |
policy (Ch 6) | The server(s) MUST respond to ICMP/ICMPv6 Echo Requests sent by the confederation infrastructure and confederation monitoring service | MUST | Check monitoring results and/or server configuration | |
policy (Ch 6) | NRO MUST set-up a web server in order to publish information about the eduroam service. | MUST | Check if website is present | |
policy (Ch 6) | The address of the web server with information about the eduroam service SHOULD be www.eduroam.<tld>. | SHOULD | Check if web site exists Note from MOL: have encountered many organisations that are prevented by policy from registering a TLD-level domain, but they can always do tld/eduroam... | |
policy (Ch 6) | An NRO’s web server MUST provide data in XML format, based on the specification defined by the SG, and available at http://monitor.eduroam.org/database | MUST (soon outdated xml → json) web page → https://monitor.eduroam.org/fact_eduroam_db.php | Check if data exists | |
policy (Ch 6) | AAA server: RFC2866 (RADIUS Accounting). The server SHOULD be able to receive RADIUS Accounting packets if a service provider opts to send that data. | SHOULD | Check server configuration Note from MOL: accounting packets may include GDPR-sensitive data. On govroam we have elected to NOT accept accounting packets... | |
policy (Ch 6) | AAA server: RFC2866 (RADIUS Accounting). If RADIUS Accounting is supported, RADIUS Accounting packets with a destination outside the federation MUST NOT be forwarded outside the federation, and MUST be acknowledged by the FLRS. | MUST | Check server configuration |
3b. Secondary Requirements and recommendations (MOL)
policy (Ch 6) | A RADIUS/TLS endpoint open for connections from all other eduroam participants to enable the receiving end of RADIUS/TLS dynamic discovery. | RECOMMENDED | Check issued certificates and server configuration | |
policy (Ch 6) | A DNS-based discovery module for outgoing RADIUS/TLS dynamic discovery. | RECOMMENDED | Check issued certificates and server configuration | |
policy (Ch 6) | Servers SHOULD be highly available, for example, by deploying multiple separate servers in a failover configuration in different IP subnets on different physical locations. | RECOMMENDED | Check server number, location and configuration (including IP addresses) | |
3b. Secondary Requirements and recommendations (MOL)
# | Name | Description | Status | Tools | # | Name | Description | Status | Tools |
---|---|---|---|---|---|---|---|---|---|
1 | SSID | NROs MUST ensure all members only deploy the service under the 'eduroam' SSID. Non-compliant networks MUST NOT be labelled 'eduroam' or anything similar to avoid confusion for visitors. The eduroam SSID MUST NOT be shared with other network services. | MUST | ||||||
2 | 802.11 only | NROs MUST ensure members offer eduroam ONLY on 802.11-based wireless media (i.e. NOT over bluetooth etc). | MUST | ||||||
3 | 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 | ||||||
4 | 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 | ||||||
5 | 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 | ||||||
6 | Shared secrets | RADIUS shared secrets MUST have sufficientropy (16+ characters), and MUST NOT be reused (each RADIUS server must have a unique shared secret for each trust relationship it participates in) | MUST | ||||||
7 | 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 | |||||
8 | Published locations | NRO ensures all member venue location data is added to the eduroam database (for use in maps etc.) | SHOULD | ||||||
9 | Web presence | NRO and members SHOULD publish a site at (tld)/eduroam documenting eduroam activities and locations in their NREN | SHOULD | Evidence: URL/screenshots | |||||
10 | Contact data | NRO has arranged 365 cover of all named contact points (mail and phone redirects for leave etc) | SHOULD | ||||||
11 | CAT enabled | NRO maintains a CAT adminstrator/config for its own staff and recommends CAT usage to all members. Wherever possible, CAT SHOULD be used to assist with client deployments. | SHOULD | ||||||
12 | Training | NRO provides eduroam training to member organisations (either directly or through a third party) | SHOULD | ||||||
13 | User education | NRO and members SHOULD implement training for end users on the expected legitimate behaviours of eduroam systems. Many attacks rely on incorrect user responses to inappropriate service behaviours such as password requests, certificate mismatch warnings etc. | SHOULD | ||||||
14 | Clarity | NRO members SHOULD act to minimise any possibility of confusion between eduroam and other guest services they may offer (e.g. to prevent credentials being inappropriately presented) | SHOULD | ||||||
15 | Certificate type | NRO and members SHOULD undertake a risk-based selection of private vs. public CAs for their RADIUS infrastructure. Private is usually preferrable. | SHOULD | ||||||
16 | EAP Types | NRO should advise members that they SHOULD use at least one of TLS, TTLS, EAP-FAST or PEAP (see reference 9) | SHOULD | ||||||
17 | Anonymous Outer Identities | Where supported by the EAP type and the supplicant, it is strongly recommended that anonymous outer identities SHOULD be used. (see reference 10) | SHOULD | ||||||
18 | Enable CUI | Chargeable User Identity (CUI) SHOULD be implemented to enhance accountability of end user bahaviour by pseudonymous means. | SHOULD | ||||||
19 | Cert revocation | If an EAP type which uses client side certificates is used (e.g. EAP-TLS), a robust revocation process SHOULD be in place to cover loss, theft or compromise of devices. | SHOULD | ||||||
20 | Rogue detection | Where available, NRO and members SHOULD monitor for rogue access points. IF possible, automated suppression of rogues SHOULD be implemented. | SHOULD | ||||||
21 | Wireless IPS | Where available, NRO and members SHOULD implement Wi-Fi Intrusion Prevention Systems (IPS) to detect AP spoofing, malicious broadcasts etc. | SHOULD | ||||||
22 | Manual configuration | Where CAT-assisted end user device configuration is not possible, it SHOULD NOT be undertaken by the end user. Administration staff should undertake such configuration to ensure it is correctly completed. Manual configuration is not recommended. | SHOULD NOT | ||||||
23 | Maps | Websites MAY includes graphical maps of accessible locations, noting additional services such as charging points | MAY |
...