...
3a. Requirements and recommendations
| # | Name | Description | Status | Tools | Review comments |
|---|---|---|---|---|---|
| 1 | policy (Ch 6) | NRO has signed the appropriate version of the policy | MUST | OT checks in official archive (OT manually) | |
| 2 | 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 (OT automatically, manually if not possible) | |
| 3 | 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 | OT interviews NRO (OT manually) or NRO self-assessment (NRO self) | |
| 4 | policy (Ch 6) |
| Provide trustworthy and secure transport of all private authentication credentials (i.e.passwords) that are traversing the eduroam infrastructure. | MUST | Check authentication flows to ensure that EAP is used (OT automatic) | |
| 5 | 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 authentication flows to ensure that EAP is used (OT |
| automatic) | |
| 6 | policy (not 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. Policy says 24 working hours but 24 working hours is more than 2 days !?! A ticket on TTS should be opened by the respective NRO representative, and closed with a short comment on the performed action.
| NROs should appoint at least one representative to the eduroam SG | SHOULD | Check mailing list membership and meeting participation (OT manually) | |||
| 7 | policy (Ch 6) | Participate in the work of the SG | MUST | Check mailing list membership and meeting participation (OT automatic, manually if not possible) | |
| 8 |
policy (not Ch 6) |
| The use of RADIUS/TLS is recommended | RECOMMENDATION | Check server configuration and issued certificates (OT automatic) | |
| 9 |
| policy (not 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. Policy says 24 working hours but 24 working hours is more than 2 days !?! A ticket on TTS should be opened by the respective NRO representative, and closed with a short comment on the performed action. | SHOULD | OT lists outages from the monitoring systems (OT automatic) |
| , then checks SG mailing list archive |
| and TTS (OT manually). |
| No unscheduled maintenance should have taken place since last audit (or during the last 12 months). |
| 10 | policy (not 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 (help needed from the CERT teams?) since last audit or from the last 12 months (OT manually) | This sounds like we expect them. | ||
| 11 | policy (not Ch 6) | Malfunction in a member federation should be announced to the eduroam OT and optionally 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 lists outages from the monitoring systems (OT automatic) and checks from TTS and the SG mailing list archive if malfunction has been reported (OT manually). Time period: Since last audit or the last 12 months. | So if there are never issues, people don't score? |
| 12 | policy (not Ch 6) | Participating federations are encouraged to check sent 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) | Check sent VLAN attributes (OT automatic) Contact institutions directy to check if sending is intentional (OT semi-automatic - contact info in eduroam database). Check also at federation TLRs (NRO self) | An NRO may also decice to drop everything, right, if agreed by members. |
| 13 | 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 | This is not really possible to check. But if eduroam OT learns of this kind of violation of the policy, NRO should loose many audit points, in order to courage NROs to report this to eduroam OT. | Tools are rather passive again. If people never report anything, they score? Or they fail? |
| 14 |
This is not really possible to check. But if eduroam OT learns of this kind of violation of the policy, NRO should loose many audit points, in order to courage NROs to report this to eduroam OT.
| 15 | 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 authentication flow through ETLRS (OT automatic) | |
| 16 | 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 (NRO self) | |
| 17 | policy (Ch 6) | AAA server: The server MUST generate F-Ticks and send them to the monitoring infrastructure. | REQUIRED/MUST | Check received F-ticks (OT automatic) and/or server configuration (NRO self) | |
| 18 | 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 (OT automatic) | |
| 19 | policy (Ch 6) | The server MUST be setup to allow monitoring requests from the monitoring service | MUST | Check server configuration and monitoring results (OT automatic) | |
| 20 | 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 (NRO self) | |
| 21 | 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 (OT automatic) | |
| 22 | policy (Ch 6) | NRO MUST set up a web server in order to publish information about the eduroam service, including information with respect to the participating institutions, as well as practical information on how to use eduroam. | MUST | Check if website is present (OT manual) | |
| 23 | 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 (OT automatic) 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... | |
| 24 | policy (Ch 6) | The national eduroam website should be available in English | SHOULD | Check if website is present (OT manual - there is no specified URL to the English version, e.g. www.eduroam.tld/en/) | |
| 25 | 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 eduroam database (OT automatic) | |
| 26 | policy ( Ch 5.7) | The NRO must provide the following data to the eduroam OT: Estimated coverage inside themember federation | MUST | Check when the eduroam database data for the NRO has been updated (OT automatic) | |
| 27 |
| Skip this Note from MOL: accounting packets may include GDPR-sensitive data. On govroam we have elected to NOT accept accounting packets... | I don't agree: well, we for instance accept the requests right away and discard. | ||
| 28 | 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 (NRO self) | |
| 29 | policy (Ch 6) | Provide 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 (OT automatic?) | |
| 30 | policy (Ch 6) | Provide a DNS-based discovery module for outgoing RADIUS/TLS dynamic discovery. | RECOMMENDED | Check issued certificates and server configuration (OT automatic?) | |
| 31 | 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 (OT automatic), check location and configuration (NRO self) | |
| 32 | policy (Ch 6 | Logs of all authentication requests and responses SHOULD be kept. The minimum log retention time is six months, unless national regulations require otherwise. The information in the requests and responses SHOULD as a minimum include: The time the authentication request was exchanged. The value of the User-Name attribute in the request ('outerEAP-identity'). The value of the Calling-Station-Id attribute in authentication requests. The result of the authentication. The value of Chargeable-User-Identity (if present in Access-Accept message). | RECOMMENDED | Check server configuration and logs (NRO self) |
3b. Secondary Requirements and recommendations (MOL)
...