eduroam in a nutshell
eduroam stands for education roaming. It offers users from participating academic institutions secure Internet access at any other eduroam participating location. The eduroam architecture that makes this possible is based on a number of technologies and agreements, which together provide the eduroam user experience: "open your laptop and be online".
The crucial agreement underpinning the foundation of eduroam involves the mechanism by which authentication and authorisation works:
- The authentication of a user is carried out at their Identity Provider (IdP), using their specific authentication method.
- The authorisation decision allowing access to the network resources upon proper authentication is done by the Service Provider (SP), typically a WiFi hotspot (University campus, etc.).
In order to transport the authentication request of a user from the Service Provider to his Identity Provider and the authentication response back, a world-wide system of RADIUS servers is created. Typically every Identity Provider deploys a RADIUS server, which is connected to a local user database. This RADIUS server is connected to a federation level RADIUS server, which is either in turn connected to the upstream RADIUS server infrastructure or can connect to other RADIUS servers dynamically (using the protocol RADIUS/TLS). Because users are using usernames of the format "user@realm", where realm is the IdP's DNS domain name often of the form institution.tld (tld=top-level domain; both country-code TLDs and generic TLDs are supported), the RADIUS servers can use this information to route the request to the appropriate next RADIUS server until the IdP is reached. An example of the RADIUS hierarchy is shown in Figure 2.1.
To transfer the user's authentication information securely across the RADIUS-infrastructure to their IdP, and to prevent other users from hijacking the connection after successful authentication, the access points or switches deployed by the SP use the IEEE 802.1X standard that encompasses the use of the Extensible Authentication Protocol (EAP). EAP is a container that carries the actual authentication data inside, the so-called EAP methods. There are many EAP methods an IdP can choose from.
eduroam requires that the chosen EAP method must allow
- mutual authentication (i.e. the user can verify that he is connected to "his" IdP whereever the user is
- encryption of the credentials used (i.e. only the user and his IdP will see the actual credential exchange; it will be invisible to the Service Provider and all intermediate proxies)
Some popular EAP methods in use in eduroam are
- PEAP ("Protected EAP") - a Microsoft protocol that establishes a TLS tunnel, and sends usernames and passwords in MS-CHAPv2 hashes inside)
- TTLS ("Tunneled TLS") - an IETF protocol that establishes a TLS tunnel, and sends usernames and passwords in multiple configurable formats inside)
- TLS ("Transport Layer Security") - an IETF protocol that authenticates users and the IdP with two X.509 certificates
- FAST ("Flexible Authentication via Secure Tunneling") - a Cisco protocol that establishes a TLS tunnel, and sends usernames and passwords in a custom way inside)
RADIUS transports the user's name in an attribute User-Name, which is visible in cleartext to all intermediate hosts on the way. Some EAP methods allow to put a different User-Name into the RADIUS packet than in the EAP payload. In that case, the following terms are used:
- outer identity: this is the User-Name in the RADIUS packet and visible to all intermediate parties
- inner identity: this is the actual user identification. It is only visible to the user himself and the Identity Provider
When using such EAP methods, and activating this option, the real username is not visible in RADIUS (it will only see the outer identity). Doing so will enhance the user's privacy, and is encouraged. Outer identities should be in the format "@realm" (nothing left of the @ sign, but the realm is the same as with the actual username). The realm part still must be the correct one as it is used to route the request to the respective Identity Provider. Once the IdP server decrypts the TLS tunnel in the EAP payload, it gets the inner identity and can authenticate the user.
After successful authentication by the Identity Provider and authorisation by the Service Provider, this SP grants network access to the user, possibly by placing the user in a specific VLAN intended for guests.
In the next chapter the various elements of this architecture and their functions is described.
Note: On responsibility for actions of the user: Directive 2001/31/EC article 12 defines the liability of a service provider:
- Where an information society service is provided that consists of the transmission in a communication network of information provided by a recipient of the service, or the provision of access to a communication network, Member States shall ensure that the service provider is not liable for the information transmitted, on condition that the provider:
(a) does not initiate the transmission;
(b) does not select the receiver of the transmission; and
(c) does not select or modify the information contained in the transmission.
- The acts of transmission and of provision of access referred to in paragraph 1 include the automatic, intermediate and transient storage of the information transmitted in so far as this takes place for the sole purpose of carrying out the transmission in the communication network, and provided that the information is not stored for any period longer than is reasonably necessary for the transmission.
- This Article shall not affect the possibility for a court or administrative authority, in accordance with Member States' legal systems, of requiring the service provider to terminate or prevent an infringement.
The complete Directive can be found at EUR-Lex1.
Figure 2.1: Layers of the eduroam RADIUS hierarchy NEED TO (RE)CREATE DIAGRAM ??
Please refer to deliverable DJ5.1.4 "Inter-NREN Roaming Architecture: Description and Development Items" for an in-depth description of eduroam and the underlying architecture.
Federation-Level RADIUS servers (FLRs)
A federation RADIUS server has a list of connected IdP and SP servers and the associated realms. It receives requests from the confederation servers and IdP/SP it is connected to and forwards them to the proper server, or in case of a request for a confederation destination to a confederation server.
IdP and SP RADIUS servers
The IdP RADIUS server is responsible for authenticating its own users (at its own premises, if it also an SP, or when they are visiting another SP) by checking the credentials against a local identity management system.
The SP RADIUS server is responsible for forwarding requests from visiting users to the respective federation RADIUS server. Upon proper authentication of a user the SP RADIUS server may assign a VLAN to the user.
Note that the IdP RADIUS server is the most complex of all. Whereas the other RADIUS servers merely proxy requests, the IdP server also needs to handle the requests, and therefore needs to be able to terminate EAP requests and perform identity management system lookups.
The Identity Management System contains the information of the end users; for instance usernames and passwords. They must be kept up-to-date by the responsible IdP.
A supplicant is a piece of software (often built into the Operating System but also available as a separate program) that uses the 802.1X protocol to send authentication request information using EAP. Supplicants are installed and operate on end-user computing devices (e.g. notebooks, PDAs, WiFi-enabled cell phones, and so on).
Access Points are Wireless LAN access devices conformant to IEEE 802.11 and need to be IEEE 802.1X capable. They must be able to forward access requests coming from a supplicant to the SP RADIUS server, to give network access upon proper authentication, and to possibly assign users to specific VLANs based on information received from the RADIUS server. Furthermore Access Points exchange keying material (initialisation vectors, public and session keys, etc.) with client systems to prevent session hijacking.
Switches need to be able to forward access requests coming from a supplicant to the SP RADIUS server, to grant network access upon proper authentication and to possibly assign users to specific VLANs based on information received from the RADIUS server.
eduroam set up on Campus: IdP and SP
The following sections provide detailed information for the two roles eduroam IdP and eduroam SP, respectively.
The eduroam IdP section explains the administrative obligations for an eduroam IdP, the set up of several popular RADIUS servers, and means to provision configuration details of supplicants to end users.
The eduroam SP section explains general basics of wireless LAN deployment, the administrative obligations for an eduroam SP, and the set up of several popular vendor WiFi environments for use in eduroam.
Reference Campus Setup
Campus networks vary widely in such things as topology, equipment used, software, and so on. In order to assist a campus administrator in setting up eduroam on their campus, this section presents the implementation of a typical setup. It is hoped that this will allow users of different topologies and/or equipment to understand the necessary steps to take. Furthermore, in the appendices the same setup will be expanded for a number of other common types of equipment and software. Lastly, we are planning to provide these and future example configurations on the website http://www.eduroam.org.
For the reference network we use a typical set of network equipment consisting of:
- A Cisco Catalyst 3550 (or similar) switch.
- A Cisco Aironet AP-1200 Access Point.
- A laptop with Windows XP.
- A Radiator RADIUS server.
The network topology is as follows:
Figure 3.1: Network Topology (NEED TO RE_CREATE DIAGRAM PAGE 23??)
In this setup, wireless users are separated in different VLANs: VLAN906 for administrative users and VLAN909 for normal eduroam users. The next table describes each VLAN used in this document:
VLAN for internet access – access to core routers
The Administrative VLAN of the hotspot (AP's; RADIUS; etc.)
VLAN with open SSID for giving information about the institute
VLAN reserved for administrative users
VLAN reserved for 'normal' eduroam users
Table 3.1: VLAN description
The next table describes the IP configuration for the router sub-interfaces and what networks are configured for each VLAN:
Interface IP Address
What is accessible in this network
Some public IP address
AP's; RADIUS Server
Table 3.2: Router Configuration
Configuring the Ethernet switch for eduroam
In order to gain access to the Internet the configuration of the Ethernet switch needs to be changed. You must create a VLAN in which the Access Points will be placed, and provide it with the correct IP-address and gateway information. This can be done with the commands described below.
The next table describes the VLAN associated with each Port of the switch and what equipment will be connected to that specific port.
What is connected to it
U (902) T (909)
U (901) T (902; 909)
Central Ethernet Switch
Table 3.3: Ethernet Switch Configuration
First configure the port where the RADIUS Server will be connected and put it on the Administrative VLAN:
switch(config-if)#description RADIUS Server
switch(config-if)#switchport mode access
switch(config-if)#switchport access vlan 902
Then configure all switch-ports that will connect Access Points for the VLAN's that users and Access Points can have access to (in trunk mode). At a minimum configure the administrative VLAN and the VLAN where authenticated users will be placed:
switch(config)#interface range fastethernet0/2 - 47
switch(config-if)#description eduroam Access Points
switch(config-if)#switchport trunk encapsulation dot1q
switch(config-if)#switchport trunk native vlan 902
switch(config-if)#switchport trunk allowed vlan 902, 909
switch(config-if)#switchport mode trunk
The uplink can be defined with:
switch(config-if)#switchport trunk encapsulation dot1q
switch(config-if)#switchport trunk native vlan 901
switch(config-if)#switchport trunk allowed vlan 901, 902, 909
switch(config-if)#switchport mode trunk
Cisco AP 1200 Series (802.11g Radio).
The configuration examples used in this document were tested and made on a Cisco Series 1200 with an 802.11g Radio Module and with the following Cisco software:
Setting the Name and IP address
First, an IP address on the BVI interface (the IP address that this Access Point will have for accessing
resources like the RADIUS server) needs to be configured. Also a unique name for this Access Point (ap1200)
will be configured.
In the authentication, authorisation and accounting configuration parameters (AAA), at least one group needs to
be defined (radsrv), which will be assigned later for the several AAA operations. More groups can be defined if
needed for various purposes; one for authentication, another for accounting, and so on. In this example the
RADIUS server has the IP address 192.168.10.253.
Configuring the SSIDs
For each SSID one dot11 ssid <SSID NAME> must be configured. In this section the default VLAN for the SSID
will be configured as well as the authentication framework, the accounting and, if desired, the SSID to be
More SSIDs can be configured. An open SSID for giving information about the institution and/or how to
connect to the eduroam SSID:
The Radio Interface
Now the configured SSID's will be mapped to the radio interface, and it will be specified what ciphers will be
used/allowed on each VLAN. If dynamic VLANs are planned, the ciphers for those VLANs must also be
configured even if there is no direct mapping on any SSID (this example shows the usage of the VLANs 906
and 909 for eduroam users)
To bind extra SSID's the previous command, for each SSID to be bound, needs to be repeated.
The following command sets the maximum time (e.g. 300 seconds, which is recommended) for
For each VLAN to be used for wireless clients, two virtual interfaces need to be defined: one on "the air"
(DotRadio) and another on the "wire" (FastEthernet) then they need to be bridged together with the same
bridge group. These VLANs are always tagged with the proper VLAN identifier.
An administrative VLAN needs to be configured as well (for maintenance/management and
authentication/accounting traffic). This VLAN is usually untagged (the command defining the VLAN has to be
suffixed with the keyword "native") and belongs to bridge-group 1. The Radio virtual interface for this VLAN
does not need to be defined since the default will keep the physical interface (Dot Radio 0) in bridge-group 1.
Because VLANs can be from 1 to 4094 and bridge-groups from 1 to 255, it is not necessary to have the same
bridge-group id as the vlan id.
The multiple (dynamic) VLAN assignment
The example configuration above did not configure dynamic VLAN assignment. Availability of this feature varies between models of the 1200 Series, so please exercise caution when procuring if you wish to make use of this feature. If multiple VLANs are configured on the Cisco AP, it is mandatory to associate each SSID to at least one VLAN, otherwise the Access Point will not activate the SSID's. It is possible however, to put different users who are connected to the same SSID (e.g. eduroam) on different VLANs based, for instance, on the user profile. To activate this feature it is necessary to enter
in the Access Point's configuration. The AP then gives priority to the VLANs returned by RADIUS over the ones statically associated with the SSID. This enables the feature dynamic VLAN assignment.
Cisco's Access Points require that two virtual interfaces (a radio and an Ethernet port interface) are configured for each VLAN. If, for example, four VLANs are to be used for eduroam users (for students, admin staff, teachers and visiting eduroam users from other institutions for example) then it is necessary to define one Dot11Radio0.vlanID, and one FastEthernet0.vlanID, and ensure that both have the same encapsulation dot1Q vlanID and the same bridge-group for each VLAN.
Two commands that are also needed are the below, otherwise the access point will not change the user to the received VLAN:
The required configuration can be downloaded as a file fromhttp://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip. You must then amend the file as indicated by the comments in the file, and then copy and paste the commands into the Access Point in configuration mode (telnet or console access).
(obsolete section) Appendix A: RADIUS servers
As the eduroam infrastructure is build upon RADIUS servers, the following picture depicting the message flow
inside an institutional RADIUS server might be helpful.
Figure A 1: Message flow in RADIUS server Identity Management System
A.2.6 User authentication: configuring an eduroam IdP
Configuring an IdP involves:
- Configuring the server as EAP endpoint.
- Configuring the local database backend.
EAP configuration happens in the file eap.conf (downloadable from
http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip). This example, eap.conf file is
configured to accept both TTLS and PEAP requests and process them with the same backend. For a
discussion of when to use TTLS and when PEAP, please refer to section 126.96.36.199 of this document. The
following notes refer to different modules within the file:
- In the tls section, the server certificate that is presented to the users while they authenticate is defined.
certdir, private_key_... have to point to the appropriate files on the server. It appears confusing for most
new administrators that tls needs to be defined even though EAP-TLS is not a desired authentication
method. This is because the ttls and peap sections share the certificate parameters and rely on the
existence of the tls stanza. Unwanted EAP-TLS authentication can be prevented by pointing cadir to a
dummy Certification Authority (like the one that is created on first server startup) which never issues
proper client certificates.
- The ttls and peap sections denominate a dedicated virtual server to handle the inner tunnel request
(which happens after the TLS handshake with the supplicant has completed). Note that there needs to
be an empty mschapv2 stanza in eap.conf to make PEAP work – this is due to internal server workings
- To include EAP into the virtual server eduroam (see section A.2.4 "Virtual server definition for eduroam:
sites-enabled/eduroam"), only two lines need to be added; the new virtual server "eduroam-innertunnel"
(which we defined in eap.conf before) needs be set up to do the actual user authentication, and
the module eap must be listed at the end of the authorise and authenticate sections.: The most notable difference between the inner server and the outer is that the inner tunnel does not do
EAP. Instead, it uses the ldap module in the authorize and authenticate sections to authenticate users
against the ldap backend. Note that the ldap module is configured in radiusd.conf. You have to enter
the appropriate connection details to your LDAP server there and open firewall ports from the RADIUS
server to the LDAP server if need be.
Also note that this virtual server does not call the suffix module. This means the inner request does not
get proxied elsewhere. This is a standard security measure in eduroam.
The virtual server definition also includes the files module. When doing LDAP authentication, this is
optional. In the example file, we use this module to have test users in the flat file "users" in order to
have a possibility of debugging authentication. Once the authentication against the file works and the
LDAP connection is set up properly, the files module is only needed for advanced topics like VLAN
• For an initial setup of the users file, administrators should delete all existing entries and add only the
following line in the file:
This creates a test user with the name "firstname.lastname@example.org" and a password. It can be used to test authentication.
- In case a VLAN assignment should be done, the users file needs to contain the corresponding RADIUS
attributes, like in the following example for VLAN 313:
- The configuration of the ldap module itself happens in radiusd.conf. This config stanza is extensively
documented in the file, so below just a simple example of a sample configuration (based on an
eduPerson LDAP schema).
- If logging of accounting requests to a database is desired (see below), it is also wise to extend the
accounting key in the acct_unique module to make accounting more robust.
A.2.7 Setting up accounting in the SQL database
All accounting information is logged into the MySQL database. The configuration is in the file
/etc/raddb/sql.conf. The content of this file should be replaced with that found in http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip.
A.2.8 Logging the client IP address as Service Provider (Optional)
The client IP address is logged in the DHCP log file. However this information can also be stored in the
ACCOUNTING table with other accounting data and thus provide easy access to that data. A Sysadmin needs
to set-up a script to update the SQL database information with the assigned IP address. The client IP address
is determined by tailing the DHCP log file and monitoring all IP assignments. The script also monitors active
connections and cleans up accounting (closes accounting) for stale connections. SNMP access to Access
Points is required.
The script is available from here: http://www.eduroam.si/uploads/CN/eC/CNeCC3Uc7XI9Tw_dLtwYZg/eduroam_monitor-20060809.tar.bz2
The access points need to be registered with the script. This is done by entering the needed access point data
into the database:
create table access_points (
`IP address` varchar(100) PRIMARY KEY NOT NULL,
`snmp secret` varchar(100) NOT NULL default '',
`radius secret` varchar(100) NOT NULL default '',
`root username` varchar(100) NOT NULL default '',
`root password` varchar(100) NOT NULL default ''
A.2.9 More information
The original Slovenian Eduroam technical specifications and sample configuration site:http://www.eduroam.si
ARNES AAI technical support e-mail address: email@example.com
Eduroam-in-a-box web configuration tool:http://eduroam.sourceforge.net
(obsolete section) Appendix B: Access Points
This section describes the configuration of the Access Points:
- Cisco Aironet 1200 series.
- Lancom L-54.
These Access Points have been used extensively by JRA5 activity members, and so their configuration and
suitability for eduroam are well established.
B.1 Cisco Aironet 1200 Series example setup
The required configuration can be downloaded as a file fromhttp://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip. You must then amend the file as
indicated by the comments in the file, and then copy and paste the commands into the Access Point in
configuration mode (telnet or console access).
B.2 LANCOM L-54 Series Access Points
This series of Access Points offers a wide range of features for a mid-range price. One of the outstanding features in its price class is the ability to use ARP sniffing to determine a client's IP address even if it changes during a user session. Activating this feature fulfils the requirement for MAC to IP correlation from the confederation policy and obsoletes logging of DHCP leases.
The following steps are needed to set up eduroam on a Lancom L-54 or L-300 series access point. It describes the setup via the web interface and is current as of LCOS Version 8.0. The starting point of this tutorial is a factory-reset device, i.e. it is not configured at all and set up to its defaults.
Appendix C Supplicants
This section describes the configuration of the following supplicants:
- MacOS X Supplicant for MacOS 10.5.
- wpa_supplicant for Linux.
- Intel PROset/Wireless
These supplicants are either Open Source or integrated into the Operating System, therefore there are no
licence fees to consider. The main difference between these supplicants is the degree to which they can be
preconfigured. Note that the WPA_supplicant can be used on either Unix or Windows platforms because of its
open source nature.
C.1 MacOS 10.5
These instructions are valid for Mac OS X 10.5 (Leopard) update 4. Please note that previous updates of
Leopard had a different user interface. Future updates could also change this interface and the instructions in
this document could be wrong or not accurate. Mac OS X Versions 10.7 and above are supported by eduroam CAT.
1. Open Network Preferences. This can be accessed either from the Systems Preferences panel or the
RECREATE 1st SCREENSHOT HERE?
2. If required, create a new Location for roaming purposes. You can create different locations for ease of
use (such as Home or Work). In this example, the Location University-roaming is used. Just the
wireless interface (also known as AirPort in Mac OS X) exists for this location:
RECREATE 3rd SCREENSHOT HERE?
3. Click on Advanced to open the Advanced Options panel for the AirPort interface. Of the tabs
available on this panel, the following will be used to configure eduroam:
802.1X. This tab is for configuring 802.1X access profiles. Please note that these profiles can be used
for several Locations.
○ AirPort. This tab will display when the interface is On or a network has been manually configured. It
displays the identifier for the different networks and security being used when connecting to them
(note that several security modes with the same identifier could be configured, for instance for WPA
4. Click on 802.1X to create an 802.1X User Profile. The 802.1x tab screen appears.
5. In the Profiles panel, click the plus (+) symbol and select Add User Profile:
Note: The commonest requirement is to create a user profile. However, you can also create a profile for
authenticating users to the system, or a common profile for all the users.
6. A User profile example dialogue appears. The minimum information you must enter for a user profile is:
Username and password (the actual username and password of the user).
The default wireless network identifier to join using this profile.
The authentication method to be used. This can be one of (most commonly):
— TTLS, which supports four inner authentication methods: MSCHAP, MSCHAPv2, CHAP, and
PAP. You can also provide an inner identity (optional, but recommended for eduroam). The
example below uses the prefix anonymous. However, just the postfix with the @ symbol and
the user home institution realm is acceptable.
— TLS. This method allows us to authenticate using a user certificate. The certificate must be
installed in the user's keychain (via the KeyChain Access application) for this option to be
activated. After activating the check box, a dialogue for selecting the appropriate certificate is
shown. In this example we use a certificate signed by the CA Cert Signing Authority:
— PEAP. This authentication method also offers the possibility for entering the outer identity:
RECREATE 1st SCREENSHOT p 100 HERE
7. Select the AirPort tab and use the plus (+) icon to add the eduroam network using the previously
created 802.1x profile. The following dialogue appears:
RECREATE 2nd SCREENSHOT p 100 HERE
8. Click on the Security box to display the following:
9. In most cases select either WPA Enterprise or WPA2 Enterprise.
Note: By selecting the 802.1x profile created in previously (field 802.1X), fields containing user
credentials are automatically populated with the values previously entered.
10. Activate the Airport interface.
11. Apply the changes made in the previous steps and activate the network, either from the Network
Preferences panel or the menu bar.
Assuming the configuration was successful, you will see something like the following:
While connecting to the server, it's possible that a certificate warning could appear. This happens when:
- The certificate presented by the RADIUS server being contacted is valid but not signed by any of the
Certification Authorities recognised by your computer. To prevent this, any new Certification Authority
should be added using the KeyChain Access tool. If you are confident that you are talking to the right
server, and that the certificate presented by the server contains all the certification path, you can trust
this certificate (any additional checks can be carried out by expanding the certificate information if
- The certificate presented by the RADIUS server is invalid or self-signed. In this case do not trust the
The preferred way to generate configuration profiles for iPhone, iPad and Mac OS X is eduroam CAT. The remainder of this section is only interesting for you if you do not want to make use of eduroam CAT for this purpose.
The iPhone Configuration Utility allows you to set up your iPhone to access eduroam. This tool helps you
create a wireless configuration profile (.mobileprofile file extension). There are versions for Windows and Mac
You can also download profiles sent to your iPhone.
C.3.1 Using the configuration utility
To configure your iPhone for eduroam:
1. Start the iPhone Configuration utility.
2. Select the Passcode tab and select Allow simple value:
RECREATE 1st SCREENSHOT p 102 HERE
3. Select the General tab and enter Identity details for this profile:
Name: Enter eduroam.
Identifier: Enter eduroam.
Organisation: Enter the name of your organisation.
○ Description: Enter a description for this profile.
RECREATE 2nd SCREENSHOT p 100 HERE
4. Click the Wi-Fi tab
RECREATE 1st SCREENSHOT p 103 HERE
5. Click Configure to enter connection and authorisation information as follows:
Service Set Identifier (SSID): Enter eduroam.
○ Security Type: Select WPA/WPA2 Enterprise.
6. Under Enterprise Settings click Protocols and under Accepted EAP Types select TTLS:
RECREATE 2nd SCREENSHOT p 102 HERE
7. Under Enterprise Settings click Authentication and enter authentication details:
Username: Enter your email address.
Inner Authentication: Select PAP.
Outer Identity: Enter the identity to be used for external identification (e.g.
RECREATE 1st SCREENSHOT p 104 HERE
8. Click the Credentials tab and enter the Credential Name to be used.
RECREATE 2nd SCREENSHOT p 103 HERE
9. Click the Wi-Fi tab and under Enterprise Settings click Trust to enter trust details:
○ Trusted Server Certificate Names: Enter the names expected from the Authentication server.
RECREATE 1st SCREENSHOT p 105 HERE
C.3.2 Downloading a profile
You can receive a profile on your iPhone. An example is shown below:
Opening the attachment to the message displays a dialogue such as:
Note: In this example the profile has not been signed. However the profile contains a valid TTLS+PAP
configuration and the right certificates for recognising the organisation radius server certificate.
If you decide to install this profile, you will be connected to eduroam:
wpa_supplicant (http://hostap.epitest.fi/wpa_supplicant/) is an open source 802.1x supplicant for Linux, BSD
and MS Windows. This section describes its use on the Linux platform. wpa_supplicant is available for most
modern Linux distributions and seems to be the focal point of 802.1X development on the *nix platform.
The eduroam CAT Linux installers configure wpa_supplicant; and if it is front-ended with NetworkManager then even in comfortable UI-friendly way. The remainder of this section is only interesting for you if you do not want to make use of eduroam CAT for this purpose.
It is out of scope of this cookbook to describe how wpa_supplicant can be compiled form source or what
options need to be enabled in the Linux kernel to make eduroam authentication work. Modern Linux
distributions with standard kernel, wireless tools and wpa_supplicant should work "out of the box".
Using the technical information below it is possible to implement eduroam support so that it will be seamlessly
integrated with the OS. This is, however, very distribution specific and therefore out-of-scope for this document.
It is assumed that the user has a working wireless card (this can be verified by using the iwconfig command).
wpa_supplicant is responsible for the (layer 2) authentication of the user, and must be followed by some means
of setting up the (layer 3) IP connection by using a DHCP-client. Wpa_supplicant typically runs in the
background to control the connection, take care of re-authentications, manage roaming between access points,
and so on. It is started with the command:
wpa_supplicant -i interface -c configuration_file -D driver --B
- interface is the system name for the wireless interface (like eth1, ath0, wlan0, etc.).
- configuration_file is the location of the file (described later on).
- driver is one of: wext, ipw, madwifi and ndiswrapper (described below).
- -B option means 'run in the background'.
The driver setting depends on the particular card used.
The wext diver currently supports most existing cards (Atheros chipset based cards being an exception,
madwifi should be used there). Hence, the wext setting should be tested first.
The configuration file depends on the EAP type of choice. Example configurations (which can be downloaded
from http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip) are provided for EAP-TTLS,
EAP-PEAP and EAP-TLS. Each of the examples contains two, nearly identical, network blocks; the only
difference is that one is for WPA and the second for dynamic WEP.
Note: In principle, one block with 'key_mgmt=WPA-EAP IEEE8021X' should be sufficient, but under certain
conditions this may fail. Using two separate blocks always seems to work correctly.
Also, The ca_cert points to the certificate file of the CA which has provided the certificate for the RADIUS
server. This file should contain certificates for the whole certification chain, up to the root. All certificates and
keys should be in PEM format.
The EAP-TTLS file is shown below for reference:
# EAP-TTLS configuration
Note: this example will set the outer identity to be the same as the real, inner identity of the user. It is possible
to set the outer identity to a different name (for instance to an opaque id), but for simplicity this is not shown
Also, most wpa_supplicant compilations will accept user key/certificate in one PFX (p12) file. If that is used, this
file should be pointed to by private_key and client_cert should be commented out.
Download the script (contained in http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip) to
enable you to start and stop the eduroam connection. Note that this script needs to be configured by assigning
correct values to the variables in the configuration section. The script kills possible wpa_supplicant processes
and DHCP clients for the particular interface. Then it starts wpa_supplicant and monitors its state with
wpa_cli. If no authentication takes place during the REAUTH_TIMEOUT period, wpa_supplicant is restarted.
After authentication, the DHCP client is started.
Note: This script has to be run with administrator's rights. This can be avoided by creating wrappers, which can
then be connected to panel buttons so the network can be started and stopped by a mouse click and providing
the administrator's password. To enable this, the following package can be downloaded and used:
This utility allows campus administrators to create a configuration script that can be distributed to the users.
The script contains all necessary certificates, scans the system for the needed tools and creates configuration
files, certificate files, sets up the main starting script and wrappers. A full description is beyond the scope of this
document, but can be found in the documentation of the package.
C.3 Intel PROSet/Wireless supplicant
This supplicant (shipped with Intel Centrino chipsets) makes it very easy for an administrator to prepare and
distribute a pre-configured supplicant configuration.
C.3.1 Preparing the profile as an administrator
As an IdP administrator, first create a configuration for yourself in the supplicant. It is suggested that you use a
proper anonymous outer identity of "@realm" (your realm, with nothing left of the @ sign) as the "Roaming
Identity". Now, verify that the settings are correct by connecting to eduroam.
Then, in the main window of the supplicant, click on "Profiles...". In the Profiles window, select the newly
created eduroam entry and then press the "Export" button. You will be prompted for the destination folder of the
profile. The filename in this folder will be the name of the profile as it is shown in the Profiles window.
Note that the exported profile will be exported without your username and password, but with the anonymous
identity preserved, i.e. your own credentials are automatically safe from inadvertent leakage.
Distribute the generated file to your users.
C.3.2 Installing the profile as a user
A simple double-click will install the profile on the user's supplicant. When the user tries to connect for the first
time, he will be prompted for his own username and password.
Note that there will be no visual feedback at all after double-clicking on the profile file. A user might be tempted
to think that nothing happened and try to import the profile twice. In this case, an error message about the
duplicate profile will be displayed. We suggest to educate the users accordingly.
Appendix D eduroam along with commercial hotspot system
This chapter describes a sophisticated deployment of Wireless LAN that includes both eduroam access (as
service provider, not identity provider) and a commercial hotspot deployment that offers three distinct classes of
access and multiple billing models. The following access models are covered:
- Commercial web redirect login portal.
- Commercial WPA2-Enterprise secured access.
- WPA2-Enterprise access for institution staff (not eduroam-eligible).
- eduroam access for R&E users.
Every usage class is assigned a separate VLAN and allows isolation of users. Four SSIDs are in use, and are
named "ccrn-hotspot" (web redirect), "ccrn-wpa" (commercial WPA), a hidden SSID (staff access) and
The billing models for the commercial access allow:
- Online-time based billing.
- Time window based billing.
- Volume based billing.
This mixture of a commercial system and eduroam access can be applied to any operator who is not in the
Research and Education community. The commercial system generates revenue while offering eduroam is a
competitive advantage against other providers. Several deployments of eduroam in non-R&E locations have
shown that eduroam attracts students to these places and by that may generate extra revenue – pubs are a
prime example for this business model.
The following instructions demonstrate how to set up such a hotspot solution with a single hardware server,
switches, Access Points and pure Open Source Software. This is a real-life scenario deployed in the city of
Luxembourg at the "Centre Culturel de Rencontre Abbaye de Neumünster" (CCRN).
These instructions assumes that a server with at least two network interfaces is present, where eth0 connects to
the outside internet, and eth1 is free for use with the hotspot system. It uses IP addresses in the 10.10.0.0/8
range within the system. The instructions attempt to be distribution-neutral. However, users should note that
this example was installed on an openSUSE 10.2 Linux operating system, and distribution-specific information
may be present.
D.1 Installation Instructions
- Prepare a Linux server with a distribution of choice and install the following packages at a minimum:
vconfig -> provides the VLAN configuration tool vconfig (separate download required:
chillispot -> provides the web-redirect portal binary, chilli (version 1.1.0 is on openSUSE 10.2
iptables -> provides firewall manipulation tools iptables, ip6tables (version 1.3.6 is on openSUSE 10.2
apache2 -> provides the web server for the web-redirect portal httpd (version 2.2.3 is on openSUSE
10.2 installation media).
MySQL -> provides the datastore for user accounts mysql (version 5.0.26 is on openSUSE 10.2
apache2-mod-perl -> enables execution of perl CGIs (version 2.0.2 is on openSUSE 10.2 installation
php5 -> provides php (version 5.2.0 is on openSUSE 10.2 installation media).
phpmyprepaid -> provides user management web interface (separate download required:
http://sourceforge.net/projects/phpmyprepaid, in this deployment version 0.3.3 is in use).
freeradius -> provides the RADIUS server radiusd (version 1.1.3 is on openSUSE 10.2 installation
○ dhcp-server -> provides the DHCP server dhcpd (version 3.0.5 is on openSUSE 10.2 installation
- Ensure the following configurations are met:
Kernel: must support
IEEE 802.1q VLANs
tun/tap network interfaces
must have routing capabilities
Note: The openSUSE 10.2 kernel supports all of the above.
VLANs: add with
vconfig add eth1 10
vconfig add eth1 11
vconfig add eth1 12
vconfig add eth1 13
assign IP addresses to
eth1: ifconfig eth1 10.10.0.1 netmask 255.255.255.0 up
eth1.10: ifconfig eth1.10 10.10.10.1 netmask 255.255.255.0 up
eth1.11: ifconfig eth1.11 10.10.11.1 netmask 255.255.255.0 up
eth1.12: ifconfig eth1.12 10.10.12.1 netmask 255.255.255.0 up
Do NOT assign an IP address to eth1.13 but make sure the interface is running (ifconfig eth1.13 up)
Make sure routing is turned on (cat /proc/sys/net/ipv4/ip_forward must give the result "1").
INTIF is eth1.13
EXTIF is eth0
set uamsecret to an arbitrary value; the same value must be in CGI configuration below
RADIUS server is localhost; use the shared secret for localhost (typically testing123)
copy hotspotlogin.cgi into apache's cgi-bin store
copy dictionary.chillispot into /etc/raddb
modify ruleset to allow RADIUS traffic in INPUT chain from eth1
modify ruleset to allow DHCP requests in INPUT from eth1.10, eth1.11, eth1.12
MySQL: create database "radius" and user for access
make sure CGI support for perl is active
make sure PHP support is enabled
request a certificate from a well-known authority that includes the TLS Web Server Authentication
OID (for example, Thawte and Verisign include this OID)
SSL support on port TCP/443 is mandatory: install the server cert
install somewhere in apache2 document root
set database details in dbconnect.php
point browser at installation path and follow instructions
set up a "location" first, then billing models
It is not necessary to define Access Points
define DHCP ranges for subnets 10.10.10.1/24, 10.10.11.1/24, 10.10.12.1/24
don't bind on interfaces eth0, eth1 and eth1.13
use database "radius" on localhost as authentication source
$INCLUDE dictionary.chillispot into file dictionary
define a realm DEFAULT that points to the eduroam infrastructure
realms NULL and LOCAL have auth source LOCAL
tag incoming requests in "hints" file to match SSIDs and user auth sources
allow EAP passthrough for eduroam users
— install server cert for EAP sessions for own users (-wpa, -staff)
It is useful to put VLAN definitions, IP allocations, firewall ruleset application into an init script to automate theboot process, an example init script is provided at http://www.eduroam.org/downloads/docs/eduroamcookbook\-
3. Add dhcpd, mysql, apache2, freeradius, chilli (init script included) to default runlevel (init script from
above should have precedence); under SUSE, runlevels are manipulated with "insserv":
4. Attached for convenience
init script for VLANs, IP
init script for chilli daemon
chilli.conf (comments stripped)
dhcpd.conf (comments stripped)
modified iptables ruleset
/etc/raddb files (comments stripped)
sample Lancom AP config (shared secrets, IP info strippedI
Many operating systems support IEEE 802.1X and EAP authentication, but the user interfaces in supplicants differ significantly. For some supplicants, manually clicking through a series of GUI pages is the only option. This is sometimes tedious for end users.
If possible, an IdP administrator should prepare pre-configured packages which contain the necessary information to securely connect to eduroam:
- the SSID: "eduroam"
- the crypto setting: WPA2/AES
- the EAP type setting
- the CA that issued the eduroam IdP server's EAP server certificate
- the Common Name in the eduroam IdP server's EAP server certificate
The following sections describe a series of tools that can be used to create such auto-installers. The use of one these windows 10 drivers update is recommended, because it will likely have a positive effect on user uptake, and reduce helpdesk load.
PLEASE ADD TEXT
PLEASE ADD TEXT
PLEASE ADD TEXT
Devices that are compatible with eduroam
The following list is sorted alphabetically by vendors. The table notes which EAP methods are supported. Legend:
CAT - this device/EAP type combination is supported by eduroam CAT; can probably also be configured securely manually
Yes - the device can be configured securely manually for this EAP type
Deficient - the device lacks important security features, but workarounds exist which can make its use safe
Insecure - the device can be configured manually for this EAP type, but not all security parameters can be set up
No - device is known not to support IEEE 802.1X/EAP
? - Unknown
TPS - supported with Third-Party Software (possibly commercial)
Samsung Galaxy S2
Huawei Sonic u8650
|Apple||Mac OS X||10.7+||CAT||CAT||CAT||Yes||No||?||Yes|
|Apple||Mac OS X||10.4-10.6||Yes||Yes||Yes||Yes||No||?||Yes|
|Microsoft||Windows||8 / 8.1||CAT||CAT||CAT||CAT||CAT||?|
 Installation and pinpointing of CA possible; verification of expected server name (CN) not possible. A secure configuration is only possible if the Identity Provider deploys a private CA which issues exclusively server certificates for his own eduroam EAP servers. All other Identity Provider deployments are INSECURE.
 Version 1.0 or higher required
 Verifying that the server is signed by the proper CA is not possible; this means users will not be able to detect fake hotspots and might send their username/password to an unauthorised third party.
 Only with 10.6.x (Snow Leopard) and later does OSX allow the configuration of of CA/server trust settings (Pinning 802.1X to specific CA and RADIUS server CommonName)
Reporting a new device
Please let us know in the "Comments" field what device you have, and what EAP method(s) you have found working. We will update the list periodically.
PLEASE ADD TEXT
There are use cases for securing access to a wired port in the same way as to a wireless Access Point. This use case is often not primarily intended for roaming though, as it is much more difficult for an incoming guest to locate a physical port in a building than it is to pick up a wireless broadcast signal from an access point. Much rather, an IdP who has already turned his users into eduroam users might want to benefit from the existing configuration in his end-users' devices to secure dormitories and similar locations, where finding the attachment point is less of an issue.
Connecting wired infrastructure to eduroam
The eduroam consortium is media-agnostic and welcomes wired eduroam. Wired eduroam works a lot like wireless - instead of an Access Point with 802.1X support, an eduroam SP needs a wired switch with that same 802.1X support. The SP configures it to authenticate the physical port users to the same RADIUS server that his access points do, too (i.e. the switch becomes a RADIUS client for the eduroam SP RADIUS server) - and that's all, the switch is then part of the eduroam infrastructure proper without further changes needed.
End user experience
Experience for end users is somwhat grim compared to wireless.The IEEE 802.1X revisions of 2001 and 2004 lack some of the features eduroam users are used to in the wireless world where IEEE 802.11 augments the missing features of IEEE 802.1X. The following text describes the shortcomings of versions prior to IEEE 802.1X-2010, because as of this writing, no single switch and/or supplicant is known which would support the new features of IEEE 802.1X-2010. Deployers of wired eduroam should be aware of the following differences for end users.
When connecting to eduroam, users are usually made aware that the network they are connecting to is an eduroam network - simply by observing the SSID "eduroam" occuring on their computing device. In wired IEEE 802.1X networks, the concept of SSIDs does not exist. The user needs to plug in his device and try to connect in the usual way (using his supplicant, the usual EAP configuration and his eduroam credentials) - which will work on the configured eduroam ports, but not at any other network ports. eduroam Service Providers are advised to give clear indication which ports in a building are eduroam ports and which are not. One means to achieve this is by putting an eduroam logo besides the ports in question, or announcing the existence of eduroam on a building's wired ports on a signpost near the entrance to the building.
Improvements with IEEE 802.1X-2010
With IEEE 802.1X-2010, so-called "Network Announcements" are supported. After plugging in the device, the user's supplicant is presented with a list of strings which identify the network. This feature provides the equivalent of SSIDs from wireless networks and can help end users identify usable wired network plugs.
Support for multiple configurations
Computing devices typically allow multiple independent configurations for the wireless network interface; the configurations are usually seperated by the SSID they belong to. That way, users can configure their eduroam credentials for the "eduroam" SSID, and can have any number of other configurations for other networks at work or at home. In wired IEEE 802.1X, supplicants typically only allow "the" IEEE 802.1X configuration (likely due to the missing network indication as described above, which makes it impossible for the supplicant to determine which configuration is to be used for the wired connection). Users who have a need for multiple wired IEEE 802.1X configurations will probably be dissatisfied with that situation.
Improvements with IEEE 802.1X-2010
With IEEE 802.1X-2010's network announcements, it becomes easy for supplicants to distinguish between different configurations. It is expected that, once IEEE 802.1X-2010 support on the attachment points becomes common, supplicant implementations will follow suit and enable storing and choosing different configurations per network identifier. This is implementation-specific per supplicant though, and support for this can and will vary.
Encryption of payload
In IEEE 802.11 enterprise wireless, the end-user's network payload data is encrypted between his device and the Access Point. This happens automatically when using EAP and RADIUS, and is also highly desirable for the user's security because it prevents snooping of his private data by bystanders in the broadcast domain of the access point.
In wired networks, user payload is not broadcast, but is instead directed on a copper or fibre wire directly to the switch. This makes encryption of the payload a less pressing problem. Consequently, IEEE 802.1X does not foresee encryption of user payload data.
This is not particularly alarming because of the point-to-point nature of wires, but is a difference to the wireless use case deployers of IEEE 802.1X should be aware of.
Improvements with IEEE 802.1X-2010
IEEE 802.1X-2010 includes support for a previously standalone feature called "MACsec" (previously IEEE 802.1AE). This feature allows to encrypt payload data on the wire between the end-user device and the switch. Implementations of supplicants and switches supporting this feature have not yet been observed in the wild though.