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.
Eduroam stands for EDUcation ROAMing. It offers users from participating academic institutions secure Internet access at any other eduroam-enabled institution. 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:
In order to transport the authentication request of a user from the Service Provider to his Identity Provider and the authentication response back, a hierarchical 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 central national RADIUS server, which in turn is connected to a European (or global) RADIUS server. 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=country code top-level domain), the RADIUS servers can use this information to route the request to the appropriate next hop in the hierarchy 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). Using the appropriate EAP-method either a secure tunnel will be established from the user's computer to their IdP through which the actual authentication information (username/password etc.) will be carried (EAP-TTLS or PEAP), or mutual authentication by public X.509 certificates (which is not vulnerable to eavesdropping) will be used (EAP-TLS).
RADIUS transports the user's name in an attribute User-Name, which is visible in cleartext. It also transports the EAP payload, which is encrypted and not visible to intermediate servers, only to the IdP server. In order to ensure privacy, it might be desirable not to put the real username in the RADIUS User-Name attribute (this attribute is the "outer" identity). Instead, it might be preferred to put @realm in this attribute (nothing left of the @ - this is the IETF-suggested format). The realm part still must be the correct one as it is used to route the request to the respective home server. Once the IdP server decrypts the TLS tunnel in the EAP payload, it gets the real user name - the "inner" identity.
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:
The complete Directive can be found at EUR-Lex1.
Figure 2.1: Layers of the eduroam RADIUS hierarchy NEED TO (RE)CREATE DIAGRAM ??
The confederation top-level RADIUS Servers, at the time of writing, are located in the Netherlands and Denmark for the European confederation, and Australia and Hong Kong for the Asian and Pacific region. Each have a list of connected country domains (.nl, .dk, .au, .cn etc.) serving the appropriate National Roaming Operators (NROs). They accept requests for federation domains for which they are authoritative, and subsequently forward them to the associated RADIUS server for that federation (and transport the result of the authentication request back). Requests for federation domains they are not responsible for are forwarded to the proper confederation TLR.
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.
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.