spaces.at.internet2.edu has been upgraded to Confluence 6.15.10. If you have any questions and/or concerns, please contact us at techsupport@internet2.edu
Child pages
  • 2. Technical Overview
Skip to end of metadata
Go to start of metadata

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 in the figure below.



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
  • EAP-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, and most Linux supplicants. To use EAP-TTLS in Windows requires an external supplicant such as Secure-W2.

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.



Figure 2: Authentication with 802.1x over 802.11 with EAP details


An additional option that supplicant configuration uses 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 the username, or more often in the case of eduroam <em>username@realm</em> (such as <em>joe@example.edu</em> where "joe" is the username or "netid" and "example.com" is the so-called <em>realm</em>). 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@realm.edu. 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.



Figure 3: Authentication with 802.1x over 802.11 with an anonymous outer-identity

Routing in eduroam

As discussed above, 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.

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 eduroam in Canada</a>. Within the US the eduroam-US Top-Level RADIUS Server (TLRS) handles routing to .edu members.



Figure 5: eduroam-US routing

References

EAP is defined in RFC 2284

EAP Method Feature Comparison

The following is a comparison of the most common EAP methods deployed in the eduroam-US ecosystem.

EAP-TLS

Native Supplicant Support: Windows (XP, Vista, 7), Mac OS X, Linux, iOS (iPhone, iPod Touch, iPad), Android (v1.6+)

Pros

  • Validates client as well as infrastructure
  • Reduced risk of being Phished
  • Blocking user access is via certificate revocation

Cons:

  • PKI infrastructure is required
  • Users must configure supplicant to use certificate*
  • Identity may be exposed in TLS exchange depending on contents of certificate

EAP-TTLS

Native Supplicant Support: Windows (8, 10), Mac OS X, Linux, iOS (iPhone, iPod Touch, iPad), Android (v1.6+)

Pros

  • None

Cons

  • No native supplicant support on Microsoft Windows XP or 7
  • Potential for Man-in-the-Middle attacks

EAP-PEAP

Native Supplicant Support: Windows (XP, Vista, 7), Mac OS X, Linux, iOS (iPhone, iPod Touch, iPad), Android (v1.6+)

Pros

Works on many platforms

Cons

  • Potential for Man-in-the-Middle attacks
  • Identity may be exposed during Phase-1 of exchange
  • This may be mitigated using configuration tools such as the iPhone Configuration Utility for iOS devices (iPhone, iPod Touch, iPad), Active Directory for Windows devices (XP, Vista), etc.
  • Man-in-the-Middle attacks may be perpetrated against any SSL/TLS protected service in which the used server certificates are not validated. This validation comes from the signing Certificate Authority's (CA) certificate being in the root-store of a given device. For common CAs the certificate is often bundled with the operating system. If an institution opts to use either a CA which is not shipped with common OSs or their own CA which is not an intermediate CA for a well-known CA, then they must take the responsibility of distributing their CA certificate, and installing it correctly on end-user devices. The same configuration tools discussed to mitigate the complexity of configuring TLS certificates for end-user devices may sometimes be used to install necessary CA certs for those devices, even while using EAP methods other than EAP-TLS (or PEAP-TLS).


Glossary

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.

  • No labels