institutional eduroam implementation plan - aarnet web viewthis document describes the institutional...
Post on 02-Feb-2018
214 Views
Preview:
TRANSCRIPT
Institutional eduroamImplementation Plan
Author: Neil Witheridge Date: 21st April 20168th April 2016
Version: 1.00.1
About This Document
This document describes the institution eduroaminstitutional eduroam implementation plan, addressing technical and administrative requirements for participating in the national eduroam federation. This plan is based on AARNet’s eduroam institution implementation plan.
Contents
Introduction ........................................................................................................................3Terminology ....................................................................................................................................3
Institutional eduroam Service Type ..........................................................................................................4eduroam Prerequisites ...................................................................................................................4
Information previously provided to the NRO ............................................................................................4
Implementation Plan Overview .........................................................................................5Deployment Tasks ..........................................................................................................................5
RADIUS Servers ...................................................................................................................................... 6Wireless Infrastructure ............................................................................................................................. 6Network Access ....................................................................................................................................... 6Institutional eduroam Support .................................................................................................................. 6Institutional eduroam Webpage ...............................................................................................................6
Information Transfer to the NRO ....................................................................................................7Institutional eduroam Deployment Scenarios .................................................................................7
Typical Institution ..................................................................................................................................... 7Institution acting as eduroam SP for Partners ..........................................................................................8Other Scenarios ....................................................................................................................................... 8
NRO eduroam Operational Objectives .............................................................................9National RADIUS Server Operation ...............................................................................................9Operability Monitoring ....................................................................................................................9Information Resources ...................................................................................................................9Support to Institutional Administrators ...........................................................................................9
Institution RADIUS Server(s) Deployment .....................................................................10Implementation Items ...................................................................................................................10
Required ................................................................................................................................................ 10Recommended ....................................................................................................................................... 12Optional .................................................................................................................................................. 12
Discussion ....................................................................................................................................12Required RADIUS Attributes .................................................................................................................. 12RADIUS Server Certificate ..................................................................................................................... 13Filtering invalid usernames and realms ..................................................................................................14Non-responsive Server Handling ...........................................................................................................15RADIUS Server Logging ........................................................................................................................ 15
Information to be provided to the NRO .......................................................................................15
Wireless Infrastructure ....................................................................................................17Implementation Items ...................................................................................................................17
Required ................................................................................................................................................ 17Recommended ....................................................................................................................................... 17
Ver 1.00.1 21st April 20168th April 2016 Draft 1 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Information to be provided to the NRO ........................................................................................18
Network Access ................................................................................................................19Implementation Items ...................................................................................................................19
Required ................................................................................................................................................ 19Recommended ....................................................................................................................................... 19Optional .................................................................................................................................................. 19
Discussion ....................................................................................................................................19Recommended Ports and Protocols .......................................................................................................19
Information to be provided to the NRO ........................................................................................20
Institutional Support ........................................................................................................21Implementation Items ...................................................................................................................21
Mandatory .............................................................................................................................................. 21Recommended ....................................................................................................................................... 21
Discussion ....................................................................................................................................21Local eduroam Contacts ........................................................................................................................ 21Local Support Workflow ......................................................................................................................... 22Test accounts ......................................................................................................................................... 22eduroam Configuration Assistant Tool ...................................................................................................22End-User Education ............................................................................................................................... 22
Information to be provided to the NRO ........................................................................................23
eduroam Webpage ...........................................................................................................24Implementation Items ...................................................................................................................24
Mandatory .............................................................................................................................................. 24Required Information ....................................................................................................................24
General Information ............................................................................................................................... 24IdP-role-specific Information .................................................................................................................. 24SP-role-specific Information ................................................................................................................... 24
Information to be provided to the NRO ........................................................................................25
Appendix A: Institutional eduroam Implementation Workflow ....................................26Introduction ........................................................................................................................3
Terminology ....................................................................................................................................3Institution eduroam Service Type .............................................................................................................4
eduroam Prerequisites ...................................................................................................................4Information provided to NRO previously ..................................................................................................4
Implementation Plan Overview .........................................................................................5Deployment Tasks ..........................................................................................................................5
RADIUS Servers ...................................................................................................................................... 5Wireless Infrastructure ............................................................................................................................. 6Network Access ....................................................................................................................................... 6Institutional eduroam Support .................................................................................................................. 6Institutional eduroam Webpage ...............................................................................................................6
Information Transfer to NRO ..........................................................................................................6Institution eduroam Deployment Scenarios ...................................................................................7
Independent Institution ............................................................................................................................. 7Public Institution ....................................................................................................................................... 8Other Scenarios ....................................................................................................................................... 8
NRO eduroam Operational Objectives .............................................................................9National RADIUS Server Operation ...............................................................................................9Operability Monitoring ....................................................................................................................9Information Resources ...................................................................................................................9Support to Institutional Administrators ...........................................................................................9Institutional Deployment Information Self-Maintenance (Future) ...................................................9
Institution RADIUS Server(s) Deployment .....................................................................10
Ver 1.00.1 21st April 20168th April 2016 Draft 2 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Implementation Items ...................................................................................................................10Required ................................................................................................................................................ 10Recommended ....................................................................................................................................... 11Optional .................................................................................................................................................. 12
Discussion ....................................................................................................................................12Required RADIUS Attributes .................................................................................................................. 12RADIUS Server Certificate ..................................................................................................................... 12Filtering invalid usernames and realms ..................................................................................................14Non-responsive Server Handling ...........................................................................................................15RADIUS Server Logging ........................................................................................................................ 15
Information to be provided to NRO ..............................................................................................15
Wireless Infrastructure ....................................................................................................17Implementation Items ...................................................................................................................17
Required ................................................................................................................................................ 17Recommended ....................................................................................................................................... 17
Information to be provided to NRO ..............................................................................................17
Network Access ................................................................................................................19Implementation Items ...................................................................................................................19
Required ................................................................................................................................................ 19Recommended ....................................................................................................................................... 19Optional .................................................................................................................................................. 19
Discussion ....................................................................................................................................19Recommended Ports and Protocols .......................................................................................................19
Information to be provided to NRO ..............................................................................................20
Institutional Support ........................................................................................................21Implementation Items ...................................................................................................................21
Mandatory .............................................................................................................................................. 21Recommended ....................................................................................................................................... 21
Discussion ....................................................................................................................................21Local eduroam Contacts ........................................................................................................................ 21Local Support Workflow ......................................................................................................................... 22Test accounts ......................................................................................................................................... 22eduroam Configuration Assistant Tool ...................................................................................................22End-User Education ............................................................................................................................... 22
Information to be provided to NRO ..............................................................................................23
eduroam Webpage ...........................................................................................................24Implementation Items ...................................................................................................................24
Mandatory .............................................................................................................................................. 24Required Information ....................................................................................................................24
General Information ............................................................................................................................... 24IdP-role-specific Information .................................................................................................................. 24SP-role-specific Information ................................................................................................................... 24
Information to be provided to NRO ..............................................................................................24
Appendix A: Institution eduroam Implementation Workflow .......................................26
Ver 1.00.1 21st April 20168th April 2016 Draft 3 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
IntroductionThe eduroam joining process for an institutions institution consists of 4 steps:
[1.] Institution’s Application to the NRO to participate in eduroam, involving the Exchange exchange of institutional and basic eduroam deployment planning information allowing the National Roaming Operator (NROthe NRO) to assess the institution’s satisfaction of pre-requisites and ability to operate sustainably as an eduroam participant;
1.[2.] Deployment of eduroam, satisfying technical and administrative requirements;
2.[3.] eduroam Operability Auditing;
[4.] Announcement 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 (NROthe NRO): The entitityentity that operates the eduroam service for a country or economy. For example, the NRONRO may be a National Research and Education Network (NREN) operator. NROThe 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.1X802.1x protocol;
Network Access Server (NAS) i.e. a Wireless Access Point, Wireless LAN Controller. The NAS implements the IEEE 802.1X802.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.1X802.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 as 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
Ver 1.00.1 21st April 20168th April 2016 Draft 4 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
RADIUS servers (TLRS).
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’.
Some NROthe NROs also host 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 NROthe NRO-provided institutional SP test accounts.
Institution eduroamInstitutional 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
The first stepStep 1. of the eduroam joining process, the institutional application to participate in eduroam, involving 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, concludes with an invitation from NRO to the institution to proceed to deploy eduroam infrastructure and establish administrative processes required for eduroam participation.
Having received an invitation to proceed to Step 2, the institution has been deemed as 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 NROthe NRO previously
The following information will have been provided to NROthe 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
Ver 1.00.1 21st April 20168th April 2016 Draft 5 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Information item Description/Comment
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
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
Willingness to provide tLocal test account(s)
Confirm willingness to provide an 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 Potential 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 NROthe NRO TMS
Confirmation of willingness to configure trust for the eduroam NROthe NRO Test&Monitoring servers in eduroam institutional RADIUS servers.
Internet Service ProviderISP 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 if any
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 OverviewThe eduroam service relies on consistent implementation achieved in conformance with global and national eduroam policy.
Ver 1.00.1 21st April 20168th April 2016 Draft 6 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Deployment Tasks
An outline of each deployment task is provided below.
Ver 1.00.1 21st April 20168th April 2016 Draft 7 of 37 Neil Witheridge
AARNet Confidential 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 NRO test and monitoring server (operability monitoring)
o Authentication transaction logging (ensuring the required attributes are logged)
o Configuration for trust for the eduroam NROthe NRO TMS in each of the institution’s eduroam RADIUS servers for eduroam operability monitoring.
To assist with RADIUS Server deployment, the NRO 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 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.
Ver 1.00.1 21st April 20168th April 2016 Draft 8 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Institutional eduroam Webpage Creation of a public eduroam informational webpage, providing comprehensive eduroam service
information to local users and visitors.
Information Transfer to NROthe NRO
Each of the above tasks involves providing deployment information to NROthe NRO in order that the NRO NRO can create an accurate record of the institution’s eduroam deployment in the eduroam NROthe 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 NROthe NRO, the institution will perform self-monitoring and internal testing to ensure readiness for eduroam operability auditing (step 3 of the eduroam Jjoining Pprocess).
Ver 1.00.1 21st April 20168th April 2016 Draft 9 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Institution eduroamInstitutional eduroam Deployment Scenarios
Below are just 2 examples of possible eduroam deployment scenarios for institutions.
Independent Typical Institution
From an eduroam perspective, it is anticipated that typically an 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.
Ver 1.00.1 21st April 20168th April 2016 Draft 10 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Ver 1.00.1 21st April 20168th April 2016 Draft 11 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
[Figure 1. ] Independent Typical Institution eduroamInstitutional eduroam Deployment Scenario[Figure 2. ]
Ver 1.00.1 21st April 20168th April 2016 Draft 12 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Public 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.
From an eduroam perspective, iIt is anticipatedmay be appropriate that a forlarge public 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, the eduroam connectivity (including RADIUS servers, and support elements such as and IT support and informational webpage) will tobe provided by a central administrative organisation (for example by a state-based Department of Education) its Partners. From an eduroam operational perspective, Partner Institutions are seen as realms of the Meta-Institution, and the Meta-Institution is responsible for Partner institution compliance with eduroam IdP policy. This scenario is depicted in Figure 3.
Ver 1.00.1 21st April 20168th April 2016 Draft 13 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Ver 1.00.1 21st April 20168th April 2016 Draft 14 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
[Figure 3. ] Public Institution eduroamInstitutional eduroam Deployment Scenario
Notes:
1. In the above diagram the ‘anchor controller’ operated by the governing organisationMeta-Institution may not exist i.e. wireless infrastructure at each Partner Iinstitution may be stand-alone and be configured to authenticate against the institution Meta-Institution RADIUS server operated by the administrative organisation.
2. It is assumed that each institution Partner Institution will have its own ‘realm’ (depicted as “myschool1partner1.edu.au”, “myschool2partner2.edu.au”, “myschool2partner3.edu.au”) and the institution RADIUS Server operated by the administrative Meta-Institution organisation will be configured to handle (i.e. authenticate users from) those realms.
3. It is assumed that there the Meta-Institution providesis a centralised ITcentralised IT Support function. However it is anticipated that each Partner iInstitution 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 centralised Meta-Institution IT support function.
Other Scenarios
There may 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 NRO.
NRONRO eduroam Operational ObjectivesThe implementation steps described in following sections reflect the NRO NRO’s operational objectives in delivering the eduroam service to institutions.
National RADIUS Server Operation
As the eduroam National Roaming Operator, the NRO 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
NROThe 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 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 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 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 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).
Ver 1.00.1 21st April 20168th April 2016 Draft 15 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
The NRO 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 NRO is responsible for providing support to institutional administrators. Hence it is important that the NRO 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 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 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 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.
Institution RADIUS Server(s) DeploymentThe 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. Typically, 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 implementation and install on server
Deploy an implementation of RADIUS which is compliant with RFC2865. Primary candidates are FreeRADIUS, Radiator, Cisco ISE, Microsoft NPS. A 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.
Ver 1.00.1 21st April 20168th April 2016 Draft 16 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
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 wireless AP/WLC & eduroam infrastructure (NRS,TMS)
Configure as trusted clients the Institutional institutional wireless infrastructure (Access Points/ Wireless LAN controller) using 802.1xAccess Points/ Wireless LAN controller, and NROthe NRO hosted operated NRS and TMS
Filtering (local rejection) of malformed usernames and invalid realms
Reject authentication requests with malformed username or invalid realms.
Proxy authentication requests for non-local realms to the NRS
Proxy authentication requests for non-local realms to the NRS.
RADIUS attributes in proxied request only required set
Include the minimal set of required attributes in proxied authentication requests (filter out other attributes sent from wireless infrastructure).
Release of Operator-Name Release the Operator-Name attribute in proxied authentication requests. Operator n-Name should be of the correct format according to RFC5580
Request Chargeable-User-Identity 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 populated with user-device’s MAC address
For the purpose of user traceability, it is necessary that the user device’s MAC address is populated and delivered to via the proxied authentication 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.
Ver 1.00.1 21st April 20168th April 2016 Draft 17 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Choice of tunnelled EAP Authentication Methods
Dependent 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+on-site+or+on+campus#Howtodeployeduroamon-siteoroncampus-IdentityManagementSystem
Authentication of local-realm users
Authenticate authentication requests forusers for local realms against the appropriate identity store. Local-domain authentication requests may be received from the institutional wireless infrastructure, the NRSs or TMS.
Release of Chargeable-User-Identity if requested
Release Chargeable-User-Identity (according to RFC, release CUI if requested in proxied authentication request from NRS) according to RFC4372
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 Chargeable-User-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 lLocal 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.
Release of Chargeable-User-Identity if requested
Release Chargeable-User-Identity (according to RFC, release CUI if requested in proxied authentication request from NRS) according to RFC4372
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.)
Ver 1.00.1 21st April 20168th April 2016 Draft 18 of 37 Neil Witheridge
AARNet Confidential 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, Cconfigure 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.00.1 21st April 20168th April 2016 Draft 19 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
RADIUS Server Certificate
When an Identity Provider uses multipledeploys multiple RADIUS servers for resilience reasonsHA, then all these servers can and should should have a certificate with the same name; and it may well be theuse the same identical server certificate.
It is a good idea recommended to use a server name which parses asis a fully-qualified domain name - (however t the he corresponding record does not have to existdomain name needn’t be registered in DNS) though. The server name should then be both in certificate's Subject field (Common Name component) and be a subjectAltName:DNS as well.
The following additional certificate properties are non-standard and are of particular interestuse in the eduroam context:
Property Content Remarks
server name parses as fully-qualified domain name
Server certificates with spaces, e.g. "RADIUS Service of Foo University" are known to be problematic with some supplicants, one example being Apple iOS 6.x.
server name Subject/CN == SubjectAltName:DNS
Some supplicants only consult the CN when checking the name of an incoming server certificate (Windows 8 with PEAP); some check either of the two; some new EAP types such as TEAP, and Linux clients configured by CAT 1.1.2+ will only check SubjectAltName:DNS. Keeping the desired name in both fields in sync is a safe bet for futureproofnessfutureproofing.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 one the same CN/subjectAltName:DNS values pair.
server name not a wildcard name (e.ge.g. "*.someidp.tld")
Some supplicants exhibit undefined/buggy behaviour when attempting to parse incoming certificates with a wildcard. Windows 8 and 8.1 are known to choke on wildcard certificates.
signature algorithm
Minimum: SHA-1Recommended: SHA-256 or higher
Server certificates signed with the signature algorithm MD5 are considered invalid by many modern operating systems., e.g. Apple iOS 6.x and above. Also Windows 8.1 and all previous versions of Windows (8, 7, Vista) which are on current patch levels will not validate such certificates. Having a server certificate (or an intermediate CA certificate) with MD5 signature will create problems on these operating systems.Apparently, no operating system as of yet has an issue with the root CA being self-signed with MD5. This may change at any point in the future though, so when creating a new CA infrastructure, be sure not to use MD5 as signature algorithm anywhere.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.
Ver 1.00.1 21st April 20168th April 2016 Draft 20 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Property Content Remarks
length of public key
Minimum: 1024 BitRecommended: 2048 Bit or higher
Server certificates with a length of the public key below 1024 bit are considered invalid by some recent operating systems, e.g. Windows 7 and above. Having a server certificate (or an intermediate CA certificate) with a too small public key will create problems on these 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. Therefore, fFor new certificates, 2048 bit or more is recommended .to avoid problems with the certificate in the future.
Extension: Extended Key Usage
TLS Web Server Authentication
Even though the certificate is used for EAP purposes, some popular operating systems (i.e. Windows XP and above) require the certificate extension "TLS Web Server Authentication" (OID: 1.3.6.1.5.5.7.3.1) to be present. Having a server certificate without this extension will create problems on these operating systems.
Extension: CRL Distribution Point
HTTP/HTTPS URI pointing to a valid CRL
Few very recent operating systems require this extension to be present; otherwise, the certificate is considered invalid. Currently, Windows Phone 8 is known to require this extension; Windows 8 can be configured to require it.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 otherwiseOne might be tempted to fill the certificate extension with a random garbage (or intranet-only) URL which does not actually yield a CRL; however this would make the certificate invalid for all operating systems which do evaluate the extension if present. So the URL should be a valid one.
Extension: BasicConstraint (critical)
CA:FALSE 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 Mac OS X 10.8 (Mountain Lion)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.
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 non-local 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.
Ver 1.00.1 21st April 20168th April 2016 Draft 21 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
The first part of that statement is simple, user names MUST contain an "@" symbol (e.g. username@camford.ac.uk) 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:
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 thesefiltering these are should be made available from the NRO 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.
Depending on the capabilities of yourIf the institution’s RADIUS server, the NRS can either handle non-responsiveness from you using timeouts (passive) or status-server checks (active). implementation is Status-Server capable, its use is strongly recommended.
Ver 1.00.1 21st April 20168th April 2016 Draft 22 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
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 NRO
The following information must be provided to the NRO NRO for each RADIUS Server deployed.
This information allows the NRO NRO to implement its operational objectives related to NRS configuration & RADIUS server monitoring.
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 stores
List of local realms supported by the RADIUS server and their 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.
Ver 1.00.1 21st April 20168th April 2016 Draft 23 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
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.
Request for Chargeable-User-Identity
Confirmation of request for CUI in proxied authenticaitonauthentication 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 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.
Ver 1.00.1 21st April 20168th April 2016 Draft 24 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Wireless InfrastructureWireless 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,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 NROthe 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.
Recommended
Item Description
Coverage Map Coverage map, leveraging existing wireless networking coverage map.
Wireless equipment Vendor, Make/Model, Version (informational purposes only for NROthe NRO)
Ver 1.00.1 21st April 20168th April 2016 Draft 25 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Information to be provided to NROthe NRO
The following information will have been provided to NROthe 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.1X802.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.00.1 21st April 20168th April 2016 Draft 26 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Network AccessConfiguration 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.
Ver 1.00.1 21st April 20168th April 2016 Draft 27 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Discussion
Recommended Ports and Protocols
The standard set of protocols and ports that are recommended to be provided to eduroam users are:
(listList taken from https://www.eduroam.org/downloads/docs/GN3-12-192_eduroam-policy-service-definition_ver28_26072012.pdf )
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 & outgoingoutgoing
SSH TCP/22 (SSH) outgoing
HTTP TCP/80 (HTTP) outgoing
TCP/443 (HTTPS) outgoing
TCP/3128 (Squid proxy) outgoing
TCP/8080 (HTTP proxy) outgoing
Mail Sending TCP/465 (SMTPS) outgoing
TCP/587 (SMTP message submission) outgoing
Mail Receipt TCP/143 (IMAP4) outgoing
TCP/993 (IMAPS) outgoing
TCP/110 (POP) outgoing
TCP/995 (POP3S) outgoing
FTP (passive) TCP/21 (FTP) outgoing
Institutions may open additional protocols and ports as permitted by local policies.
Information to be provided to NROthe NRO
It is assumed that the network configuration may be different for each campus, hence networking information is regarded as campus specific.
The following information must be provided to NROthe NRO per campus.
Note that one set of institution-wide data must 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
Ver 1.00.1 21st April 20168th April 2016 Draft 28 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Information item Description/Comment
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.00.1 21st April 20168th April 2016 Draft 29 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Institutional SupportThe 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 NROthe NRO (Level 3 support, support requests referred by the institutions designated technical administrator to an NROthe 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 administratoreduroam administrator mail list.
Institutional Test Accounts Provide institutional test accounts corresponding to each local realm handled by the institution.
Institutional support training on eduroam support workflow
Provide local institutional IT support with basic training on eduroam (training materials from NROthe NRO) and the required support workflow.
Recommended
Item Description
Configuration Assistant Tool Collaborate with NROthe 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 adminstratorsadministrators for the institution.
Ver 1.00.1 21st April 20168th April 2016 Draft 30 of 37 Neil Witheridge
AARNet Confidential 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.ge.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 NROthe NRO, the request should be sent to NROthe NRO support email address.
Local support training should be undertaken. Resources are available for support training from NROthe 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 NROthe 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 National Roaming OperatorRO.
NROthe NRO will configure the institution visitor test account on NROthe NRO’s test and monitoring RADIUS server for your own testing,
e.g. institution.edu.au@test.eduroam.edu.au
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 vigilentvigilant in authenticating their home RADIUS server.
Ver 1.00.1 21st April 20168th April 2016 Draft 31 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Information to be provided to NROthe NRO
The following information must be provided to NROthe 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, mobileand 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 NROthe 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,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,links or advice to users to accessing CAT via its native interface).
Ver 1.00.1 21st April 20168th April 2016 Draft 32 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
eduroam WebpageThe 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 NROthe NRO eduroam sites
Statement of conformance with global eduroam and NROthe 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,andaccess, 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.00.1 21st April 20168th April 2016 Draft 33 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Ver 1.00.1 21st April 20168th April 2016 Draft 34 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Information to be provided to NROthe NRO
The following information must be provided to NROthe 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 NROthe 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.00.1 21st April 20168th April 2016 Draft 35 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Appendix A: Institution eduroamInstitutional eduroam Implementation WorkflowWorkflow for implementing eduroam IdP+SP operability:
Ver 1.00.1 21st April 20168th April 2016 Draft 36 of 37 Neil Witheridge
AARNet Confidential Institutional eduroam Implementation Plan
Ver 1.00.1 21st April 20168th April 2016 Draft 37 of 37 Neil Witheridge
top related