...
3c. Technical requirements and recommendations (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 | ||
| 2 | Allow ICMP | Firewalls MUST permit ICMP to allow centralised monitoring of RADIUS servers | MUST | ||
| 3 | Limit admin access | System administration (RADIUS and associated systems) MUST be preformed over a private internal network ONLY. | MUST | ||
| 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 | ||
| 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). | MUST | Why do we care about not running 1645. (Or even random other ports, like the hosted SP may do.) | |
| 6 | 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 | ||
| 7 | 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 | ||
| 8 | Ensure consistent timestamps | All servers MUST be configured against the same time-synched NTP server to minimise issues with log reconciliation. | MUST | ||
| 9 | Make back-ups | All servers and configuration files MUST be regularly backed up (as a minimum after every configuration change) | MUST | ||
| 10 | 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 | ||
| 11 | 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 | ||
| 12 | Enable 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 | 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 | ||
| 14 | Enable Message-Authenticator | MUST | EAP requests always carry it | ||
| 15 | Adopt AES | eduroam wi-fi services MUST implement WPA2 Enterprise with the use of the CCMP (AES) algorithm | MUST | ||
| 16 | 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 | ||
| 17 | Disable PAP | Password Authentication Protocol MUST NOT be used between access points and RADIUS servers | MUST NOT | ||
| 18 | DIsable SPAP | Shiva Password Authentication Protocol MUST NOT be used, as their encryption is reversible (see reference 7) | MUST NOT | ||
| 19 | Disable MS-CHAPv1 | Challenge Handshake Authentication Protocol is considered weak and MUST NOT be used. | MUST NOT | ||
| 20 | Disable WPA-TKIP | The WPA specification MUST NOT be supported and the TKIP algorithm MUST NOT be employed in eduroam services | MUST NOT | ||
| 21 | 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 | ||
| 22 | Secure RadSec server identities | If RadSec is used, X.509 certificates must be used to identify RADIUS servers | MUST (optional) | ||
| 23 | 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?) | ||
| 24 | Suppress VLAN attributes | Dynamic VLAN attributes SHOULD NOT be sent in Access-Accept replies to the NRPS. | SHOULD NOT (MUST NOT?) | ||
| 25 | Adopt network segmentation | Network segmentation SHOULD be considered, placing roaming users into a separate segment to local organisation users. | SHOULD | ||
| 26 | Deploy VLAN spoofing countermeasures | the visitor network design SHOULD prevent devices from mailiciously placing themselves into unauthorised VLANs | SHOULD | ||
| 27 | Conduct external penetration testing | NROs SHOULD regularly conduct vulnerability assessment of internet-facing eduroam infrastructure. | SHOULD | ||
| 28 | Conduct internal vulnerability testing | NROs SHOULD regularly conduct vulnerability testing from within the internal network of eduroam infrastructure. | SHOULD | ||
| 29 | 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 | ||
| 30 | Incorporate redundancy | NRO-level RADIUS servers SHOULD be deployed in a redundant, diverse configuration to maximise availability and meet SLAs | SHOULD | ||
| 31 | Deploy hardened servers | NRO-level RADIUS servers SHOULD be hardened to recognised best practice standards (includes secondary/backup RADIUS, certificate servers etc.) | SHOULD | ||
| 32 | Adopt encrypted comms | NRO SHOULD recommend to members that they use a VPN to protect communications between Access Points and the RADIUS server. | SHOULD | ||
| 33 | 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 |
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 |
| 7 | SPAP vulnerability | https://technet.microsoft.com/en-us/library/dd197599(v=ws.10).aspx |
| 8 | RADIUS EAP support (re. Message injection) | http://www.networksorcery.com/enp/rfc/rfc3579.txt |
| 9 | EAP Types | https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol |
...