Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

NumberNameDescriptionStatusTools
1policy (Ch 6)NRO has signed the appropriate version of the policyMUSTOT checks in official archive

policy
(before Ch 6)
NROs should appoint at least one representative to the eduroam SGSHOULDOT 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. 

SHOULDOT 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 incidentsSHOULDOT 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 actionSHOULDOT 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.MUSTCheck 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 practicesMUSTCheck 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”MUSTCheck reported cased to identify the flow

policy (Ch 6)Participate in the work of the SGMUSTCheck if presence on mailing lists.

policy (Ch 6)Provide the information for the eduroam databaseMUSTCheck 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.MUSTCheck if website is present

policy (Ch 6)The national eduroam website should be available in EnglishSHOULDCheck 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.MUSTCheck 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.MUSTCheck 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.MUSTCheck 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/MUSTCheck 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/MUSTCheck server configuration

policy (Ch 6)AAA server: The server MUST generate F-Ticks and send them to the monitoring infrastructure.REQUIRED/MUSTCheck 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/MUSTCheck 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 serviceMUSTCheck 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)MUSTCheck server configuration

policy (Ch 6)The server(s) MUST respond to ICMP/ICMPv6 Echo Requests sent by the confederation infrastructure and confederation monitoring serviceMUSTCheck 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. MUSTCheck if website is present

policy (Ch 6)The address of the web server with information about the eduroam service SHOULD be www.eduroam.<tld>.SHOULDCheck if web site exists

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/databaseMUST (soon outdated xml → json) web page → https://monitor.eduroam.org/fact_eduroam_db.php (question)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.

SHOULDCheck 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.

3b. Secondary Requirements and recommendations (MOL)

federation MUST NOT be forwarded outside the federation, and MUST be acknowledged by the FLRS.MUSTCheck server configuration

3b. Secondary Requirements and recommendations (MOL)

#NameDescriptionStatusTools
1SSID

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
2802.11 onlyNROs MUST ensure members

3
#NameDescriptionStatusTools
1Audit trailNROs 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 eduroamMUST
24No sharingNROs 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
35Physical securityNROs 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
46Shared secretsRADIUS 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
57Physical signageNRO advises member organisations to deploy physical signage in areas where eduroam is available (e.g. to assist visitors with medical prosthetics)SHOULDEvidence: copy of documentation/web page
68Published locationsNRO ensures all member venue location data is added to the eduroam database (for use in maps etc.)SHOULD
79Web presenceNRO and members SHOULD publish a site at (tld)/eduroam documenting eduroam activities and locations in their NRENSHOULDEvidence: URL/screenshots
810Contact dataNRO has arranged 365 cover of all named contact points (mail and phone redirects for leave etc)SHOULD
911

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
1012TrainingNRO provides eduroam training to member organisations (either directly or through a third party)SHOULD
1113User educationNRO 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
1214ClarityNRO 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
1315Certificate typeNRO and members SHOULD undertake a risk-based selection of private vs. public CAs for their RADIUS infrastructure. Private is usually preferrable.SHOULD
1416EAP TypesNRO should advise members that they SHOULD use at least one of TLS, TTLS, EAP-FAST or PEAP (see reference 9)SHOULD
1517Anonymous Outer IdentitiesWhere supported by the EAP type and the supplicant, it is strongly recommended that anonymous outer identities SHOULD be used. (see reference 10)SHOULD
1618Enable CUIChargeable User Identity (CUI) SHOULD be implemented to enhance accountability of end user bahaviour by pseudonymous means.SHOULD
1719Cert revocationIf 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
1820Rogue detectionWhere possibleavailable, NRO and members SHOULD monitor for rogue access points. IF possible, automated suppression of rogues SHOULD be implemented.SHOULD
21Wireless IPSWhere available, NRO and members SHOULD implement Wi-Fi Intrusion Prevention Systems (IPS) to detect AP spoofing, malicious broadcasts etc.SHOULD
2219Manual configurationWhere 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
2023MapsWebsites MAY includes graphical maps of accessible locations, noting additional services such as charging pointsMAY

...

#NameDescriptionStatusTools
1FirewallA layer 4 firewall MUST separate all internet-facing RADIUS servers and the internal network. Access must be controlled and monitored.MUST
2Firewall ICMPFirewalls MUST permit ICMP to allow centralised monitoring of RADIUS serversMUST
3Admin accessSystem administration (RADIUS and associated systems) MUST be preformed over a private internal network ONLY.MUST
4DMZ connectivityAll protocols permitted access to the servers MUST be risk-assessed (e.g. SMB and RDP may present security risks)MUST
5External port accessA 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
6Internal port accessA 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
7Patch managementAll 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
8Consistent timeAll servers MUST be configured against the same time-synched NTP server to minimise issues with log reconciliation.MUST
9BackupsAll servers and configuration files MUST be regularly backed up (as a minimum after every configuration change)MUST
10MonitoringServers 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
11Authentication logsAll 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
12AlertsServers 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
13CA serversCA 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
14Enable Message-AuthenticatorWhere supported, the Message-Authenticator attribute MUST be enabled to prevent IP spoofed fake message injection. (see reference 8)MUST
15AES requirededuroam wi-fi services MUST implement WPA2 Enterprise with the use of the CCMP (AES) algorithmMUST
16Traffic interceptionNROs 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
17Disable PAPPassword Authentication Protocol MUST NOT be used between access points and RADIUS serversMUST NOT
18DIsable SPAPShiva Password Authentication Protocol MUST NOT be used, as their encryption is reversible (see reference 7)MUST NOT
19Disable MS-CHAPv1Challenge Handshake Authentication Protocol is considered weak and MUST NOT be used.MUST NOT
20Disable WPA-TKIPThe WPA specification MUST NOT be supported and the TKIP algorithm MUST NOT be employed in eduroam servicesMUST NOT
21AccountingRADIUS accounting messages MUST NOT be forwarded to the eduroam international RADIUS Proxies. They may contain potentially sensitive information.MUST NOT
22RadSecIf RadSec is used, X.509 certificates must be used to identify RADIUS serversMUST (optional)
23Dedicated serversNRO-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?)
24VLAN attributesDynamic VLAN attributes SHOULD NOT be sent in Access-Accept replies to the NRPS.SHOULD NOT (MUST NOT?)
25Network segmentationNetwork segmentation SHOULD be considered, placing roaming users into a separate segment to local organisation users.SHOULD
26VLAN spoofing countermeasuresthe visitor network design SHOULD prevent devices from mailiciously placing themselves into unauthorised VLANsSHOULD
27External penetration testingNROs SHOULD regularly conduct vulnerability assessment of internet-facing eduroam infrastructure.SHOULD
28Internal vulnerability testingNROs SHOULD regularly conduct vulnerability testing from within the internal network of eduroam infrastructure.SHOULD
29Non-eduroam guestsNRO and its members may offer a public guest Wi-Fi service for thsoe 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
30RedundancyNRO-level RADIUS servers SHOULD be deployed in a redundant, diverse configuration to maximise availability and meet SLAsSHOULD
31Hardened serversNRO-level RADIUS servers SHOULD be hardened to recognised best practice standards (includes secondary/backup RADIUS, certificate servers etc.)SHOULD
32Encrypted commsNRO SHOULD recommend to members that they use a VPN to protect communications between Access Points and the RADIUS server.SHOULD
33Set Operator-NameWhere 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

...