eduroam NRO audit

-- draft --

1. Purpose

goal is to evaluate the service level, recognise excellence and identify possible weak spots all in order to maintain and improve the over quality of the service

2. Rules & Process

once a year - initial audit (2 months) + audit for those who failed (1 month)

requirements and recommendations = norms = MUST, SHOULD, MAY

audit marks:

NRO passes: all MUSTs obeyed
NRO is good: all MUSTs + all SHOULDs obeyed
NRO is excellent: all MUSTs + all SHOULDs + all MAYs

audit results:

rewards and sanctions

audit tools:

self assesment
automatic via monitoring tools
manual assessment by the OT / audit team

audit process:

initiated by the eduroam OT
NRO admins fill in the web form (monitor.eduroam.org/audit)
OT provides data via manual audit or monitoring tools
OT publishes final results (only final mark per NRO is publicly available

3a. Requirements and recommendations

Number	Name	Description	Status	Tools
1	policy (Ch 6)	NRO has signed the appropriate version of the policy	MUST	OT checks in official archive
	policy (before Ch 6)	NROs should appoint at least one representative to the eduroam SG	SHOULD	OT 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.	SHOULD	OT 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 incidents	SHOULD	OT 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 action	SHOULD	OT 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.	MUST	Check 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 practices	MUST	Check 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”	MUST	Check reported cased to identify the flow
	policy (Ch 6)	Participate in the work of the SG	MUST	Check if presence on mailing lists.
	policy (Ch 6)	Provide the information for the eduroam database	MUST	Check 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.	MUST	Check if website is present
	policy (Ch 6)	The national eduroam website should be available in English	SHOULD	Check 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.	MUST	Check 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.	MUST	Check 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.	MUST	Check 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/MUST	Check 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/MUST	Check server configuration

3b. Secondary Requirements and recommendations (MOL)

	Name	Description	Status	Tools
1	Physical signage	NRO advises member organisations to deploy physical signage in areas where eduroam is available (e.g. to assist visitors with medical prosthetics)	Should	Evidence: copy of documentation/web page
2	Published locations	NRO ensures all member venue location data is added to the eduroam database (for use in maps etc.)	Should
3	Web presence	Publishes a site at (tld)/eduroam documenting eduroam activities and locations in their NREN	Should	Evidence: URL/screenshots
4	Maps	Website (3) includes graphical maps of accessible locations, noting additional services such as charging points	May
5	Contact data	NRO has arranged 365 cover of all named contact points (mail and phone redirects for leave etc)	Should
6	CAT enabled	NRO maintains a CAT adminstrator/config for its own staff and recommends CAT usage to all members	Should
7	Training	NRO provides eduroam training to member organisations (either directly or through a third party)	Should
8	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
9	No 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)	MUST
10	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
11
12
13
14
15

3c. Technical requirements (MOL)

	Name	Description	Status
1	Firewall	A layer 4 firewall MUST separate the internet-facing RADIUS server and the internal network. Access must be controlled and monitored.	MUST
2	Firewall ICMP	Firewalls MUST permit ICMP to allow centralised monitoring of RADIUS servers	MUST
3	Admin access	System administration (RADIUS and associated systems) MUST be preformed over a private internal network ONLY.	MUST
4	DMZ connectivity	All protocols permitted access to the servers MUST be risk-assessed (e.g. SMB and RDP may present security risks)	MUST
5	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
6	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	Traffic interception	NROs 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
8	RadSec	If RadSec is used, X.509 certificates must be used to identify RADIUS servers	MUST (optional)
9	Network segmentation	Network segmentation SHOULD be considered, placing roaming users into a separate segment to local organisation users.	SHOULD
10	VLAN spoofing countermeasures	the visitor network design should prevent devices from mailiciously placing themselves into unauthorised VLANs	SHOULD
11	External penetration testing	NROs SHOULD regularly conduct vulnerability assessment of internet-facing eduroam infrastructure.	SHOULD
12	Internal vulnerability testing	NROs SHOULD regularly conduct vulnerability testing from within the internal network of eduroam infrastructure.	SHOULD
13	Non-eduroam guests	NRO 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
14
15