About eduroam

On this page:

• About eduroam
• How eduroam Works
• An Overview of eduroam on JANET
• Using eduroam on JANET
• Implementing eduroam on JANET
• Update to the Technical Specification February 2009

eduroam on JANET

JANET is part of the eduroam confederation (www.eduroam.org) in which the UK, 32 other European countries, Canada and Australia, China (including Hong Kong) and Taiwan through APAN have collaborated to provide international RADIUS proxy authentication facilities.

- What is eduroam? - required viewing for all Freshers!

How Roaming Works

• An Overview of the eduroam on JANET

• 802.1X

http://www.terena.nl/activities/tf-mobility/deliverables/delD/DelD_v1.2-f.pdf

Web Redirect

http://www.terena.nl/activities/tf-mobility/deliverables/delF/DelF-f.pdf

 

An Overview of eduroam on JANET

Introduction

eduroam allows visitors from any participating organisation to use credentials provided by their Home organisation to gain network access at a Visited organisation. It facilitates a range of network access scenarios, ranging from casual visits and meetings to large conferences and classroom sharing. This document provides an overview of the most important participation requirements.

A participating organisation may act as either a Home organisation or as a Visited organisation or both, at their discretion.

General Requirements for both Home and Visited Organisations

• Deploy an Organisational RADIUS proxy server (ORPS)

Each participant must deploy an ORPS. The ORPS is a RADIUS server that provides the interface between participants' RADIUS systems and the National RADIUS proxy servers (NRPS) operated by JANET(UK). Two or more ORPS may be deployed to improve service resilience.

Home Organisation Requirements

• Configure the RADIUS server to authenticate their own users with the PAP and EAP protocols

Home organisations must deploy a RADIUS server to authenticate their own users using PAP and any suitable EAP method (such as TLS, TTLS or PEAP). The RADIUS authentication server may also act as the ORPS.

Visited Organisation Requirements

• Configure the RADIUS server and implement authentication mechanism for visitors

JANET(UK) specifies two service tiers for eduroam: JRS2 and JRS3. Participants that choose to be a Visited organisations must implement one of these tiers, at their discretion. The differences between the tiers are shown in Table 1 below.

Service tier	Authentication method	NAT	IPv6	WPA	WPA2	SSIDs
JRS2	IEEE 802.1x	May	May	Must	May	eduroam
JRS3	IEEE 802.1x	Must not	Must	Should	Must	eduroam

Table 1 - Tier requirements for Visited organisations.

• Permit the forwarding of certain IP protocols

The Technical Specification that Visited organisations must adhere to requires eduroam networks at sites to permit as a minimum egress and established forwarding of the protocols listed in Table 2 below. Visited sites may of course be more liberal and permit a wider range of protocols and a greater number of ports to be open, but this is at their discretion. [Certain messaging applications (eg MSN) will not be supported if only the following ports are open.]

Description	Protocols	Description	Protocols	Description	Protocols
IPv6 tunnel broker	UDP/3653 & TCP/3653	HTTPS	TCP/443	POP3S	TCP/995
IPSec NAT traversal	UDP/4500	LDAP	TCP/389	Passive (S)FTP	TCP/21
Cisco IPSec NAT traversal	UDP10000 & TCP/10000	LDAPS	TCP/636	SMTPS	TCP/465
PPTP	IP 47 & TCP/1723	IMSP	TCP/406	Message submission	TCP/587
OpenVPN	UDP and TCP 1194, TCP/5000-5110	IMAP4	TCP/143	RDP	TCP/3389
NTP	UDP/123	IMAP3	TCP/220	VNC	TCP/5900
SSH	TCP/22	IMAPS	TCP/993	Citrix	TCP/1494
HTTP	TCP/80	POP	TCP/110	AFS	UDP/7000-UDP/7007

Table 2 - Minimum requirements for egress and established forwarding of protocols.

Using eduroam on JANET

eduroam can be used from users' own laptops over wireless networks or via hardwired desktop PCs and MACs (for example in IT suites or libraries) that have been suitably configured. It can be used at Visited organisations and in many cases at Home organisations too.

End-users at customer organisations which have deployed eduroam should consult their IT Support dept. for one-off setup of their laptops prior to travelling to Visited sites providing the eduroam service. They will also be able to learn what facilities at the Home Organisation site are offered for remote access from Visited Organisations, (eg. e-mail, VPN). This information should be available on the eduroam pages of the Home Organisation web site, which can be found on the Participating Organisations Map by hovering over your city blob.

Users MUST also check the Participating Organisations Map to check that their laptop setup is compatible with the authentication method offered by the Visited Organisation and to learn the SSID which they must input into their laptop.

Once at Visited eduroam sites, end-users will be able to log on to the guest network by using their unique credentials (the same for all sites they might visit) - these are their own home organisation username and the organisation realm name in the form: username@foo.ac.uk. (Nb. this is NOT necessarily the user's e-mail address). Users will be able to do this at eduroam-enabled hotspots at the Visited sites which should be marked "eduroam".

Users experiencing any technical problems with the eduroam service or with remote access facilities provided by their Home Organisation, should in the first instance consult their Home Organisation IT Support dept.

Also see eduroam User Guide and eduroam Connection Guide.

UNINETT website "How to connect to an eduroam site" - useful configuration guide and technical information for users

Implementing eduroam on JANET

Follow link for a step-by-step guide to implementing eduroam - Implementing eduroam Roadmap.

And of course you could print the following manuals to have by your side:

eduroam Deployment Guide (pdf)

eduroam Technical Specification (doc) (pdf)

Inter-NREN Roaming Infrastructure & Service Support Cookbook 2nd Edition (pdf) (pdf)

and probably the 802.1x Implementation guide and Sussex FreeRADIUS 2 case study too!

 

Update to the Technical Specification v1.1 February 2009

The most significant changes to the requirements have been italicised.

Changes from version 1.0:

• Substituted all occurrences of ‘UKERNA’ with ‘JANET(UK)’, reflecting the change of trading name of The JNT Association.
• Set a date when the revised document takes effect.
• Capitalised all RFC 2119 keywords to conform to convention.
• Substituted the ‘rationale’ headings with ‘discussion’ throughout the document, reflecting the purpose of these sections.
• Substituted instances of ‘VLAN’ with ‘network’ throughout the document to avoid the spurious differentiation between ‘logical’ and ‘physical’ networks.
• Corrected the participation requirements in section 2.1 (‘Participation’) to permit participation from organisations that choose not to deploy a visitor network. This was the original intention of the previous version of the document.
• Moved the discussion on logging from section 2.4 (‘RADIUS Hosts’) to section 2.3 (‘Logging’) to aid clarity.
• Removed mandatory support for ICMP responses from section 2.3 (‘RADIUS Hosts’) because some RADIUS implementations do not support this, and added the JANET Roaming Support Server as a possible source of ICMP requests.
• Mandated a list of RADIUS attributes that must be forwarded by an ORPS in section 2.4 (‘RADIUS hosts’).
• Added a sub-section 2.5 ('JANET Roaming Website') to the 'Common Requirements' section; this has the effect of requiring all organisations (and not only Visited organisations) to publish a JANET Roaming website.
• Added requirements in section 2.5 (‘JANET Roaming Website’) relevant to all organisations to link to the JANET Roaming Policy and eduroam website.
• Added a brief discussion concerning the use of anonymous and pseudonymous user names in section 3.1 (‘User Names’).
• Removed section 3.3 PAP Authentication and the recommendation that organisations configure their RADIUS server to authenticate PAP (Password Authentication Protocol); this being unnecessary since the use of web redirect is no longer permitted by this specification. We do however recommend that organisations retain PAP authentication for the Test account to faciliate monitoring and troubleshooting.
• Changed the EAP type specification for the test account from being a requirement to being a recommendation, section 3.4 (‘Test Account’). Removed requirement for test account to be PAP authenticable and also recommended the use of either PEAP or TTLS.
• Renumbered section 3.6 (‘User security awareness’) to 3.5 and removed the discussion of web redirect this section; this information is redundant as the use of web redirect is no longer permitted by this specification.
• Removed the reference to a ‘local AUP’ in section 4.1 as an applicable document may not necessarily exist.

• Added a clarification in section 4.1 concerning the segregation of networks and visitors using VLANs or other techniques.
• Added a requirement in section 4.2 to explicitly prohibit the forwarding of requests from NASs other than those that conform to this specification.
• Added a requirement in section 4.2 to prohibit forwarding of realmless NAIs.
• Changed the heading of section 4.3 (‘NAS Requirements’) from ‘NAS General Requirements’.
• Clarified the appropriate uses of local authorisation or admission control in section 4.3.
• Removed section 4.10 (‘802.1X NASs’) and moved its requirements into section 4.3 (‘NAS Requirements’); 802.1X NASs are the only type permitted by this specification, as the use of web redirect is no longer permitted by this specification.
• Changed the heading of section 4.4 (‘Securing Host Network Configuration’) from ‘Securing Host Bootstrapping’ to assist understanding.
• Removed the discussion of web redirect from section 4.4 (‘Securing Host Network Configuration’); this information is redundant as the use of web redirect is no longer permitted by this specification.
• Changed the heading of section 4.5 (‘IP Forwarding’) from ‘IP Filtering’ to assist understanding.
• Added the Network Time Protocol to the list of mandatory forwarded protocols in section 4.5 (‘IP Forwarding).
• Added AFS to the list of mandatory forwarded protocols in section 4.5 ('IP Forwarding').
• Added port udp/10000 to the Cisco IPSec NAT traversal protocol’s policy in section 4.5 (‘IP filtering’). This corrects its accidental omission in the previous version of this policy.
• Updated the OpenVPN protocol’s policy in section 4.5 (‘IP Filtering’) to reflect the change in this protocol’s default port and transport.
• Added a recommendation in section 4.7 (‘JANET Roaming Website’) relevant to Visited organisations to publish the IP forwarding policies imposed on the visitor network on the JANET Roaming website.
• Moved some of the requirements that cover common requirements in section 4.7 ('JANET Roaming Website') to the new section 2.5 ('JANET Roaming Website').
• Changed the heading of section 4.8 (‘SSID’) from ‘SSIDs’ reflecting this specification’s use of a single SSID.
• Updated section 4.8 (‘SSIDs’) to require a single SSID for all tiers.
• Removed section 4.9 (‘WRD NASs’) as the use of web redirect is no longer permitted by this specification.

• Removed section 4.12 (‘WEP’) as the use of WEP is no longer permitted by this specification.
• Mandated the use of TKIP in section 4.10 (‘WPA’).
• Removed discussion of WEP in section 4.10 (‘WPA’) as WEP is no longer permitted by this specification.
• Mandated the use of CCMP (AES) in section 4.11 (‘WPA2’).
• Removed discussion of WEP in section 4.11 (‘WPA2’) as WEP is no longer permitted by this specification.

 

Any problems, comments or suggestions regarding this page, please e-mail the eduroam service manager.