Clarification of eduroam(UK) Policy and Tech Spec Wording - Visitor Activity Logging

Download as PDFDownload as PDF

Updated 24/04/2021

The eduroam(UK) Policy calls for the following from Visited Organisations:

  • Since complaints may be received by a Visited organisation about the network activity of a visitor, the Visited organisation must keep sufficient logs to be able to trace network activity to an authenticated user, and to keep these logs securely for a minimum of three months.
  • If activity logs are collected (e.g. through web proxy), the Visited organisation must make the relevant portions available to the Home organisation and/or the eduroam(UK) Service when these are required to investigate misuse.
  • Must accept and log complaints of misuse and forward these promptly to the appropriate Home organisation.

In other words, the actual requirement is that if there is a complaint about something that a visitor did then the Visited site needs to be able to work out which Home site authenticated the visitor and provide the Home organisation with enough information for them to be able to use their logs to identify the individual and hold them to account. The requirement is definitely NOT that Visited organisations should log everything their visitors do on their networks.  (This would be technically challenging in any case given that organisations usually deploy DHCP and/or Proxying/NAT).

Detailed and accurate logging (normally implemented on participants’ RADIUS servers) of authentication and accounting requests is necessary for resolving technical problems and the investigation of network abuse. Note that the eduroam(UK) policy states that Visited organisations are responsible for all activities of visitors, and consequently it is in their interests to ensure that this logging is accurate and complete.

Technical details of the logging requirements are described in the eduroam(UK) Technical Specification, the relevant clauses are reproduced below.

Logging requirements for all participating organisations, Visited (SP) and Home (IdP) - nb addl reqm apply to Home orgs, see follow on section:

(eduroam(UK) Tech Spec mandatory requirement number listed at left hand margin)

6        Every log entry MUST state the date and time it was logged, derived from a reliable time source. The timestamp MUST be in UTC.

7        Logs must be kept for at least three months.

15.        Participants’ ORPSs MUST log all RADIUS authentication requests exchanged with the NRPS; the following information must be recorded.

15.1.            The value of the user name attribute in the request.

15.2.            The value of the Calling-Station-Id attribute in the request.

Note that with version 1.4 of the Tech Spec, RADIUS accounting requests should not be forwarded to the NRPS so logging of accounting events is not mandated. However RADIUS accounting may be employed on the campus network and the member organisation may wish to record the following:

  • The value of the user name attribute in the request
  • The value of the accounting session identifier
  • The value of the request’s accounting status type

Additional logging requirements for Home (IdP) organisations (ie applicable to most eduroam(UK) participants):

In addition to the above requirements, the following apply to Home (IdP) participants.

19.        Home organisations MUST log all authentication attempts; the following information MUST be recorded.

19.1.            The time that the authentication request was received.

19.2.            The authentication result returned by the authentication database.

19.3.            The reason given, if any, if the authentication was denied or failed.

19.4.            User-Name in the outer-EAP and the User-Name from the inner-EAP (if a tunnelled EAP method is used).

19.5.            Chargeable-User-Identity (CUI) if one was generated.

19.6.            Calling-Station-ID.

19.7.            Operator-Name if one was present in Access-Request.

Most RADIUS server software systems generally have adequate capability to enable the above to be configured fairly easily.  For example, see Appendix 1: Logging in the case study below: