...
| # | Name | Description | Status | Tools | Review comments | who | how |
|---|
| 1 | policy (Ch 6) | NRO has signed the appropriate version of the policy | MUST | OT checks in official archive (OT manually) |
| ot | M |
| 2 | policy |
not NROs should appoint at least one representative to the eduroam SG | SHOULD | | Establish the necessary infrastructure for eduroam (set-up FLRS and exchage traffic in expeced manner) | MUST | Check RADIUS server basic configuration (OT automatically) |
| ot | A |
Check mailing list membership and meeting participation (OT manually)not The use of RADIUS/TLS is recommended | RECOMMENDATION | | 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 RADIUS server version number (OT automatically/manually) OT interviews NRO (OT manually) or NRO self-assessment (NRO self |
Check server configuration and issued certificates (OT automaticnot 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), them 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). | | Provide trustworthy and secure transport of all private authentication credentials (i.e.passwords) that are traversing the eduroam infrastructure. In other words, 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) |
|
|
|
| 5 | 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 (MAY) | Check number of servers (OT automatic), check location and configuration (NRO self) |
| ot | M |
| 6 | 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), check server configuration (NRO self) |
| ot | A |
| 7 | 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) |
| ot | A |
| 8 | 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) |
| ot | A |
| 9 | 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) |
| ot | ? |
| 10 | policy (Ch 6) | The server(s) MUST be setup to allow monitoring requests from the monitoring service | MUST | Check server configuration and monitoring results (OT automatic) |
| ot | A |
| 11 | 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) |
| ot | A |
| 12 | policy
(not Ch 6) | NROs should appoint at least one representative to the eduroam SG | SHOULD (MUST) |
| 5 | 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. |
| 6 | 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? |
| 7 | 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). | An NRO may also decice to drop everything, right, if agreed by members. |
| 8 | 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? |
9 | 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) | 10 | policy (Ch 6) | Establish user-support service for its end users, as explained in Section 5.1 in the eduroam policy, “User Support Processes” (This is not relevant for an NRO audit)
| MUST | Check reported cases to identify the flow | 11 | policy (Ch 6) | Participate in the work of the SG | MUST | Check mailing list membership and meeting participation (OT automatic, manually if not possible) |
| OT | M |
12Provide 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) | | Participate in the work of the SG (ask for reply from SG member's e-mail) | MUST (SHOULD) | Check mailing list membership and meeting participation (OT automatic, manually if not possible) |
| OT | A |
| 14 |
13Ensure 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| 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 |
authentication flows to ensure that EAP is used | if website is present (OT |
automatic14Ensure 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) | The address of the web server with information about the eduroam service SHOULD be www.eduroam.<tld>. (combine with 14)
| 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... |
| OT | M |
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)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 | | 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/) |
| OT | M |
Check server configuration (NRO self)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) | | 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) |
| OT | A |
| 18 | policy ( Ch 5.7) | The NRO must provide the estimated coverage inside themember federation to the eduroam OT.
| MUST | Check when the eduroam database data for the NRO has been updated (OT automatic) |
|
|
|
| 19 | policy (not Ch 6) | The use of RADIUS/TLS is recommended | RECOMMENDED (SHOULD) | Check server configuration and issued certificates (OT automatic) |
| OT | A |
| 20 | 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?) |
|
|
|
| 21 | policy (Ch 6) | Provide a DNS-based discovery module for outgoing RADIUS/TLS dynamic discovery. | RECOMMENDED | Check issued certificates and server configuration (OT automatic?) |
|
|
|
| 22 | 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). |
|
|
|
| 23 | 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. | N | S |
| 24 | 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? | N | S |
| 25 | 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. | OT | A |
| 26 | 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? | N | S |
| 27 | policy (Ch 6) | Establish user-support service for its end users, as explained in Section 5.1 in the eduroam policy, “User Support Processes” | MUST | NRO checks that this is the case with the FTLRs & NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) |
| N | S |
| 28 | 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 | 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. |
|
|
| 29 | 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) |
| OT | A |
| 30 |
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)| /SNTP) | MUST | Check server configuration (NRO self) |
| N | S |
| 31 | policy (Ch 6) | Logs of all authentication requests and responses MUST be kept. The minimum log retention time is six months, unless national regulations require otherwise. These logs may constitute personal data and MUST be managed in a GDPR-compliant way. The information in the requests and responses MUST 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). | MUST (in policy as SHOULD) | NRO checks that this is the case with the FTLRs & NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) |
| N | S |
| 32 |
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) | 23The 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... | | Communicate to all IdPs and SPs the obligations put on them in policy Chapters 6.3.2. and 6.3.3. (included in 3c & 3d) | MUST | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) |
| N | S |
| 33 |
24The 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 federationMUST | Check when the eduroam database data for the NRO has been updated (OT automatic) | 27 | 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 | Skip thisNote 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) | ...
|
| 19 | Implement rogue AP detection | Where available, NRO and members SHOULD monitor for rogue access points. IF possible, automated suppression of rogues SHOULD be implemented. | SHOULD | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) |
|
| 20 | Implement wireless IPS | Where available, NRO and members SHOULD implement Wi-Fi Intrusion Prevention Systems (IPS) to detect AP spoofing, malicious broadcasts etc. | SHOULD | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) |
|
| 21 | Provide physical signage | NRO advises member organisations to deploy physical signage in areas where eduroam is available (e.g. to assist visitors with medical prosthetics) (What does this mean in practice?(WBK)) | SHOULD | Evidence: copy of documentation/web page |
|
| 22 | Configuration instructions (policy) | An IdP MUST provide sufficient configuration instructions for their end users so that a unique identification of the IdP is possible for the end user at all times. | MUST | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) |
|
| 23 | Use the CAT | NRO SHOULD maintain a CAT adminstrator/config for its own staff and also recommend CAT usage to all members. Wherever possible, CAT SHOULD be used to assist with client deployments. | SHOULD | Check CAT (OT automatic), NRO verifies that CAT has been strongly recommended to |
| # | Name | Description | Status | Tools | Review Comments |
|---|
1 | Deploy a Firewall | A layer 4 firewall MUST separate all internet-facing RADIUS servers and the internal network. Access must be controlled and monitored. | MUST | NRO checks that this is the case with the FTLRs & NRO verifies that this has been communicated to 3 | Limit admin access | System administration (RADIUS and associated systems) MUST be preformed over a private internal network ONLY. | MUST | NRO checks that this is the case with the FTLRs & | eduroam IdPs/SPs (NRO self) | OT/A |
2 | Allow ICMP | Firewalls MUST permit ICMP to allow centralised monitoring of RADIUS servers | MUST | NRO shows web site with ICMP monitoring results (OT manually) | | 24 | Deprecate 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 | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) |
|
| 25 | Provide end-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 |
NRO checks that this is the case with the FTLRs & | NRO verifies that this has been communicated to eduroam IdPs/SPs and that NRO has offered to help with training implementation (NRO self) |
4 | Assess connectivity risks | All protocols permitted access to the servers MUST be risk-assessed (e.g. SMB and RDP may present security risks) | MUST | Carry out assessment (OT manually) | 5 | Regulate 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 |
|
| 26 | Prevent credential 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). Automated monitoring of high numbers of simultaneous logins may help with this. | MUST | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) Automated monitoring (OT automatic or NRO automatic) |
|
| 27 | Select a 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 |
| NRO verifies that this has been communicated to eduroam IdPs/SPs and that NROs have offered help and advice (NRO self |
)Why do we care about not running 1645. (Or even random other ports, like the hosted SP may do.67 | Regulate 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 | NRO checks that this is the case with the FTLRs & UDP fragmentation | Make sure UDP fragmentation works | MUST | Test this once a year with eduroam managed IdP - one account per organisation, verify results (OT automatic) Can be checked by peers. |
|
| 28 | Deploy secure CA servers | CA servers MUST be hosted on a dedicated, locked-down server in a secure location, configured for minimum user access. Such servers SHOULD have a fully qualified domain name, although this MAY not be published through DNS. | MUST | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) |
|
| 29 | Select an EAP Type | NRO should advise members that they SHOULD use at least one of TLS, TTLS, EAP-FAST or PEAP (see reference 9) | SHOULD |
NRO checks that this is the case with the FTLRs & | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) |
8 | Undertake 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 |
|
| 30 | Implement certificate 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 |
| NRO verifies that this has been communicated to eduroam IdPs/ |
SPs 9 | Ensure consistent timestamps | All servers MUST be configured against the same time-synched NTP server to minimise issues with log reconciliationMUST | that this is the case with the FTLRs & NRO verifies that this has been communicated to eduroam IdPs/SPs NRO checks that this is the case with the FTLRs & | authentication flows through the FLTRs, identifies the organisations utilizing client certs and shows evidence that a robust revocation process is in place (NRO self) |
10 | Make back-ups | All servers and configuration files MUST be regularly backed up (as a minimum after every configuration change) | MUST |
|
| 31 | Disable PAP | Password Authentication Protocol MUST NOT be used between access points and RADIUS servers | MUST NOT |
| NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) |
11NRO checks that this is the case with the FTLRs & Conduct 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 | | DIsable SPAP | Shiva Password Authentication Protocol MUST NOT be used, as their encryption is reversible (see reference 7) | MUST NOT |
NRO checks that this is the case with the FTLRs & | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) |
12 | Retain 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 |
|
| 33 | Disable MS-CHAPv1 | Challenge Handshake Authentication Protocol is considered weak and MUST NOT be used. | MUST NOT | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) |
|
| 34 | Use 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 |
| NRO verifies that this has been communicated to eduroam IdPs/SPs and checks FTLR logs (NRO self) |
13 | Enable Alerts | Servers MUST be configured to send alerts (with copies of logs) to SysAdmins so that incidents can be detected and responded to in real time. Alert systems should be regularly tested for effectiveness. | MUST |
|
| 35 | Set Operator-Name (policy) | Where possible, NRO and members SHOULD ensure all Access-Request packets proxied to the NRPS (FTLRs) contain the Operator-Name attribute correctly set to the relevant realm. | SHOULD | NRO checks authentication flow through the FTLRs |
NRO checks that this is the case with the FTLRs (show test results) & NRO verifies that this has been communicated to eduroam IdPs/SPs 14 | Deploy secure CA servers | CA servers MUST be hosted on a dedicated, locked-down server in a secure location, configured for minimum user access. Such servers SHOULD have a fully qualified domain name, although this MAY not be published through DNS. |
|
| 36 | Operator-Name functionality (policy) | The appearance of the Operator-Name attribute (RFC5580) in Access-Requests MUST NOT cause these requests to be treated as invalid | MUST NOT |
MUST | NRO verifies that this has been communicated to eduroam IdPs/SPs and checks FTLR logs (if possible) (NRO self) |
15 | Enable Message-Authenticator | Where supported, the Message-Authenticator attribute MUST be enabled to prevent IP spoofed fake message injection. (see reference 8) | MUST | EAP requests always carry it |
|
| 37 | Enable CUI (policy) | Chargeable User Identity (CUI) SHOULD be implemented to enhance accountability of end user behaviour by pseudonymous means. | SHOULD |
16 | Adopt AES | eduroam wi-fi services MUST implement WPA2 Enterprise with the use of the CCMP (AES) algorithm | MUST | NRO verifies that this has been communicated to eduroam IdPs/SPs |
(NRO self)17 | Don't intercept traffic | NROs and members 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 | NRO checks that this is the case with the FTLRs & | and checks FTLR logs (NRO self) |
|
| 38 | UDP fragmentation | Make sure UDP fragmentation works | MUST | Test this once a year with eduroam managed IdP - one account per organisation, verify results (OT automatic) Can be checked by peers. |
|
| 39 | Operate to default deny | NROs SHOULD advise all members to operate a default deny policy on all firewalls and access control lists, only granting specific traffic types that are required and have been risk assessed to pass. | SHOULD | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) |
|
| 40 | Adopt network segmentation | Network segmentation SHOULD be considered, placing roaming users into a separate segment to local organisation users. | SHOULD |
| NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) |
18 | Disable PAP | Password Authentication Protocol MUST NOT be used between access points and RADIUS servers |
|
| 41 | Deploy VLAN spoofing countermeasures | the visitor network design SHOULD prevent devices from mailiciously placing themselves into unauthorised VLANs | SHOULD |
MUST NOT | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) |
19
|
| 42 | Provide maps | Websites MAY includes graphical maps of accessible locations, noting additional services such as charging points | MAY | Check information on web site (OT manual) |
|
...
