Institutional eduroam
Implementation Plan
Author: Neil Witheridge
Date: 21st April 2016
Version: 1.0
About This Document
This document describes the institutional eduroam implementation plan, addressing technical and
administrative requirements for participating in the national eduroam federation.
Contents
Introduction ........................................................................................................................ 3
Terminology ................................................................................................................................ 3
Institutional eduroam Service Type ........................................................................................................... 4
eduroam Prerequisites ................................................................................................................ 4
Information previously provided to the NRO ............................................................................................. 4
Implementation Plan Overview ......................................................................................... 5
Deployment Tasks ...................................................................................................................... 5
RADIUS Servers........................................................................................................................................ 6
Wireless Infrastructure .............................................................................................................................. 6
Network Access ......................................................................................................................................... 6
Institutional eduroam Support ................................................................................................................... 6
Institutional eduroam Webpage................................................................................................................. 6
Information Transfer to the NRO ................................................................................................. 7
Institutional eduroam Deployment Scenarios .............................................................................. 7
Typical Institution ....................................................................................................................................... 7
Institution acting as eduroam SP for Partners ........................................................................................... 8
Other Scenarios......................................................................................................................................... 8
NRO eduroam Operational Objectives ............................................................................. 9
National RADIUS Server Operation ............................................................................................ 9
Operability Monitoring ................................................................................................................. 9
Information Resources ................................................................................................................ 9
Support to Institutional Administrators......................................................................................... 9
Institution RADIUS Server(s) Deployment ..................................................................... 10
Implementation Items................................................................................................................ 10
Required .................................................................................................................................................. 10
Recommended ........................................................................................................................................ 13
Optional ................................................................................................................................................... 13
Discussion ................................................................................................................................ 13
Required RADIUS Attributes ................................................................................................................... 13
RADIUS Server Certificate ...................................................................................................................... 14
Filtering invalid usernames and realms ................................................................................................... 15
Non-responsive Server Handling ............................................................................................................ 16
RADIUS Server Logging ......................................................................................................................... 16
Information to be provided to the NRO ..................................................................................... 16
Wireless Infrastructure .................................................................................................... 18
Implementation Items................................................................................................................ 18
Required .................................................................................................................................................. 18
Recommended ........................................................................................................................................ 19
Information to be provided to the NRO ...................................................................................... 20
Network Access ............................................................................................................... 21
Implementation Items................................................................................................................ 21
Required .................................................................................................................................................. 21
Ver 1.0 21st April 2016
1 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Recommended ........................................................................................................................................ 21
Optional ................................................................................................................................................... 21
Discussion ................................................................................................................................ 21
Recommended Ports and Protocols........................................................................................................ 21
Information to be provided to the NRO ...................................................................................... 22
Institutional Support........................................................................................................ 23
Implementation Items................................................................................................................ 23
Mandatory................................................................................................................................................ 23
Recommended ........................................................................................................................................ 23
Discussion ................................................................................................................................ 23
Local eduroam Contacts ......................................................................................................................... 23
Local Support Workflow .......................................................................................................................... 24
Test accounts .......................................................................................................................................... 24
eduroam Configuration Assistant Tool .................................................................................................... 24
End-User Education ................................................................................................................................ 24
Information to be provided to the NRO ...................................................................................... 25
eduroam Webpage........................................................................................................... 26
Implementation Items................................................................................................................ 26
Mandatory................................................................................................................................................ 26
Required Information ................................................................................................................ 26
General Information ................................................................................................................................. 26
IdP-role-specific Information .................................................................................................................... 26
SP-role-specific Information .................................................................................................................... 26
Information to be provided to the NRO ...................................................................................... 27
Appendix A: Institutional eduroam Implementation Workflow .................................... 28
Ver 1.0 21st April 2016
2 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Introduction
The eduroam joining process for an institution consists of 4 steps:
1. Institution’s Application to the NRO to participate in eduroam, involving the exchange of institutional
and basic eduroam deployment planning information allowing the National Roaming Operator (the
NRO) to assess the institution’s satisfaction of pre-requisites and ability to operate sustainably as an
eduroam participant;
2. Deployment of eduroam, satisfying technical and administrative requirements;
3. eduroam Operability Auditing;
4. Commencement of participation, involving the NRO announcement of the institution’s participation in
eduroam to current eduroam national participants, and globally via upload of the institution’s
eduroam deployment data to the eduroam global database.
This document describes the implementation plan for Step 2.
Terminology
National Roaming Operator (the NRO): The entity that operates the eduroam service for a country or
economy. For example, the NRO may be a National Research and Education Network (NREN) operator. The
NROs are sometimes referred to as the “eduroam operators”.
The institution: The administrative organisation with overall responsibility for deployment of eduroam on
behalf of one or more institutions is referred to simply as ‘the institution’ in the following implementation
description.
eduroam username: institutional_username@institutional_realm
Following are components of eduroam infrastructure:

Supplicant i.e. software on an end-user’s mobile device responsible for establishing a wireless
connection. For eduroam, the supplicant implements the IEEE 802.1x protocol;

Network Access Server (NAS) i.e. a Wireless Access Point, Wireless LAN Controller. The NAS
implements the IEEE 802.1x protocol for communicating with the supplicant, and initiates an
authentication transaction with the supplicant. The NAS implements the RADIUS protocol for
communication with the Authentication Server. In performing authentication, both the IEEE 802.1x leg
and RADIUS leg use the EAP framework (Extensible Authentication Protocol). EAP is a framework
for conveying a variety of authentication methods.
For security and ease of implementation, eduroam uses tunneled EAP protocols. Basically this involves
a first step of TLS handshaking and establishing an encrypted tunnel (keys, keying materials) (and also
authenticating the home RADIUS server), and a second step of transferring encrypted user information in
RADIUS EAP attributes in order to perform secure user authentication. For eduroam, the predominant
authentication protocols (outer/inner) are PEAP/MSCHAPv2, TTLS/MSCHAPv2 and TTLS/PAP.

Authentication Server (AS) i.e. the institution’s RADIUS Server(s) configured in the NAS as the
destination of RADIUS authentication requests.

RADIUS is an ‘Authentication, Authorisation and Accounting’ (AAA) protocol. RADIUS implementations
support the use of a ‘realm’ part of the eduroam username (conveyed in the RADIUS User-Name
attribute) to determine whether to authenticate the user against a local identity store, or to forward (proxy)
the authentication request to the national eduroam RADIUS Server, which in turn will proxy the request to
the Regional or Top-Level eduroam RADIUS Server, or to the eduroam participating ‘home-institution’
RADIUS server responsible for authentication of user from the realm.

Infrastructure Servers are responsible for proxying the authentication request between institutional
RADIUS servers, and include both the National RADIUS Servers (NRS) and Regional or Top-Level
RADIUS servers (TLRS).
Ver 1.0 21st April 2016
3 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
eduroam participant roles:

Identity Provider (IdP): the institution authenticates its users according to its local realm; and

Service Provider (SP): the institution provides network access to visitors by virtue of their successful
remote authentication via eduroam by their ‘home institution’.
the NROs also operate an eduroam Test and Monitoring Server (TMS) which comprises both a RADIUS
client, issuing authentication requests using the ‘rad_eap_test’ client software, and a RADIUS Server which
authenticates the NRO-provided institutional SP test accounts.
Institutional eduroam Service Type
The eduroam service-type for institutions is usually IdP+SP, i.e. authenticating the institutions own users as
they travel to other eduroam participating institutions, as well as providing network access to visitors via
eduroam. Institutions may also operate as SP-only participants, and in special cases as IdP-only
participants.
eduroam Prerequisites
Step 1. of the eduroam joining process, the institutional application to participate in eduroam, involves
sharing basic institutional information and eduroam deployment and technical contact information. The
institution is evaluated in its satisfying the pre-requisites for eduroam participation, being:

Understanding of eduroam and willingness/ability to comply with technical and administrative policy
requirements for operating as an eduroam IdP+SP;

Effective identity management & secure identity store;

Effective wireless network infrastructure with support for IEEE 802.1x (WPA2 Enterprise);

Effective internal networking and internet access via NREN or other ISP, with the requirement for their
users (staff, students) to conform to the institution’s network access Acceptable Use Policy (AUP);

IT capability necessary to deploy and sustainably operate the eduroam RADIUS Server;

IT support capability necessary to provide IT support to local staff and visitors;

Administrative capability necessary to publish an institutional eduroam webpage providing eduroam
configuration and usage information for local users and visitors.
If the NRO deems the institution as satisfying the pre-requisites, Step 1. concludes with an invitation from the
NRO to the institution to proceed to deploy eduroam infrastructure and establish administrative processes
required for eduroam participation i.e. an invitation to proceed to Step 2.
Information previously provided to the NRO
The following information will have been provided to the NRO during step 1 of the joining process:
Information item
Description/Comment
Institution name
Formal name, including “The” if appropriate
Institution address
Street,City,State,Postcode
Primary domain name
Registered primary domain name, will be use as the institution
label in monitoring, metrics etc.
Institution webpage
URL of institution’s website home-page
Link to Institution’s network AUP
URL of institution’s network access Acceptable Use Policy
Ver 1.0 21st April 2016
4 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Information item
Description/Comment
Institution’s Identity Store info
Authentication system/identity store vendor, model/name, version
Intended local realms
Intended local realms, of form (sub) primary domain name
Local test account(s)
Confirm willingness to provide eduroam test accounts for each
local realm
Wireless Infrastructure info
Wireless equipment vendor, model/name, version. Confirm
support for multiple SSIDs, IEEE 802.1x capable.
Wireless coverage map (if any)
Link to institution’s wireless coverage map
Intended eduroam coverage
Names & addresses of campuses where eduroam coverage will
be provided
Potential eduroam overlap
Assessment of potential for eduroam coverage overlap with
another institution
RADIUS server info (if any)
Implementation vendor, model/name, version of existing RADIUS
server, or preferred implementation if any.
Configure trust for eduroam the NRO Confirmation of willingness to configure trust for the eduroam the
TMS
NRO Test&Monitoring servers in institutional RADIUS servers.
ISP information
Internet Service Provider and link to the institution’s Access
Agreement if available
Network service for local users
Description of network service, in particular IP addressing,
application proxies & content filtering if any, restrictions e.g.
ports/protocols, bandwidth, data quotas.
Intended eduroam network service
Intended network service for eduroam users, plan for eduroam
user traffic segregation e.g. via VLAN
Institution IT Support info
Number of IT support staff, link to IT support helpdesk, support
request ticketing system
Estimate of number of users
Estimate of number of users/identities across the institution
eduroam Technical Contact
Full name, email address, phone, mobile (for SMS comms) of the
primary technical contact who will be responsible for eduroam
deployment.
Implementation Plan Overview
The eduroam service relies on consistent implementation achieved in conformance with global and national
eduroam policy.
Deployment Tasks
An outline of each deployment task is provided below.
Ver 1.0 21st April 2016
5 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
RADIUS Servers

RADIUS server deployment satisfying requirements for the eduroam service, including
o
Choosing a RADIUS Server Platform
o
Deploying the RADIUS Server(s) & DNS name server configuration
o
Firewall configuration to allow access to RADIUS servers from the National RADIUS Server
o
Acquiring a server certificate for the RADIUS Server(s) to enable home RADIUS server
authentication
o
Based on local realms and how associated users credentials are stored, and which OS’s the
institution will support for eduroam access, determine which EAP authentication protocols are
applicable.
o
Receipt of user authentication requests from wireless network infrastructure and eduroam
infrastructure (national RADIUS server (NRS), also the eduroam test&monitoring server (TMS)), and
based on ‘realm’ part of username

authentication of local user against institutional identity store (IdP role)

proxying visitor authentication requests to eduroam infrastructure (national RADIUS server)
(SP role)

interoperating with the NRO test and monitoring server (operability monitoring)
o
Authentication transaction logging (ensuring the required attributes are logged)
o
Configuration for trust for the eduroam the NRO TMS in each of the institution’s eduroam RADIUS
servers for eduroam operability monitoring.
To assist with RADIUS Server deployment, the NRO will configure National RADIUS Servers (NRSs) to
enable testing during the deployment step. Configuration of NRS involves establishing trust for receipt of
authentication requests from and proxying of authentication requests to the institution RADIUS server(s). The
NRO will assist the institution by performing tests to confirm technical readiness.
Wireless Infrastructure

Planning and implementation of eduroam coverage area by configuration of wireless infrastructure to
broadcast the “eduroam” SSID and configuration of the ‘eduroam network’ for IEEE 802.1x authentication
at required locations (institution sites/campuses).
Network Access

Network service provision for eduroam users supporting the range of required protocols (the goal being to
provide an equivalent network access service to users as would be available if the user were on their
home campus)
o
Establishing a VLAN/network service for eduroam with appropriate IP addressing
o
Network access logging, associating access events with the user device’s MAC address and
assigned IP address (including DHCP logging, address translation if user network addressing is
NAT’ed).
Institutional eduroam Support

Establishment of an eduroam end-user support capability (including training of local support staff,
publication of an eduroam IT Support workflow) and promotion of the eduroam service to local users.
o
Provision of an institutional test account for each local realm;
o
Access to the eduroam Configuration Assistant Tool.
Institutional eduroam Webpage

Creation of a public eduroam informational webpage, providing comprehensive eduroam service
information to local users and visitors.
Ver 1.0 21st April 2016
6 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Information Transfer to the NRO
Each of the above tasks involves providing deployment information to the NRO in order that the NRO can
create an accurate record of the institution’s eduroam deployment in the eduroam the NRO “AdminTool”. The
AdminTool generates a data file, which is used to populate the global eduroam database and inform global
eduroam of the institution’s participation.
Following the above tasks and completion of information transfer to the NRO, the institution will perform selfmonitoring and internal testing to ensure readiness for eduroam operability auditing (step 3 of the eduroam
Joining Process).
Institutional eduroam Deployment Scenarios
Below are 2 examples of possible eduroam deployment scenarios for institutions.
Typical Institution
From an eduroam perspective, it is anticipated that typically the institution manages its own identities
(students and staff), operates its own network infrastructure (including wireless network and ISP agreement),
will deploy its own eduroam RADIUS server and provide support and web informational resources locally.
This scenario is depicted in Figure 1.
Figure 1.
Ver 1.0 21st April 2016
Typical Institutional eduroam Deployment Scenario
7 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Institution acting as eduroam SP for Partners
eduroam deployment topology may vary depending on complexity of agreements between institutions and
the NRO. Below is an example of a more complex eduroam deployment.
It may be appropriate that a large institution provides eduroam connectivity for partner institutions. Those
partner institutions may have their own identity management and network infrastructure (including wireless
and ISP agreement). However the large institution (‘Meta-Institution’) may provide eduroam connectivity
(including RADIUS servers and support elements such as IT support and informational webpage) to its
Partners. From an eduroam operational perspective, Partner Institutions are seen as realms of the MetaInstitution, and the Meta-Institution is responsible for Partner institution compliance with eduroam IdP policy.
This scenario is depicted in Figure 2.
Figure 2.
Public Institutional eduroam Deployment Scenario
Notes:
1. In the above diagram the ‘anchor controller’ operated by the Meta-Institution may not exist i.e. wireless
infrastructure at each Partner Institution may be stand-alone and be configured to authenticate against the
Meta-Institution RADIUS server.
2. It is assumed that each Partner Institution will have its own ‘realm’ (depicted as “partner1.edu.au”,
“partner2.edu.au”, “partner3.edu.au”) and the institution RADIUS Server operated by the Meta-Institution will
be configured to handle (i.e. authenticate users from) those realms.
3. It is assumed that the Meta-Institution provides a centralised IT Support function. However it is anticipated
that each Partner Institution will also have a local IT support person who may be called upon to assist in
troubleshooting either directly by end-users or by the Meta-Institution IT support function.
Other Scenarios
There will be scenarios that merge or depart from the above scenarios, however it is envisaged the
description below can be readily adapted to other scenarios in consultation with the NRO.
Ver 1.0 21st April 2016
8 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
NRO eduroam Operational Objectives
The implementation steps described in following sections reflect the NRO’s operational objectives in
delivering the eduroam service to institutions.
National RADIUS Server Operation
As the eduroam National Roaming Operator, the NRO’s primary responsibility is to operate the National
RADIUS Server (NRS), which routes eduroam authentication requests from the visited institution to the
user’s home institution.
This involves establishing a trust relationship (by virtue of a RADIUS ‘secret’) between the NRS institution
RADIUS servers, and configuring the routing of authentication requests to institutional RADIUS servers (and
establishing the appropriate order if fail-over is used for high-availability deployment).
Operability Monitoring
The NRO’s operability monitoring objectives are intended to provide information to institutional administrators
on the status of their own and other institution’s RADIUS servers. Each RADIUS server deployed by an
institution will be monitored according to its role (i.e. IdP or SP role). Monitoring will make use of trust
configured in each Institutional RADIUS Server (IRS) for the NRO hosted eduroam ‘Test & Monitoring
Server’ (TMS), and make use of test/monitoring accounts provided by institutions and maintained by the
eduroam TMS.
Information Resources
In order to minimize support costs for eduroam, the NRO’s goal is to ensure that comprehensive information
is provided to both institutional eduroam administrators and end-users.
Based on information provided by institutions, the NRO (see Note 1) will publish information which will allow
other eduroam participating institutions to understand the eduroam deployment at an institution as may be
required for supporting its own users travelling to other institutions.
The NRO ensures that institutions provide required information to populate the national eduroam
deployment database, and also provide information to the global eduroam database (hosted by eduroam’s
European confederation).
The NRO will also provide usage metrics to institutions to inform institutional stakeholders of the value the
institution is deriving from eduroam participation.
Support to Institutional Administrators
The NRO is responsible for providing support to institutional administrators. Hence it is important that the
NRO has accurate information on the eduroam deployment at institutions.
Institutional eduroam Administrators are responsible for providing support to their local IT Support Helpdesk
(responsible for 1st line eduroam support to end-users). This involves providing configuration information to
local end-users. The NRO will enable institutions to make use of the eduroam “Configuration Assistant Tool”
in order to enable scripted configuration of devices.
Note 1: Institutional Deployment Information Self-Maintenance (Future)
In the future, the NRO will provide an interface to the “eduroam AdminTool” which will enable institutional
eduroam administrators to maintain accurate deployment information via the tool.
The NRO is in the process of making this tool available, and prior to production deployment of the tool, will
populate data on behalf of institutions.
Ver 1.0 21st April 2016
9 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Institution RADIUS Server(s) Deployment
The global eduroam service relies on remote authentication of visiting users, authentication requests routed
via institutional, national and regional RADIUS servers to the user’s home institution.
An institution participating in eduroam needs to deploy and operate a RADIUS server which authenticates
local users and forwards (proxies) authentication requests of visiting users to the National RADIUS Server
(thence to their ‘home’ institution RADIUS server, potentially via regional and national RADIUS servers, for
remote authentication).
Implementation Items
Institutions typically operate as both an eduroam IdP and SP i.e. their RADIUS servers will perform both IdP
and SP roles. However in the general case of eduroam implementation, individual RADIUS servers may be
configured to perform an IdP-only role, or SP-only role, or both. This is reflected in the implementation plan
description below.
Required
For each RADIUS server deployed, the following items are required:
Item
Description
General
Choose appropriate RADIUS Deploy an implementation of RADIUS which is compliant with RFC2865.
implementation and install on Primary candidates are FreeRADIUS, Radiator, Cisco ISE, Microsoft NPS. A
server
comparison of RADIUS Server implementations for eduroam is available at
https://community.jisc.ac.uk/groups/dot1x-sig/document/radius-server-choice-guide-eduroam
RADIUS Server network
configuration
Servers with public IP addresses, listening on standard RADIUS protocol
ports (auth 1812, acct 1813). Domain name registration is optional.
Institutional Firewall
Configuration
Institutional RADIUS Server must be accessible from NRS and TMS (on
auth/acct ports), and must be able to issue authentication requests to the
NRS. Also enable ICMP Echo Requests sent by the NRS & TMS.
Server time synchronisation
For logging & traceability purposes, server clocks must be accurately
synchronised e.g. using NTP.
Authentication Request
Logging
Log RADIUS authentication requests, ensuring attributes are logged
providing traceability from network access to user authentication. Ensure log
retention is managed securely, e.g. using Syslog.
SP
Trusted client config of
Configure as trusted clients the institutional wireless infrastructure (Access
wireless AP/WLC & eduroam Points/ Wireless LAN controller) using 802.1x, and the NRO operated NRS
infrastructure (NRS,TMS)
and TMS
Filtering (local rejection) of
malformed usernames and
invalid realms
Ver 1.0 21st April 2016
Reject authentication requests with malformed username or invalid realms.
10 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Proxy authentication
Proxy authentication requests for non-local realms to the NRS.
requests for non-local realms
to the NRS
RADIUS attributes in proxied Include the minimal set of required attributes in proxied authentication
request only required set
requests (filter out other attributes sent from wireless infrastructure).
Release of Operator-Name
Release the Operator-Name attribute in proxied authentication requests.
Operator-Name should be of the correct format according to RFC5580
Request Chargeable-UserIdentity in proxied requests
Request Chargeable-User-Identity in proxied authentication requests (i.e.
visitor authentication requests proxied to the NRS) according to RFC4372
Release Framed-MTU
attribute with correct value
If Framed-MTU is not set correctly as per RFC2865, over-sized UDP packets
may be sent resulting in silent discarding of UDP packets. RADIUS server
implementations used for eduroam should respect Framed-MTU settings
(i.e. fragment EAP packets as required to avoid oversized UDP packets).
Release Calling-Station-ID
For the purpose of user traceability, it is necessary that the user device’s
populated with user-device’s MAC address is populated and delivered via the proxied authentication
MAC address
request in Calling-Station-ID.
IdP
Server and CA Certificates
Procure a server certificate for purpose of home RADIUS server
authentication & establishing a TLS session (encrypted tunnel) with the user
device (supplicant). Make the CA and intermediate certificates available if
not pre-trusted. The same certificate should be used for all RADIUS servers
acting as IdPs by the institution.
Choice of Local Realms
Local realms chosen depending on target user groups, identity stores in use,
and RADIUS server capabilities to chain authentication attempts to multiple
identity stores.
Choice of tunnelled EAP
Authentication Methods
Choice is dependent on password storage in identity store, and required
support of client devices. Choose either PEAP/MSCHAPv2 +
TTLS/MSCHAPv2 (password available in clear, hence able to be used to
generate response to challenge) or TTLS/PAP (not available in clear, sent in
clear for matching with stored credential). See:
https://wiki.geant.org/display/H2eduroam/How+to+deploy+eduroam+onsite+or+on+campus#Howtodeployeduroamon-siteoroncampus-IdentityManagementSystem
Authentication of local-realm Authenticate users for local realms against the appropriate identity store.
users
Local-domain authentication requests may be received from the institutional
wireless infrastructure, the NRSs or TMS.
Authenticate local users
connecting locally
Authenticate the institutions users accessing the institutions local network
while on campus. (Network access must be sufficient to enable confirmation
of correct authentication configuration, i.e. local users authenticating locally
should not be rejected.)
Release of ChargeableUser-Identity if requested
Release Chargeable-User-Identity (according to RFC, release CUI if
requested in proxied authentication request from NRS) according to
RFC4372
Local Test account
Provide local test accounts for each local realm either provisioned in the
RADIUS server (e.g. users file) or in the institutional identity store, and
usable with enabled authentication protocols.
Ver 1.0 21st April 2016
11 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Ver 1.0 21st April 2016
12 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Recommended
Item
Description
General
High availability deployment
It is recommended that institutions deploy two RADIUS servers, either using
fail-over or load-balancing, in order to provide high-availability. In the case of
load-balanced deployments, each RADIUS server should also be publicly
addressable for monitoring via the NRO’s TMS.
IdP
Disallow anonymous outer
identity
It is recommended that use of anonymous outer identity be disallowed for
local users. This is particularly important if Chargeable-User-Identity is not
released. Otherwise per-unique-user metrics are not achievable.
SP
Terminate Local Accounting
Request (do not proxy
accounting packets)
Accounting requests should not be proxied i.e. accounting requests arising
locally associated with visitor authentications should be terminated locally
i.e. not proxied to the NRS.
Optional
Item
Description
General
RADIUS Server domain
name registration
Registered domain names are not required as RADIUS configuration
referring to the server is by IP address.
Trusted Client config of local
test and monitoring server
Provision of local monitoring is an institutional decision. If provided,
configure trust for any local Test & Monitoring Server (i.e. any server to be
used for issuing authentication requests locally, e.g. using rad_eap_test, for
purposes of troubleshooting.
Discussion
Required RADIUS Attributes
The following are the RADIUS attributes that are required to be included in authentication requests
forwarded to the NRS for non-local users:

User-Name

Calling-Station-ID

Chargeable-User-Identifier

Operator-Name

Framed-MTU

NAS-IP-Address

NAS-Identifier

EAP Message

Message-Authenticator
Ver 1.0 21st April 2016
13 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
RADIUS Server Certificate
When an Identity Provider deploys multiple RADIUS servers for HA, then all these servers should use the
same server certificate.
It is recommended to use a server name which is a fully-qualified domain name (however the domain name
needn’t be registered in DNS). The server name should then be both in certificate's Subject field (Common
Name) and subjectAltName:DNS.
The following additional certificate properties are non-standard and are of use in the eduroam context:
Property
Content
server name
parses as fully-qualified Server certificates with spaces, e.g. "RADIUS Service of Foo
domain name
University" are known to be problematic with some supplicants.
server name
Subject/CN ==
SubjectAltName:DNS
Some supplicants only consult the CN when checking the
name of an incoming server certificate; some check either of
the two; some will only check SubjectAltName:DNS. Keeping
the desired name in both fields in sync is a safe bet for
futureproofing.
Only use one CN. If you have multiple RADIUS servers, either
use the same certificate for all of them (there is no need for the
name to match the DNS name of the machine it is running on),
or generate multiple certificates, each with the same
CN/subjectAltName:DNS values.
server name
not a wildcard name
(e.g. "*.someidp.tld")
Some supplicants exhibit undefined/buggy behaviour when
attempting to parse incoming certificates with a wildcard.
signature
algorithm
Minimum: SHA-1
Recommended: SHA256 or higher
Server certificates signed with the signature algorithm MD5 are
considered invalid by many modern operating systems.
The continued use of SHA-1 as a signature algorithm is not
recommended, because several operating systems and
browser vendors already have a deprecation policy for SHA-1
support. While the deprecation in browser-based scenarios
does not have an immediate impact on EAP server usage, it is
possible that system libraries and operating system APIs will
over time penalise the use of SHA-1. Therefore, for new
certificates, SHA-256 is recommended to avoid problems with
the certificate in the future.
length of public
key
Minimum: 1024 Bit
Recommended: 2048
Bit or higher
Server certificates with a length of the public key below 1024
bit are considered invalid by some recent operating systems.
The continued use of 1024 bit length keys is not
recommended, because several operating systems and
browser vendors already have a deprecation policy for this key
length. While the deprecation in browser-based scenarios does
not have an immediate impact on EAP server usage, it is
possible that system libraries and operating system APIs will
over time penalise the use of short key lengths. For new
certificates, 2048 bit or more is recommended .
Extension:
Extended Key
Usage
TLS Web Server
Authentication
Even though the certificate is used for EAP purposes, some
popular operating systems require the certificate extension
"TLS Web Server Authentication" (OID: 1.3.6.1.5.5.7.3.1) to be
present.
Ver 1.0 21st April 2016
Remarks
14 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Property
Content
Remarks
Extension: CRL
HTTP/HTTPS URI
Distribution Point pointing to a valid CRL
Few very recent operating systems require this extension to be
present; otherwise, the certificate is considered invalid.
These operating systems appear to only require the extension
to be present; they don't actually seem to download the CRL
from that URL and check the certificate against it. However the
URL should be a valid otherwise this would make the
certificate invalid for all operating systems which do evaluate
the extension if present.
Extension:
BasicConstraint
(critical)
Server certificates need to be marked as not being a CA.
Omitting the BasicConstraint:CA totally is known to cause
certificate validation to fail with some OSs; setting it to TRUE is
a security issue in itself. Always set the BasicConstraint "CA"
to false, and mark the extension as critical.
CA:FALSE
Filtering invalid usernames and realms
Institutional RADIUS servers are recommended to filter out bad or bogus authentication requests containing
malformed or 'homeless' usernames (i.e. known invalid realms) in order to reduce unnecessary loading of
the national proxy servers.
In order to help maximise the proxy efficiency of the National RADIUS Servers (NRSs) all institutions
providing Visited services should filter malformed outgoing RADIUS authentication requests on their
Institutional RADIUS Servers (IRSs) and not pass bad requests to the NRSs. This minimises the
unsuccessful authentication attempts (ones which will never succeed) and means that genuine
authentication requests are dealt with as quickly as possible.
SPs should forward RADIUS requests originating from eduroam NASs which contain user names with nonlocal realms to a NRS. However, SPs should not forward requests containing user names which do not
include a realm nor any which are non-NAI compliant.
The first part of that statement is simple, user names MUST contain an "@" symbol (e.g.
[email protected]) and so bare usernames (e.g. "username" in this case) should be rejected locally.
The definition of "NAI compliant" for the realm part is quite complex but basically it boils down meaning that it
must be syntactically valid, i.e. the realm part of the user name must meet all of the following requirements:

must contain at least one dot ("."), e.g. "school.edu.au" is OK;

must not start or end with a dot, e.g. ".school.edu.au " or "school.edu.au." are both invalid;

must not have two or more sequential dots, e.g. " school.edu..au " is invalid,

must consist only of alphanumeric, hyphen and dot characters, so that's a-z, 0-9, "-" and ".", spaces are
explicitly not permitted, e.g. "school.edu au" is invalid,

following on from the previous point the realm must not start or end with a space, e.g. " school.edu.au" is
invalid.
SPs should not forward requests with user names matching any of the following,

ends with “@edu.au”

ends with “.local”

ends with the institution's own realm without the .edu.au (this applies only to institutions which are
IdP+SP participants)

also, those realms which are permutations of common typo errors in the institution's realm name (e.g.
these may be found through experience in the RADIUS server log as incorrect logins)
There is also a list of common realms which we ask Visited organisations to reject locally rather than forward
as, whilst they are syntactically valid, they are not eduroam members at this time and are not expected to be
in the future. This list currently comprises:
Ver 1.0 21st April 2016
15 of 28
Neil Witheridge
Institutional eduroam Implementation Plan

myabc.com

3gppnetwork.org (plus all sub-realms thereof)

3gppnetworks.org (plus all sub-realms thereof)

gmail.com

googlemail.com

hotmail.com

hotmail.com.*

hotmail.co.*

live.com

outlook.com

yahoo.com
Standard filters for FreeRADIUS for filtering these should be made available from the NRO.
Non-responsive Server Handling
Due to the requirement to proxy authentication requests, through potentially a chain of RADIUS servers,
handling of non-responsiveness to authentication requests is an issue that must be addressed carefully.
Non-responsive Server Handling may be handled passively using RADIUS server configured timeouts, or
handled actively using the Status-Server capability if supported by the RADIUS implementation.
If the institution’s RADIUS server implementation is Status-Server capable, its use is strongly recommended.
RADIUS Server Logging
The following information & attributes must be logged:
Timestamp (UTC), Packet-Type (E.g. Access-Accept, Access-Reject), Reply-Message, User-Name,
Chargeable-User-Identity, Operator-Name, Calling-Station-ID, NAS-IP-Address, NAS-Identifier.
A compliant linelog configuration for FreeRADIUS should be made available from the NRO.
Logs must be retained for the minimum time specified in the eduroam policy (3 months).
Information to be provided to the NRO
The following information must be provided to the NRO for each RADIUS Server deployed.
This information allows the NRO to implement its operational objectives related to NRS configuration &
RADIUS server monitoring.
Ver 1.0 21st April 2016
16 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Information item
Description/Comment
RADIUS implementation
Vendor,name,version of RADIUS server implementation
RADIUS Server IP Address
IPv4 IP address, and IPv6 if IPv6 is supported
Registered domain-name
Registered domain name of RADIUS server
RADIUS Protocol Ports
RADIUS ports for authentication and accounting
RADIUS Secret
RADIUS secret, the same being used for both eduroam National
RADIUS Servers and the Test&Monitoring Server.
RADIUS Server, CA and
intermediate certificate
RADIUS server, CA and intermediate certificates for TLS session
establishment and home server authentication.
Confirm time synchronisation
Boolean indicating whether time synchronisation configured
Confirm log timestamps UTC
Boolean indicating whether log timestamps are UTC
RADIUS protocols supported
Confirmation of support for RADIUS authentication and
accounting protocols over UDP
Confirm accounting requests
terminated locally
Boolean indicating accounting requests are terminated locally
Logging of required information and
log retention
Boolean indicating logging is being performed as per policy
requirements
High availability mechanism
Flag indicating type of HA (none, fail-over or load-balancing)
Local realms and associated identity List of local realms supported by the RADIUS server and their
stores
associated identity stores
Authentication protocols
Outer and Inner authentication methods: combinations of
PEAP/MSCHAPv2, TTLS/MSCHAPv2,TTLS/PAP
Local test account (name, pwd, auth
protocols, RADIUS server or identity
store)
Local test accounts appropriate to be used for monitoring the
RADIUS server.
Release of Chargeable-User-Identity Confirmation of release of CUI for remote authentication via
proxied authentication request.
Anonymous outer-identify allowed
Boolean indicating whether anonymous outer identity is allowed.
Local user authentication performed
Confirmation of local user authentication and network access at
least to extent of confirming correct authentication configuration.
Non-local realms proxying server
priority
Order in which server should be listed in configuration for fail-over
for proxying authentication requests from NRS.
Status-Server enabled
Boolean indicating whether Status-Server capability is enabled.
Framed-MTU value
Value of Framed-MTU attribute
Release of MAC in Calling-Station-ID Confirmation of population of MAC in Calling-Station-ID,
formatted according to agreed standard.
Ver 1.0 21st April 2016
17 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Request for Chargeable-UserIdentity
Confirmation of request for CUI in proxied authentication
requests.
Release of Operator-Name
Confirmation of release of Operator-Name
Malformed username rejection
Confirmation of malformed username filtering
Invalid realm local rejection
Confirmation of invalid realm filtering
TMS Test account and password
Confirmation of receipt of the NRO TMS test account and
password
Load-balancer IP address
Confirmation of whether load-balanced deployment is used.
NRS non-response handling via
Status-Server
Confirmation of non-responsive NRS handling via Status-Server.
Wireless Infrastructure
Wireless infrastructure implementation applies to institutions operating as eduroam SPs.
The basic requirement is for institutional wireless infrastructure to support WPA2-Enterprise.
Wireless infrastructure may differ on a per-campus basis, hence if coverage involves multiple campuses,
providing campus-specific configuration information is required.
Implementation Items
Required
Item
Description
SSID “eduroam”
Broadcast the SSID “eduroam”. The eduroam service relies on all
participants broadcasting the same SSID “eduroam” and users configuring
their devices for auto-connection to the “eduroam” wireless network.
Encryption/Authentication:
AES, IEEE 802.1x
WPA2 Enterprise refers to a wireless encryption / authentication technology
set, where encryption is based on AES CCMP and authentication is
performed via the IEEE 802.1x protocol.
Coverage Plan & Campuses
Plan eduroam coverage, which campuses will eduroam be provided on.
Conceivably, each campus may have different wireless infrastructure and
network connectivity characteristics. Some campuses may even have
specific realms to be handled, and use specific authentication servers.
These per-campus differences must be identified and advised to the NRO,
as global eduroam tracks eduroam deployment and reflects it in the global
database down to specific campuses.
Configure local RADIUS as
Authentication Servers
Configuration of wireless infrastructure for IEEE 802.1x involves specifying
with Authentication Servers to use. The ASs are the institution’s local
RADIUS servers.
eduroam coverage overlap
If there is an overlapping eduroam coverage area (i.e. SSID “eduroam”
already visible from another institution) then it may be necessary to use a
different SSID e.g. eduroam-domain.name
Incidental authentications
Anticipate whether there will be incidental authentications which will use IP
addresses e.g. as users commute through the institution’s hotspot.
Ver 1.0 21st April 2016
18 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Recommended
Item
Description
Coverage Map
Coverage map, leveraging existing wireless networking coverage map.
Wireless equipment
Vendor, Make/Model, Version (informational purposes only for the NRO)
Ver 1.0 21st April 2016
19 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Information to be provided to the NRO
The following information will have been provided to the NRO during step 1 of the joining process:
Information item
Description/Comment
SSID
Confirm “eduroam” or eduroam-domain.name if overlapping
coverage.
Wireless Encryption/Authentication
Confirm WPA2-AES (i.e. IEEE 802.1x authentication) only
configured for eduroam
Map of eduroam coverage
Link to institution’s eduroam coverage map (likely same as
wireless coverage map)
Observed eduroam overlap
Confirm whether there is eduroam coverage overlap with another
institution
Anticipated ‘incidental’ authentication If the institution’s eduroam coverage includes a regular commute
path for students, then they will likely connect ‘incidentally’ as
they commute through the institution’s eduroam coverage area.
Per-Campus Information:
(for the case of public institutions, where the administering organisation provides identity
management, wireless infrastructure, eduroam infrastructure for a number of institutions, the
term ‘campus’ may be interpreted as individual institution).
Campus name
formal name, including ‘The’ if appropriate
Campus address
Street, City, State, Postcode
Campus location
Latitude and Longitude
Campus contact
Full name, email address, phone, mobile (for SMS notification).
Per-Campus SSID
If not specified, ‘institutional’ SSID is assumed
Per-Campus Wireless Encryption
If not specified, ‘institutional’ wireless encryption is assumed
Ver 1.0 21st April 2016
20 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Network Access
Configuration of network access for eduroam users applies to institutions operating as eduroam SPs.
The general ‘spirit’ of eduroam participation is to allow as functional (in terms of ports/protocols open,
bandwidth, data volume) network access as possible. Ideally users should receive the same or greater
network access than they would if on their own campus.
Network access may differ on a per-campus basis, hence if coverage involves multiple campuses, providing
campus-specific network access configuration information is required.
Implementation Items
Required
Item
Description
Protocols/Ports
Configure firewalls to allow required traffic according to the recommended
ports and protocols for eduroam users.
IP Addressing
Determine IP address range. Determine whether IPv6 addressing will be
assigned in addition to IPv4
DHCP
Configure DHCP to automatically configure networking of connecting
devices.
Logging
Ensure logging of network infrastructure is available, with timestamps and
data to ensure MAC address can be mapped to an IP address for network
access events, and with log retention equivalent to that for RADIUS logs.
Recommended
Item
Description
VLAN configuration
Configure VLAN to segregate visitor traffic from local user, or eduroam from
other corporate network.
Optional
Item
Description
Application Proxies (e.g.
content filtering)
Identify whether an application proxies are required for eduroam network.
NAT
Identity whether NAT’ing will be applied.
Rate restrictions
Identify whether any data rate throttling needs to be applied, based on local
policy.
Volume restrictions
Identify whether any quota needs to be applied, based on local policy.
Discussion
Recommended Ports and Protocols
The standard set of protocols and ports that are recommended to be provided to eduroam users are:
(List taken from https://www.eduroam.org/downloads/docs/GN3-12-192_eduroam-policy-servicedefinition_ver28_26072012.pdf )
Ver 1.0 21st April 2016
21 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Service
Protocol/Port
Direction
Standard IPsec VPN
IP protocol 50 (ESP)
incoming & outgoing
IP protocol 51 (AH)
incoming & outgoing
UDP/500 (IKE)
outgoing
OpenVPN 2.0
UDP/1194
incoming & outgoing
IPv6 Tunnel Broker Service
IP protocol 41
incoming & outgoing
IPSec NAT Traversal
UDP/4500
incoming & outgoing
Cisco IPSec VPN over TCP
TCP/10000
outgoing
PPTP VPN
IP protocol 47 (GRE)
TCP/1723 (PPTP)
incoming & outgoing
outgoing
SSH
TCP/22 (SSH)
outgoing
HTTP
TCP/80 (HTTP)
outgoing
TCP/443 (HTTPS)
outgoing
TCP/3128 (Squid proxy)
outgoing
TCP/8080 (HTTP proxy)
outgoing
TCP/465 (SMTPS)
outgoing
TCP/587 (SMTP message submission)
outgoing
TCP/143 (IMAP4)
outgoing
TCP/993 (IMAPS)
outgoing
TCP/110 (POP)
outgoing
TCP/995 (POP3S)
outgoing
TCP/21 (FTP)
outgoing
Mail Sending
Mail Receipt
FTP (passive)
Institutions may open additional protocols and ports as permitted by local policies.
Information to be provided to the NRO
The following information must be provided to the NRO per campus.
Note that one set of institution-wide data may be provided, and if individual campuses deviate from
institutional provision, the differences need to be described for those specific campuses.
Information item
Description/Comment
Protocols
Confirm that recommended protocols are enabled
IP Address Range
IP Address Range for eduroam users
DHCP
Confirm DHCP configuration of devices for network access
NAT
Boolean indicating whether NAT’ing is used
IPv6
Confirm whether IPv6 is enabled
eduroam VLANs
Confirm whether eduroam visitor network traffic is segregated
using VLAN
Bandwidth restriction
Describe any bandwidth restriction for eduroam users (throttling)
Volume restriction
Describe any volume restriction for eduroam users (quota)
Application Proxy
Describe whether application proxies are required to be
configured e.g. content filtering HTTP proxy.
Ver 1.0 21st April 2016
22 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Institutional Support
The institution is required to provide support to both local users, either on-campus or while travelling to other
eduroam participating institution, and to visitors from other eduroam participating institutions. eduroam
support is provided at 3 levels:
1. Local IT Support (Level 1 support, support requests tracked via the institution’s IT helpdesk)
2. Local eduroam technical administration (Level 2 support, support requests referred by the IT
helpdesk to the institution’s designated eduroam technical administrator(s).
3. eduroam the NRO (Level 3 support, support requests referred by the institutions designated
technical administrator to an the NRO eduroam email address)
Implementation Items
Mandatory
Item
Description
Institutional Contacts
Provide a list of institutional contacts and their type (technical, security,
management, campus)
Subscription to eduroam
administrative mail-lists
Ensure that technical contacts are subscribed to the local eduroam
administrator mail list.
Institutional Test Accounts
Provide institutional test accounts corresponding to each local realm
handled by the institution.
Institutional support training
Provide local institutional IT support with basic training on eduroam (training
on eduroam support workflow materials from the NRO) and the required support workflow.
Recommended
Item
Description
Configuration Assistant Tool
Collaborate with the NRO to enable access for the institutional users to the
eduroam Configuration Assistant Tool.
End-User Security Training
Provide training to institutional end-users on security aspects of eduroam. In
particular the need to authenticate the home RADIUS Server. Also general
advice regarding protecting passwords, not sharing accounts etc.
Discussion
Local eduroam Contacts
Information required for institutional contacts is: Full name, email address, phone number, mobile phone
number (for SMS communication).
Contact types are:

Technical

Security

Management
The mandatory contacts are 2 technical contacts. These are regarded as the primary and secondary
eduroam administrators for the institution.
Ver 1.0 21st April 2016
23 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Participants must designate 2 technical contacts that can be contacted using e-mail and telephone during
normal business hours. The primary contact must be a named individual. The secondary contact may be an
organisational unit e.g. HelpDesk. Arrangements must be made to cover for absence of the named technical
contact owing to eventualities such as illness and holidays.
Institutional technical contacts should be enrolled in the appropriate mail-list.
Local Support Workflow
The support workflow is described in Appendix A.
In the event of a requirement to escalate a service request to the NRO, the request should be sent to the
NRO support email address.
Local support training should be undertaken. Resources are available for support training from the NRO.
Access to support should be made readily apparent to eduroam users. The means of obtaining support
should be described clearly on the eduroam webpage.
Test accounts
Provide a test account for the NRO’s use in monitoring the institution’s operability as an identity provider as
described in the application to join.
The account name should include the string "test" (e.g. eduroam-test, the string "test" being used as a filter
to remove monitoring authentication requests from usage metrics).
SMS the password to eduroam NRO.
the NRO will configure the institution visitor test account on the NRO’s test and monitoring RADIUS server
for your own testing,
e.g. [email protected]
and will advise you of the password via SMS (please provide your mobile number).
eduroam Configuration Assistant Tool
With the proliferation of mobile devices, and the trend for BYOD on campuses, configuration of devices for
connection to eduroam and authentication using institutional credentials may be a challenge for users.
In the past, there has been a requirement for institutions to describe manual connection for devices.
However a tool is available, hosted by eduroam EU, which may be used by institutions to provide scripts for
automated configuration for most platforms.
The tool, eduroam Configuration Assistant Tool, is available for use by institutional administrators.
Institutional administrators are provided access to this tool, and interfaces for populating data required to
generate the configuration scripts.
End-users may access the scripts via the CAT, or institutions may download the scripts and provide access
to them on a local intranet.
Information on CAT is available at:
https://wiki.geant.org/display/H2eduroam/A+guide+to+eduroam+CAT+for+institution+administrators
End-User Education
Users should be made aware of their need to protect their credentials, keeping their password private. Users
should also be made aware of security risks associated with eduroam, that is, the requirement to
authenticate their home RADIUS server. Implications of not doing so should be made clear, in particular for
those sites relying on TTLS/PAP where a rogue eduroam infrastructure may steal user credentials unless
users are vigilant in authenticating their home RADIUS server.
Ver 1.0 21st April 2016
24 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Information to be provided to the NRO
The following information must be provided to the NRO.
Note that one set of institution-wide data must be provided, and if individual campuses deviate from
institutional provision, the differences need to be described for those specific campuses.
Information item
Description/Comment
Institutional Contacts
Contact type, Full name, email address, phone number, and
mobile number for SMS.
At least 2 technical contacts. Security and Management contacts
optional.
Mail-List subscription
Confirmation of mail-list subscription of technical contacts
Institutional test accounts
Institutional test accounts for each realm, including appropriate
authentication methods.
SP Test Account
Confirmation of receipt of test account from the NRO and access
by IT support for testing SP operability.
Local IT Support eduroam and
Workflow education
Confirmation that local IT support has received basic training in
eduroam is aware of the eduroam support workflow and
escalation procedure.
End-user eduroam and security
education
Confirmation that local users have access to basic training
information on eduroam and security related aspects, in particular
need to authenticate their home RADIUS server.
Use of eduroam Configuration
Assistant Tool
Confirmation of use of eduroam CAT.
Confirmation of type of use (locally provided links or advice to
users to accessing CAT via its native interface).
Ver 1.0 21st April 2016
25 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
eduroam Webpage
The institution is required to publish an institutional eduroam informational webpage. Essentially this page
should provide all information required for local users and visitors to connect to eduroam at the institution,
thereby enabling ‘self-service’ and avoiding support requests.
The NRO should provide a template (e.g. Word document) covering the requirements described below.
Implementation Items
Mandatory
Item
Description
Public institutional eduroam
webpage
Public eduroam webpage covering items described below.
Required Information
General Information

Information and link to global eduroam (http://eduroam.org) and the NRO eduroam sites

Statement of conformance with global eduroam and the NRO eduroam policies

A link to the institution’s network 'acceptable use policy' (AUP). eduroam users are required to conform to
their Home Institution AUP. However visitors are recommended to read and comply with the institutions
AUP. (The assumption is that R&E institution AUP's will be reasonably equivalent, hence compliance with
the Home institution AUP will deliver compliance with the institution AUP.)
IdP-role-specific Information

Clear statement on local user responsibilities (e.g. AUP conformance) in using eduroam on the
institution’s campuses and elsewhere

Links to information on authentication configuration for various devices (e.g. obtained via the eduroam
"Configuration Assistant Tool" which may be used to generate required device specific configuration
scripts)

Ability of the institution’s users to access their home institutional network while on their home institution
campus (at least required to initially configure eduroam authentication).

Strong recommendation to initially configure authentication while on their home institution campus prior to
travelling to another institution and using eduroam.

Link to eduroam support at the institution, and recommendation to seek support from their home
institution in first instance even when visiting another eduroam participating institution.
SP-role-specific Information

Technical information on connecting to the institution’s wireless infrastructure (WPA2-Enterprise),
description of network access restrictions for visitor access, and a link to the institution’s local support
with invitation to contact in case of connectivity or network access issues.

Link to the institution’s privacy statement and notification of logging of visitor's authentication requests
and network access for successfully authentications.
Ver 1.0 21st April 2016
26 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Information to be provided to the NRO
The following information must be provided to the NRO.
Note that one set of institution-wide data must be provided, and if individual campuses deviate from
institutional provision, the differences need to be described for those specific campuses.
Information item
Description/Comment
eduroam Webpage URL
When created, the institutional eduroam webpage URL should be
advised to the NRO for initial feedback.
The formal review of the website will be performed during Step 3.
of the joining process, the eduroam operability audit.
Ver 1.0 21st April 2016
27 of 28
Neil Witheridge
Institutional eduroam Implementation Plan
Appendix A: Institutional eduroam Implementation Workflow
Workflow for implementing eduroam IdP+SP operability:
Ver 1.0 21st April 2016
28 of 28
Neil Witheridge