Troubleshooting issues and resolving security incidents.

Troubleshooting issues and resolving security incidents.

Recommendation by the eduroam Service Definition.

Troubleshooting issues and resolving security incidents.

Requirement by the eduroam Service Definition.

Troubleshooting issues and resolving security incidents.

Recommendation by the eduroam Service Definition.

Requirement by the eduroam Service Definition is to keep the logs of public IP addresses assigned to users and its relation to users MAC address.

Data is logged in the ETLR servers when a RADIUS authentication or response passes (user accesses eduroam in another country)

Data is logged in the FTLR server(s) when a RADIUS authentication or response passes (user accesses eduroam in another institution)

Data is stored in the ETLR servers, accessible only to the eduroam operational team personnel.

Data is stored in the FTLR server(s), accessible only to the NRO operational team personnel.

(This may vary based on local practices)

Data is stored in the IdP server(s), accessible only to the IdP operational team personnel.

(This may vary based on local practices)

Data is stored in the SP server(s), accessible only to the IdP operational team personnel.

(This may vary based on local practices)

No

Depends on the local policy.

eduroam Service Definition recommendation is: The minimum log retention time is six months, unless national regulations require otherwise

Depends on the local policy.

eduroam Service Definition recommendation is: The minimum log retention time is six months, unless national regulations require otherwise.

Depends on local the policy.

eduroam Service Definition recommendation is: The minimum log retention time is six months, unless national regulations require otherwise.

Outer EAP-identity - username@institution_domain, username can be anonymised but not all users do that

• ?

Data is collected from the institutions participating in the eduroam in that NRO. Exact process is a matter of local implementation in a NRO.

Data is stored in the SQL database on the virtual machine that is operated in the infrastructure provided by SURFNET. The raw data is accessible only by the personnel of eduroam operations team. The virtual machine is maintained by the OT.

System sends emails with invitation tokens (one variant to institution administrators for sign-up, one variant to NRO personnel for general status updates)

• The authorisation status of administrators who ever logged in is retained permanently.
• The installer-relevant information is kept until the administrator chooses to delete it (then deleted immediately).
• There is a cache for previously generated installers which gets invalidated upon deletion of the installer-relevant information (but remains on disk until manual cleanup is triggered).

administrator authentication - supplied from eduroam SP proxy

• eduPersonTargetedId or equivalent
• real name
• email address

administrator authorisation

• is user an NRO administrator, and for which country - supplied from eduroam SP proxy
• initial email address of new institution administrators during signup (supplied from NRO administrator)
• is user institution administrator, and for which institution - information gathered from NRO administrators and with email voucher verification process

general institution information - supplied by institution administrator input

• institution name, multi-language
• geographical coordinates of institution
• institution logo
• whether institution also exists in eduroam database (institution information), and the ID in that database

eduroam media deployment information - supplied by institution administrator input

• SSIDs and encryption levels
• whether or not eduroam is on wired ports
• onboarding SSIDs which should be removed upon installation
• Passpoint consortia identifiers

support contacts of institution - supplied by institution administrator input

• helpdesk email, multi-language
• information web page, multi-language
• Acceptable Use Policy, multi-language
• telephone contact

RADIUS/EAP details - supplied by institution administrator input

• name of deployment profile, multi-language
• description of deployment profile, multi-language
• production-readiness state of deployment profile
• domain name ("realm") for deployment profile
• anonymous outer ID to be used in installers
• supported EAP types
• CA certificates that identify EAP server
• names of EAP servers
• redirection URLs for external installer handling, multi-language
• custom text accompanying installer downloads, , multi-language
• EAP-TLS username handling directives (does not contain actual user names)

• this needs to be filled in by the sys admins of the servers - not yet decided where exactly the production servers will be,but in principle  same info as for CAT
  

• The authorisation status of administrators who ever logged in is retained permanently.
• Most of the installer-relevant information is kept until the administrator chooses to delete it (then deleted immediately), with the exception of ...
• ... end user authentication data, which is retained (indefinitely?) even after deletion of users to enable prosecution

Deployment details of Managed IdP for NRO (from NRO admin input)

• Whether it is enabled or not
• max number of users per institution profile
• EAP termination settings

Deployment details of Managed IdP for institution

• whether the admin has accepted the system's ToU
• (pseudonymous) usernames of the institution's users
• expiry date of said pseudonymous usernames
• list of eduroam credentials issued to these users (properties of these credentials in 8, below), linked to the respective username
• list of pending invitation tokens with which users can create new credentials and inquire about their account status (properties of invitation toekns in 9, below)
• status of the usernames (active, inactive)
• data freshness: when were the set of users last checked by the administrator for continued validity?

eduroam credentials (X.509 certificates)

• unique, randomly generated username as certificate Subject (original pseudonymous username is not contained, but system maintains an internal link between pseudonymous username and the Subject of the certificate)
• date of issue and expiry of certificate
• unique, randomly chosen serial number for certificate
• device type for which certificate was generated
• revocation status of certificate
• invitation token (see 9, below) which was used to generate certificate

end-user invitation tokens (URLs with unique, random long identifier)

• pseudonymous username to which invitation token pertains
• number of devices which can be credentialed witht his token
• expiry date of invitation token

RADIUS authentication logs

The RADIUS server is an eduroam IdP in the sense of the dataset "eduroam RADIUS server logs → IdP" above, and the same data set considerations apply.

certificate status server logs

• logs the timestamp when a revocation assertion was requested for a given eduroam credential - revocation assertions typically coincide exactly with the actual authentication happening on the RADIUS server. Does not log the actual revocation state that was returned.