...
3b. Secondary requirements and recommendations (NRO)
| # | Name | Description | Status | Tools | |
|---|---|---|---|---|---|
| 1 | Manage shared secrets | RADIUS shared secrets MUST have sufficient entropy (16+ characters), and MUST NOT be reused (each RADIUS server must have a unique shared secret for each trust relationship it participates in) | MUST | Check server configuration (NRO self) |
3c. Requirements and recommendations - IdP & SP
| Suppress Accounting | RADIUS accounting messages MUST NOT be forwarded to the eduroam international RADIUS Proxies. They may contain potentially sensitive information and therefore GDPR compliance duties. NB: conflicts with existing policy, which states it SHOULD be supported. | MUST NOT | Check accounting messages towards the TLRs (OT automatic) | ||
| Set eduroam-SP-Country | Advise NROs to set eduroam-SP-Country attribute in particular for RadSec | SHOULD | NRO verifies that this is the case (NRO self) | (etlr also does it, but not for RadSec) | |
| Deploy 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?) | NRO verifies that this is the case with the FTLRs (NRO self) | ||
| Ensure you are contactable | NRO has arranged 365 cover of all named contact points (mail and phone redirects for leave etc) | SHOULD | Randomly check quality of info in the eduroam database (OT automatic) | ||
| Conduct external penetration testing | NROs SHOULD regularly conduct vulnerability assessment of internet-facing eduroam infrastructure. | SHOULD | To be carried out by the NRO in cooperation with the national CERT team (NRO self) | ||
| Conduct internal vulnerability testing | NROs SHOULD regularly conduct vulnerability testing from within the internal network of eduroam infrastructure. | SHOULD | To be carried out by the NRO in cooperation with the national CERT team (NRO self) | ||
| Incorporate redundancy | NRO-level RADIUS servers SHOULD be deployed in a redundant, diverse configuration to maximise availability and meet SLAs | SHOULD | NRO verifies that this is the case (NRO self) | ||
| Provide administrator training | NRO SHOULD provide eduroam training to member organisations (either directly or through a third party) | SHOULD | Check NRO course/training schedules (NRO self) | ||
| Maximize eduroam coverage | NROs SHOULD/MAY provide an eduroam proxy RADIUS server to enable interested SPs outside the community to offer eduroam in their network. | SHOULD/MAY | NRO verifies (NRO self) (Added by WBK) | ||
| Enable collaboration | NROs SHOULD/MAY enable collaboration between the eduroam-enabled institutions by the use of conferences, email lists and/or Slack channels | SHOULD/MAY | NRO verifies (NRO self) Conference material are available at https://wiki.geant.org/x/5KbTC (Added by WBK) |
3c. Requirements and recommendations - IdP & SP
| # | Name | Description | Status | Tools | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Use the right 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 | NRO verifies that this has been communicated | |||||||
| # | Name | Description | Status | Tools | |||||||
| 1 | Use the right 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 | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||||
| 2 | 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) | |||||||
| 3 | Disable WPA-TKIP | The WPA specification MUST NOT be supported and the TKIP algorithm MUST NOT be employed in eduroam services | MUST NOT | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||||
| 4 | Separate non-eduroam guests | NRO and its members may offer a public guest Wi-Fi service for those 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 | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||||
| 5 | Ensure 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 | Check info on web pages and other information sources (OT manual) | |||||||
| 6 | Permit 802.11 only | NROs MUST ensure members offer eduroam ONLY on 802.11-based wireless media (i.e. NOT over bluetooth etc). | MUST | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||||
| 7 | Maintain an 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 | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||||
| 8 | Standardise end-user access | NROs MUST ensure all members offer eduroam users access to the minimum standard ports and protocols, which are specified in the eduroam policy, such that the baseline services (web email and VPN) are consistently available. | MUST | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||||
| 9 | Ensure 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 | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||||
| 10 | 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 | |||||||
| 11 | 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 recommendedto eduroam IdPs/SPs (NRO self) | |||||||
| 2 | Adopt AES | eduroam wi-fi services MUST implement WPA2 Enterprise with the use of the CCMP (AES) algorithm | MUST | 12 | 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) | |||
| 133 | 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. | Disable WPA-TKIP | The WPA specification MUST NOT be supported and the TKIP algorithm MUST NOT be employed in eduroam services | MUST NOTSHOULD | NRO verifies that this has been communicated to eduroam IdPs/SPs and that NRO has offered to help with training implementation (NRO self) | |||||
| 4 | Separate non-eduroam guests | NRO and its members may offer a public guest Wi-Fi service for those 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 | 14 | 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 communicated to eduroam IdPs/SPs (NRO self) Automated monitoring (OT automatic or NRO automatic)SPs (NRO self) | |||
| 5 | Ensure 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 | Check info on web pages and other information sources (OT manual) | |||||||
| 6 | Adopt encrypted comms | NRO SHOULD recommend to members that they use a VPN to protect communications between Access Points and the RADIUS server. (Usually there is a controller here?!? Is VPN really needed? | 15 | 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 verifies that this has been communicated to communicated to eduroam IdPs/SPs (NRO self) | ||||
| 7 | Permit 802.11 only | NROs MUST ensure members offer eduroam ONLY on 802.11-based wireless media (i.e. NOT over bluetooth etc). | MUST | 16 | 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 SPs (NRO self). NRO checks authentication flows through the FLTRs, identifies the organisations utilizing client certs and shows evidence that a robust revocation process is in place | |||
| 8 | Maintain an 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 | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||||
| 9 | Standardise end-user access | NROs MUST ensure all members offer eduroam users access to the minimum standard ports and protocols, which are specified in the eduroam policy, such that the baseline services (web email and VPN) are consistently available. | MUST | 17 | 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) | |||
| 10 | Ensure 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 | 18 | 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 SPs (NRO self) | |||
| 19 | Set Operator-Name | Where possible, NRO and members SHOULD ensure all Access-Request packets proxied to the NRPS contain the Operator-Name attribute correctly set to the relevant realm. | SHOULD | NRO checks authentication flow through the FTLRs (NRO self) | |||||||
| 20 | Enable CUI | Chargeable User Identity (CUI) SHOULD be implemented to enhance accountability of end user behaviour by pseudonymous means. | SHOULD | NRO verifies that this has been communicated to eduroam IdPs/SPs and checks FTLR logs (NRO self) | |||||||
| 11 | 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 | |||||||
| 12 | 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 eduroam IdPs/SPs (NRO self) | |||||||
| 13 | 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 | 21 | 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) | |||
| 14 | Provide end-user education | 22 | 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) | 23 | 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 passtraining 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 verifies that this has been communicated to eduroam IdPs/SPs (NRO self) |
| 24 | 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) | |||||||
| 25 | audit eduroam IdPs/SPs | NROs SHOULD regularly audit eduroam IdPs/SPs on the criteria mentioned above | SHOULD | Show documentation of audit (OT manual) (Added by WBK) |
3c. Technical requirements and recommendations (MOL)
| and that NRO has offered to help with training implementation (NRO self) | |||||
| 15 | 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) | |
| 16 | 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) |
| 17 | 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) |
| 18 | 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 verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |
| 19 | 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 (NRO self). NRO checks authentication flows through the FLTRs, identifies the organisations utilizing client certs and shows evidence that a robust revocation process is in place (NRO self) | |
| 20 | 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) |
| 21 | DIsable SPAP | Shiva Password Authentication Protocol MUST NOT be used, as their encryption is reversible (see reference 7) | MUST NOT | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |
| 22 | 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) | |
| 23 | 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) |
| 24 | Set Operator-Name | Where possible, NRO and members SHOULD ensure all Access-Request packets proxied to the NRPS contain the Operator-Name attribute correctly set to the relevant realm. | SHOULD | NRO checks authentication flow through the FTLRs |
| (NRO self) |
| 25 | Enable CUI | Chargeable User Identity (CUI) SHOULD be implemented to enhance accountability of end user behaviour by pseudonymous means. | SHOULD | NRO verifies that this has been communicated to eduroam IdPs/SPs and checks FTLR logs (NRO self) |
| 26 | 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) |
| 27 | 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) |
| 28 | 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) |
| 29 | 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) | |
| 30 | 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. | |
| 31 | 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) | |
| 32 | Deploy VLAN spoofing countermeasures | the visitor network design SHOULD prevent devices from mailiciously placing themselves into unauthorised VLANs | SHOULD |
| NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) |
| 33 | audit eduroam IdPs/SPs | NROs SHOULD regularly audit |
| eduroam IdPs/SPs on the criteria mentioned above | SHOULD | Show documentation of audit (OT manual) (Added by WBK) |
3c. Technical requirements and recommendations NRO, IdP and SP (MOL)
| # | 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 | NRO self)15 | DIsable SPAP | Shiva Password Authentication Protocol MUST NOT be used, as their encryption is reversible (see reference 7) | MUST NOT | NROverifies that this has been communicated to eduroam IdPs/SPs (NRO self) | ||||||||||
| 2 | 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 & | 16 | 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) | 17 | Suppress Accounting | RADIUS accounting messages MUST NOT be forwarded to the eduroam international RADIUS Proxies. They may contain potentially sensitive information and therefore GDPR compliance duties. NB: conflicts with existing policy, which states it SHOULD be supported. | MUST NOT | Check accounting messages towards the TLRs (OT automatic) | 18 | Secure RadSec server identities | If RadSec is used, X.509 certificates must be used to identify RADIUS servers | MUST (optional) | Check FTLR server configuration (NRO self), check TLR configuration (OT automatic) |
| 19 | Set eduroam-SP-Country | Advise NROs to set eduroam-SP-Country attribute in particular for RadSec | SHOULD | NRO verifies that this is the case (NRO self) | (etlr also does it, but not for RadSec) | ||||||||||||||
| 3 | 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) | |||||||||||||||
| 4 | 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). | MUST | NRO checks that this is the case with the FTLRs & NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | Why do we care about not running 1645. (Or even random other ports, like the hosted SP may do.) | ||||||||||||||
| 5 | 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 | 20 | Deploy 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?) | NRO verifiesthat this is the case with the FTLRs & NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | 21 | Adopt network segmentation | Network segmentation SHOULD be considered, placing roaming users into a separate segment to local organisation users. | |||||||
| 6 | 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 | NRO checks that this is the case with the FTLRs & NRO | SHOULD | NROverifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||||||||||
| 7 | Make back-ups | All servers and configuration files MUST be regularly backed up (as a minimum after every configuration change) | MUST | NRO checks that this is the case with the FTLRs & | 22 | Deploy VLAN spoofing countermeasures | the visitor network design SHOULD prevent devices from mailiciously placing themselves into unauthorised VLANs | SHOULD | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | ||||||||||
| 8 | Conduct | external penetration testingmonitoring | 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 | NRO checks that this is the case with the FTLRs & NRO verifies that this has been communicated to eduroam IdPs/SPs | NROs SHOULD regularly conduct vulnerability assessment of internet-facing eduroam infrastructure. | SHOULD | To be carried out by the NRO in cooperation with the national CERT team(NRO self) | 24 | Conduct internal vulnerability testing | NROs SHOULD regularly conduct vulnerability testing from within the internal network of eduroam infrastructure. | SHOULD | |||||||
| 9 | 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 | NRO checks that this is the case with the FTLRs (show test results) & NRO verifies that this has been communicated to eduroam IdPs/SPs To be carried out by the NRO in cooperation with the national CERT team (NRO self) | 25 | Incorporate redundancy | NRO-level RADIUS servers SHOULD be deployed in a redundant, diverse configuration to maximise availability and meet SLAs | SHOULD | NRO verifies that this is the case (NRO self) | ||||||||||
| 10 | EAP requests always carry it | ||||||||||||||||||
| 11 | 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 & NRO verifies that this has been communicated to | 26 | Adopt encrypted comms | NRO SHOULD recommend to members that they use a VPN to protect communications between Access Points and the RADIUS server. (Usually there is a controller here?!? Is VPN really needed?) | SHOULD | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | ||||||||||
| 12 | Secure RadSec server identities | If RadSec is used, X.509 certificates must be used to identify RADIUS servers | MUST (optional) | Check FTLR server configuration (NRO self), check TLR configuration (OT automatic) | |||||||||||||||
| 1327 | audit eduroam IdPs/SPs | NROs SHOULD regularly audit eduroam IdPs/SPs on the criteria mentioned above | SHOULD | Show documentation of audit (OT manual) (Added by WBK) |
...