Technical Overview

As described in the /introduction the eduroam project is "A worldwide federation of RADIUS servers facilitating network access for roaming academic affiliates using IEEE 802.1X as the vehicle. eduroam's use of 802.1X in concert with RADIUS means the network is built around well understood, established, and easy to manage standards which are often already deployed within the network infrastructure of educational institutions."

The goal of this documentation is to give a more complete technical explanation of the way the various components of eduroam fit together to provide a seamless authentication and user experience for users of the eduroam network.

Fundamentally eduroam relies on standard wireless authentication tools including 802.11, 802.1X, and RADIUS.  When a user associates to the eduroam SSID (or any 802.1X protected SSID or wired connection for that matter) the client computer is not able to pass any traffic other than 802.1x until granted further access by the access-point (or switch in the wired case).  The client software on the client computer is called the supplicant (though you may refer to the client computer itself as the supplicant as well); The network hardware to which the computer is associated or physically connect is called the authenticator. and the authenticator directs communication with the authentication infrastructure, here referred to as the "authentication server".  The authentication server itself may actually be multiple servers and/or authentication components such as LDAP, ActiveDirectory (or Samba acting as a Primary Domain Controller and interacting with LDAP behind the scenes).  The basic authentication scheme is described below (fig. 1)

802.1x over 802.11 (High-Level overview)
Figure 1: Basic Authentication with 802.1x over 802.11

The 802.1X authentication process is more complicated than simply "exchanging credentials" as alluded to above.  The actual exchange between the supplicant and authenticator involves an Extensible Authentication Protocol (EAP) conversation.  The EAP request is forwarded to the authentication server, generally in the form of a RADIUS request.  The actual security of EAP comes from the use of SSL with one of the many EAP sub-protocols, the most common of which are listed here: 

  • EAP-TLS - requiring both client and server SSL/TLS certificates
  • PEAP - requiring only a server certificate but also an ActiveDirectory or Samba PDC authentication server.  This is the default for Windows supplicants and requires no external software, and is also supported natively by Apple's OSX, and some Linux supplicants
  • EAP-TTLS - this sub-protocol also requires only a server certificate and is supported natively by Apple's OSX, iPhone OS, Windows, and most Linux supplicants. For a detailed comparison between common EAP methods see the EAP method comparison matrix.

During authentication via of any of the EAP protocols described above, an SSL tunnel is created between the supplicant and the authentication server, inside of which the actual credentials are exchanged.  This protects the user from a compromise of their credentials by any third party during authentication.  In the case of RADIUS, the SSL tunnel is constructed by the use of RADIUS attributes carrying the encrypted data.

802.1x over 802.11 (EAP Expansion)
Figure 2: Authentication with 802.1x over 802.11 with EAP details

An additional option that users may configure their supplicant to use is the so-called "outer-identity" which is passed outside of the encrypted tunnel to the authenticator and authentication servers. By default this identity is simply their username, or more often in the case of eduroam username@realm (such as joe [at] where "joe" is the username or "netid" and "" is the so-called realm). Since, as we will see in the next sections, only the realm is used for routing of the request users may optionally set their outer-identity to be anything they like as long as the realm is their actual realm, and their inner-identity is configured correctly. For purposes of etiquette it is expected that if the outer-identity is not set to their inner-identity then it is set to anonymous [at] The ability to properly anonymize the authentication sequence means that intermediate authentication servers (which are very important in the next section) cannot observe and track authentication attempts of eduroam-ers using the system.

802.1x over 802.11 (EAP Expansion with Anonymous outer-identity)
Figure 3: Authentication with 802.1x over 802.11 with an anonymous outer-identity

Routing in eduroam

As discussed to in the prior paragraph, the local authentication server may not be the final destination for a given authentication request. If the realm of the user is not the local realm then the request may be forwarded to a remote RADIUS server which is authoritative for that realm, or simply knows where the request must go to be answered authoritatively. RADIUS supports this forwarding in its proxy mode as seen below.  When a RADIUS request is forwarded the SSL tunnel protecting the privacy of the requestor is propagated throughout the RADIUS infrastructure, thus preventing administrators not responsible for the handling of the request from intercepting and/or manipulating the contents of the EAP exchange.  The only information an intermediate RADIUS server has is the outer-identity of the requestor, the state of the EAP request (accept-request, access-challenge, access-accept, or access-reject) and any RADIUS attributes passed outside of the tunnel.

802.1x over 802.11 (EAP Expansion with RADIUS proxying)
Figure 4: Authentication with 802.1x over 802.11 with RADIUS proxying

eduroam-US is authoritative for the .edu TLD, and handles routing to other TLDs including those handled by eduroam in Europe (for all European members of the federation), eduroam in the Asia-Pacific region (including Australia, China, Hong Kong, Japan, New Zealand, and Taiwan), and Canada.  Within the US the eduroam-US Top-Level RADIUS Server (TLRS) handles routing to .edu member institutions.

eduroam routing
Figure 5: eduroam-US routing




  • Supplicant - The client software on an computer associating to an 802.1x secured network. Often the computer itself (or even the user) is referred to as the supplicant but generally without ambiguity.
  • Authenticator - The authenticator is the piece of network equipment to which a supplicant is connected and attempting to perform an 802.1x authentication. This may be a wireless access point, a switch, or another variety of hardware made for 802.1x. The authenticator will only pass 802.1x traffic to an authentication server until such point as the user has been authenticated and granted access to the network.
  • Authentication Server - an authentication server is a server or network appliance which is able to accept 802.1x authentication requests and respond appropriately based on credentials passed it it.  It may be a server running a RADIUS server and a directory service or simply know how to forward requests to another server which is itself connected to LDAP/RADIUS.  This abstraction is the strength of the 802.1x architecture.