institutional eduroam implementation plan - aarnet web viewthis document describes the institutional...

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


Discussion ....................................................................................................................................19Recommended Ports and Protocols .......................................................................................................19


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


eduroam Webpage ...........................................................................................................24Implementation Items ...................................................................................................................24

Mandatory .............................................................................................................................................. 24Required Information ....................................................................................................................24

General Information ............................................................................................................................... 24IdP-role-specific Information .................................................................................................................. 24SP-role-specific Information ................................................................................................................... 24


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



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


Network Access ................................................................................................................19Implementation Items ...................................................................................................................19


Discussion ....................................................................................................................................19Recommended Ports and Protocols .......................................................................................................19


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


eduroam Webpage ...........................................................................................................24Implementation Items ...................................................................................................................24

Mandatory .............................................................................................................................................. 24Required Information ....................................................................................................................24

General Information ............................................................................................................................... 24IdP-role-specific Information .................................................................................................................. 24SP-role-specific Information ................................................................................................................... 24


Appendix A: Institution eduroam Implementation Workflow .......................................26



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



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




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.



Deployment Tasks

An outline of each deployment task is provided below.



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.



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).



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.



[Figure 1. ] Independent Typical Institution eduroamInstitutional eduroam Deployment Scenario[Figure 2. ]



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.



[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).



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.


https://community.jisc.ac.uk/groups/dot1x-sig/document/radius-server-choice-guide-eduroam


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.



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.)



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.



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.)


Paul Hii, 21/04/16,

Why need to mention this?

Paul Hii, 20/04/16,

Why need to mention this?

https://wiki.geant.org/display/H2eduroam/How+to+deploy+eduroam+on-site+or+on+campus#Howtodeployeduroamon-siteoroncampus-IdentityManagementSystem

https://wiki.geant.org/display/H2eduroam/How+to+deploy+eduroam+on-site+or+on+campus#Howtodeployeduroamon-siteoroncampus-IdentityManagementSystem


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



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.



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.



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:

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.



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.


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.



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.



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.


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)



Information to be provided to NROthe NRO

The following information will have been provided to NROthe NRO during step 1 of the joining process:


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



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.


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:

(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.


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.


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


https://www.eduroam.org/downloads/docs/GN3-12-192_eduroam-policy-service-definition_ver28_26072012.pdf

https://www.eduroam.org/downloads/docs/GN3-12-192_eduroam-policy-service-definition_ver28_26072012.pdf



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.



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)


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.



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. [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 vigilentvigilant in authenticating their home RADIUS server.


https://wiki.geant.org/display/H2eduroam/A+guide+to+eduroam+CAT+for+institution+administrators



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.


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).



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.


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.




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.


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.



Appendix A: Institution eduroamInstitutional eduroam Implementation WorkflowWorkflow for implementing eduroam IdP+SP operability:


institutional eduroam implementation plan - aarnet web viewthis document describes the institutional...

Documents