RFC 7593
The eduroam Architecture for Network Roaming
RFC 7593: The eduroam Architecture for Network Roaming 🎀
- RFC number: 7593
- Title: The eduroam Architecture for Network Roaming
- Authors: K. Wierenga (Cisco Systems), S. Winter (RESTENA), T. Wolniewicz (Nicolaus Copernicus University)
- Category: Informational
- Stream: Independent Submission
- ISSN: 2070-1721
- Date: September 2015
- Obsoletes / Updates: neither is listed in the title block 🫶
Abstract ✨
okay so this doc is all about the architecture of eduroam, which is the service for federated (wireless) network access in academia 🎓. the combo of IEEE 802.1X, EAP, and RADIUS is what makes it secure, scalable, and easy to deploy for roaming access 🔐. eduroam has been running successfully in education for the last decade, so it can totally serve as an example for other sectors, and that's literally why this doc exists 💖. it walks through the first architectural choices and the standards picked, plus the changes that operational experience made necessary 🌸.
Status of This Memo 🧚
this document is not an Internet Standards Track specification. it's published just for informational purposes 📚.
it's a contribution to the RFC Series and it's independent of any other RFC stream. the RFC Editor chose to publish it at their discretion and makes no statement about how valuable it is for implementation or deployment. documents approved by the RFC Editor are not a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for the details 💅.
for info on the current status of this document, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7593 🔗.
Copyright Notice 🌈
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the publication date. please read these carefully, because they spell out your rights and restrictions for this document 📜.
Table of Contents 💜
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Solutions That Were Considered . . . . . . . . . . . . . 5
2. Classic Architecture . . . . . . . . . . . . . . . . . . . . 6
2.1. Authentication . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. EAP . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Federation Trust Fabric . . . . . . . . . . . . . . . . . 8
2.2.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . 9
3. Issues with Initial Trust Fabric . . . . . . . . . . . . . . 11
3.1. Server Failure Handling . . . . . . . . . . . . . . . . . 12
3.2. No Signaling of Error Conditions . . . . . . . . . . . . 13
3.3. Routing Table Complexity . . . . . . . . . . . . . . . . 14
3.4. UDP Issues . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Insufficient Payload Encryption and EAP Server Validation 16
4. New Trust Fabric . . . . . . . . . . . . . . . . . . . . . . 17
4.1. RADIUS with TLS . . . . . . . . . . . . . . . . . . . . . 18
4.2. Dynamic Discovery . . . . . . . . . . . . . . . . . . . . 19
4.2.1. Discovery of Responsible Server . . . . . . . . . . . 19
4.2.2. Verifying Server Authorization . . . . . . . . . . . 20
4.2.3. Operational Experience . . . . . . . . . . . . . . . 21
4.2.4. Possible Alternatives . . . . . . . . . . . . . . . . 21
5. Abuse Prevention and Incident Handling . . . . . . . . . . . 22
5.1. Incident Handling . . . . . . . . . . . . . . . . . . . . 22
5.1.1. Blocking Users on the SP Side . . . . . . . . . . . . 23
5.1.2. Blocking Users on the IdP Side . . . . . . . . . . . 24
5.1.3. Communicating Account Blocking to the End User . . . 25
5.2. Operator Name . . . . . . . . . . . . . . . . . . . . . . 26
5.3. Chargeable User Identity . . . . . . . . . . . . . . . . 27
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28
6.1. Collusion of Service Providers . . . . . . . . . . . . . 28
6.2. Exposing User Credentials . . . . . . . . . . . . . . . . 28
6.3. Track Location of Users . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7.1. Man-in-the-Middle and Tunneling Attacks . . . . . . . . . 29
7.1.1. Verification of Server Name Not Supported . . . . . . 29
7.1.2. Neither Specification of CA nor Server Name Checks
during Bootstrap . . . . . . . . . . . . . . . . . . 29
7.1.3. User Does Not Configure CA or Server Name Checks . . 30
7.1.4. Tunneling Authentication Traffic to Obfuscate User
Origin . . . . . . . . . . . . . . . . . . . . . . . 30
7.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 31
7.2.1. Intentional DoS by Malign Individuals . . . . . . . . 31
7.2.2. DoS as a Side-Effect of Expired Credentials . . . . . 32
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . 34
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 371. Introduction 🦋
okay so back in 2002, the European Research and Education community set out to build a network roaming service for students and employees in academia [eduroam-start]. fast forward over 10 years and it has grown to more than 10,000 service locations, serving millions of users on every continent except Antarctica 🌍✨.
this memo is here to explain the design thinking behind eduroam, and to record the operational experience and the changes that came out of it. those changes led to IETF specifications like RADIUS over TCP [RFC6613] and RADIUS with TLS [RFC6614], and they also encouraged other uses of RADIUS, like Application Bridging for Federated Access Beyond web (ABFAB) [ABFAB-ARCH] 🧠. eduroam itself is limited to academia, but the eduroam architecture can easily be reused in other environments 💅.
the memo goes in three steps. first it describes the original eduroam architecture [eduroam-homepage]. then it covers the operational problems that popped up once eduroam got rolled out widely. last, it discusses the enhancements that tackle those issues 🔥.
1.1. Terminology 📖
this document uses the identity management and privacy terminology from [RFC6973]. specifically, it uses the terms "Identity Provider", "Service Provider", and "identity management" 🪪.
1.2. Notational Conventions 🎀
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [RFC2119] ⭐.
Note: the policy that eduroam participants sign up to also states the requirements for participation using RFC 2119 language.
1.3. Design Goals 💖
the guiding design ideas for eduroam were these:
- Unique identification of users at the edge of the network 🆔
the access Service Provider (SP) needs to be able to tell whether a user is allowed to use the network resources. and if there's any abuse, there's a requirement to identify the user uniquely, which needs the cooperation of the user's Identity Provider (IdP) operator 🕵️♀️.
- Enable (trusted) guest use 🫶
to make roaming work, users from participating institutions should be able to get seamless access to the networks of other institutions 🧳.
Note: traffic separation between guest users and normal users is possible (for example, through the use of VLANs), and it's indeed widely used in eduroam 🚧.
- Scalable 📈
the infrastructure should scale to a large number of users and organizations without needing a lot of coordination and other administrative procedures (possibly with the exception of an initial setup). specifically, a user visiting another organization should not have to go through an administrative process 🙅♀️.
- Easy to install and use 🧸
it should be easy for both organizations and users to join the roaming infrastructure, otherwise it may hold back wide-scale adoption. in particular, there should be no client installation (or it should be easy), and only one-time configuration 🌷.
- Secure 🔐
an important design rule was that there needs to be a security association between the end user and their Identity Provider, which kills off the possibility of credential theft. the minimum security requirements are set out in the eduroam policy and can change over time. as an extra layer against user mistakes and negligence, participating Identity Providers should be able to add their own requirements for the quality of authentication of their own users, without the whole infrastructure having to implement those same requirements 🛡️.
- Privacy preserving 🙈
the system should provide user anonymization, meaning there's a possibility to hide the user's identity from any third parties, including Service Providers 🫥.
- Standards based 📚
with many thousands of organizations participating, it's obvious that equipment from different vendors should be usable. that's why the infrastructure is built on open standards 🧡.
1.4. Solutions That Were Considered 🧪
three architectures were trialed: one based on VPN technology (deemed secure but not scalable), one based on web captive portals (scalable but not secure), and one based on IEEE 802.1X. the 802.1X one is the basis of what is now the eduroam architecture. you can find an overview of the candidate architectures and how they compare in [nrenroaming-select] 👀.
the chosen architecture is based on:
- IEEE 802.1X [IEEE.802.1X] as the port-based authentication framework,
- EAP [RFC3748] for integrity-protected and confidential transport of credentials, and
- a RADIUS [RFC2865] hierarchy as the trust fabric. 👑
- Classic Architecture 🎀
okay so bestie, this is where the architecture gets its whole personality 🧚 eduroam (and federations like it) basically run on two kinds of direct trust relations, plus one indirect one that kinda holds the whole thing together 💅 The first is between an end user and the IdP (the identity provider run by the user's home organization). The second is between the IdP and the SP (in eduroam, that's the operator of the network at the place you're visiting). In eduroam, the user-to-IdP trust is set up through mutual authentication 🔐 and the IdPs and the SP build their trust using a RADIUS hierarchy 🌸
Put those two direct trusts together and you get the transitive trust that makes the SP trust the user to use its network resources. It's giving chain of friendship, literally 🫶
2.1. Authentication
Authentication in eduroam is done by combining IEEE 802.1X [IEEE.802.1X] with EAP [RFC4372]. The EAP part gets carried over RADIUS for guest access, so see Section 2.2 for that bit ✨
2.1.1. IEEE 802.1X
Okay, so 802.1X is the framework for port-based network access, and it's how organizations offering network access (the SPs) make sure only authorized visiting (and local) eduroam users get in 🚪 Here's the flow: the user's supplicant (or really, the user's device doing the talking) sends an access request to the authenticator at the SP (a Wi-Fi Access Point or a switch). The authenticator forwards that request to the SP's authentication server, which then proxies it through the RADIUS hierarchy to the authentication server of the user's home organization, the IdP 🦋
Note: The security of the connections between local wireless infrastructure and local RADIUS servers is part of each SP's local network, so it is out of scope for this document. For completeness, security between access points and their controllers is vendor specific, and security between controllers (or standalone access points) and local RADIUS servers is based on the typical RADIUS shared secret mechanism 🔑
In order for users to know eduroam is available, an SP that offers wireless network access MUST broadcast the Service Set Identifier (SSID) 'eduroam', unless that clashes with the SSID of another eduroam SP. In that case, an SSID starting with "eduroam-" MAY be used. The catch with the latter is that clients will not automatically connect to that SSID, so you lose the seamless connection experience 😭
Note: A direct implication of the common eduroam SSID is that users cannot tell apart a connection to their home network and a guest network at another eduroam institution. (IEEE 802.11-2012 does have the so-called "Interworking" to make that distinction, but it is not widely implemented yet.) Furthermore, without proper server verification, users may even get tricked into joining a rogue eduroam network 💀 Therefore, users should be made aware that they should not assume data confidentiality in the eduroam infrastructure 🙈
To protect over-the-air confidentiality of user data, IEEE 802.11 wireless networks of eduroam SPs MUST deploy WPA2+AES, and they MAY additionally support Wi-Fi Protected Access with the Temporal Key Integrity Protocol (WPA/TKIP) as a courtesy to users of legacy hardware 💜
2.1.2. EAP
The Extensible Authentication Protocol (EAP) [RFC4372] does two jobs, and both are iconic 👑 First, a properly chosen EAP method lets the user credentials travel to the home organization with integrity protection and confidentiality. Second, every RADIUS server transparently proxies access requests no matter which EAP method is inside the RADIUS packet, so the choice of EAP method is between the user's 'home' organization and the user themselves. In principle, any authentication form that can be carried inside EAP can be used in eduroam, as long as it adheres to the minimal requirements set out in the eduroam Policy Service Definition [eduroam-service-definition] 🌈
+-----+
/ \
/ \
/ \
/ \
,----------\ | | ,---------\
| SP | | eduroam | | IdP |
| +----+ trust fabric +---+ |
`------+---' | | '-----+---'
| | | |
| \ / |
| \ / |
| \ / |
| \ / |
+----+ +-----+ +----+
| |
| |
+---+--+ +--+---+
| | | |
+-+------+-+ ___________________________ | |
| | O__________________________ ) +------+
+----------+
Host (supplicant) EAP tunnel Authentication server
Figure 1: Tunneled EAPProxying of access requests is based on the outer identity in the EAP-Message. Those outer identities MUST be a valid user identifier with a mandatory realm as per [RFC7542], i.e., be of the form something@realm or just @realm, where the realm part is the domain name of the institution that the IdP belongs to 🗺️ To keep credentials protected, participating organizations MUST deploy EAP methods that provide mutual authentication. For EAP methods that support outer identity, anonymous outer identities are RECOMMENDED. The most commonly used ones in eduroam are the tunneled EAP methods, which first create a server-authenticated TLS [RFC5246] tunnel and then send the user credentials through it 🦋 As Figure 1 shows, a tunneled EAP method creates a direct logical connection between the supplicant and the authentication server, even though the actual traffic flows through the RADIUS hierarchy ✨
2.2. Federation Trust Fabric
The eduroam federation trust fabric is built on RADIUS, and RADIUS trust is based on shared secrets between RADIUS peers 🔐 In eduroam, any RADIUS message from a trusted peer is implicitly assumed to come from a member of the roaming consortium 💖
Note: See also the security considerations for a discussion on RADIUS security that motivated the work on RADIUS with TLS [RFC6614] 🙈
2.2.1. RADIUS
The eduroam trust fabric is a proxy hierarchy of RADIUS servers (organizational, national, global), loosely based on the DNS hierarchy 🌸 Typically, an organizational RADIUS server agrees on a shared secret with a national server, and the national server agrees on a shared secret with the root server. Access requests get routed through a chain of RADIUS proxies towards the user's Identity Provider, and the access accept (or reject) follows the same path back ✨
Note: In some circumstances there are more levels of RADIUS servers (for example, regional or continental servers), but that doesn't change the general model. Also, the packet exchange described below actually takes several round-trips in reality 🧚
+-------+
| |
| . |
| |
+---+---+
/ | \
+----------------/ | \---------------------+
| | |
| | |
| | |
+--+---+ +--+--+ +----+---+
| | | | | |
| .edu | . . . | .nl | . . . | .ac.uk |
| | | | | |
+--+---+ +--+--+ +----+---+
/ | \ | \ |
/ | \ | \ |
/ | \ | \ |
+-----+ | +-----+ | +------+ |
| | | | | |
| | | | | |
+---+---+ +----+---+ +----+---+ +--+---+ +-----+----+ +-----+-----+
| | | | | | | | | | | |
|utk.edu| |utah.edu| |case.edu| |hva.nl| |surfnet.nl| |soton.ac.uk|
| | | | | | | | | | | |
+----+--+ +--------+ +--------+ +------+ +----+-----+ +-----------+
| |
| |
+--+--+ +--+--+
| | | |
+-+-----+-+ | |
| | +-----+
+---------+
user: paul@surfnet.nl surfnet.nl Authentication server
Figure 2: eduroam RADIUS HierarchyRouting of access requests to the home IdP is based on the realm part of the outer identity. For example (as in Figure 2), when user paul@surfnet.nl of SURFnet (surfnet.nl) tries to get wireless network access at the University of Tennessee at Knoxville (utk.edu), the following happens 🧳
- Paul's supplicant transmits an EAP access request to the Access Point (Authenticator) at UTK with outer identity of anonymous@surfnet.nl.
- The Access Point forwards the EAP message to its Authentication Server (the UTK RADIUS server).
- The UTK RADIUS server checks the realm to see if it is a local realm. Since it isn't, the request is proxied to the .edu RADIUS server.
- The .edu RADIUS server verifies the realm. Since it is not in a .edu subdomain, it proxies the request to the root server.
- The root RADIUS server proxies the request to the .nl RADIUS server, since the ".nl" domain is known to the root server.
- The .nl RADIUS server proxies the request to the surfnet.nl server, since it knows the SURFnet server.
- The surfnet.nl RADIUS server decapsulates the EAP message and verifies the user credentials, since the user is known to SURFnet.
- The surfnet.nl RADIUS server informs the utk.edu server of the outcome of the authentication request (Access-Accept or Access-Reject) by proxying the outcome back through the RADIUS hierarchy in reverse order.
- The UTK RADIUS server instructs the UTK Access Point to either accept or reject access based on the outcome of the authentication.
Note: The depiction of the root RADIUS server is a simplification. In reality, the root server is distributed over three continents, and each maintains a list of the top-level realms that a specific root server is responsible for. This also means that, for intercontinental roaming, there is an extra proxy step from one root server to the other. Also, the physical distribution of nodes doesn't need to mirror the logical distribution of nodes. This helps with stability and scalability 🌈
- Issues with Initial Trust Fabric ✨
okay so bestie, the hierarchical RADIUS setup from the last part has been running eduroam for a whole decade 🎀, and honestly it's been iconic 👑. BUT the exponential growth of authentications is expected to lead to, and in some cases has already led to, performance and operations bottlenecks on the aggregation proxies 😭. The next sections spill the tea on some of the shortcomings and the fixes for them 💅.
3.1. Server Failure Handling 💀
ngl this one is a whole mood. In eduroam, authentication requests for roaming users get statically routed through preconfigured proxies 🧚. The number of proxies varies: in a national roaming case it's typically 1 or 2 (some countries deploy regional proxies, which get aggregated by a national proxy); in international roaming, 3 or 4 proxy servers are typically involved (the number may be higher along some routes) 🌈.
[RFC2865] does not define a failover algorithm, so the failure of a server has to be deduced from the absence of a reply 🙈. Operational experience has shown that this is giving detrimental effects on both the infrastructure and the end-user experience:
- Authentication failure: the first user whose authentication path runs along a newly failed server will experience a long delay and possibly a timeout 😭
- Wrongly deduced states: since the proxy chain is longer than one hop, a failure further along the authentication path looks exactly the same as a failure in the next hop 🤡
- Inability to determine recovery of a server: only a "live" authentication request sent to a server that is believed to be inoperable can reveal that the server is back in working order again. This issue has been resolved with [RFC5997] ✨
The second point can have significant impact on the operational state of the system in a worst-case scenario, and it's giving chaos 🔥: imagine one realm's home server being inoperable. A user from that realm tries to roam internationally and attempts to authenticate. The RADIUS server at the hotspot location may assume its own national proxy is down because it does not reply. That national server, being perfectly alive, in turn will assume that the international aggregation proxy is down, which in turn will believe the home country national proxy server is down. None of these assumptions are true 💀. Worse yet: in case of failover to a back-up next-hop RADIUS server, that server also gets marked as defunct, since through it no reply will be received from the defunct home server either. Within a short time, all redundant aggregation proxies might be considered defunct by their preceding hop 😭🫶.
In the absence of proper next-hop state derivation, some interesting concepts have been introduced by eduroam participants. The most noteworthy is a failover logic that considers up/down states not per next-hop RADIUS peer, but instead per realm (See [dead-realm] for details) 🦋. Recently, implementations of [RFC5997] and cautious failover parameters make false "downs" unlikely to happen, as long as every hop implements [RFC5997] 🍓. In that case, dead realm detection mainly serves to prevent proxying large numbers of requests to known dead realms 💖.
3.2. No Signaling of Error Conditions 🙈
The RADIUS protocol lacks signaling of error conditions, and the IEEE 802.1X standard does not allow conveying extended failure reasons to the end user's device. For eduroam, this creates two issues 💜:
- The home server may have an operational problem. For example, its authentication decisions may depend on an external data source such as a SQL server or Microsoft's Active Directory, and that external data source is unavailable. If the RADIUS interface is still functional, there are two options for how to reply to an Access-Request that can't be serviced due to such error conditions:
- Do Not Reply: The inability to reach a conclusion can be handled by not replying to the request. The upside is that the end user's software doesn't come to wrong conclusions and won't give unhelpful hints such as "maybe your password is wrong" 🌸. The downside is that intermediate proxies may come to wrong conclusions because their downstream RADIUS server isn't responding 😬.
- Reply with Reject: In this option, the inability to reach a conclusion is treated like an authentication failure. The upside is that intermediate proxies maintain a correct view on the reachability state of their RADIUS peer ✅. The downside is that EAP supplicants on end-user devices often react with either false advice ("your password is wrong") or even trigger permanent configuration changes. For example, the Windows built-in supplicant will delete the credential set from its registry, prompting the user for their password on the next connection attempt 💀. The latter case of Windows is a source of significant help-desk activity, since users may have forgotten their password after initially storing it but are suddenly prompted again 😭.
There have been epic discussions in the eduroam community as well as in the IETF RADEXT Working Group as to which of the two approaches is more appropriate, but they were not conclusive 🍿.
Similar considerations apply when an intermediate proxy does not receive a reply from a downstream RADIUS server. The proxy may either choose not to reply to the original request, leading to retries and its upstream peers coming to wrong conclusions about its own availability; or, it may decide to reply with Access-Reject to indicate its own liveliness, but again with implications for the end user 🫠.
The ability to send Status-Server watchdog requests is only of use after the fact, in case a downstream server doesn't reply (or hasn't been contacted in a long while, so that its previous working state is stale) ⏰. The active link-state monitoring of the TCP connection with, e.g., RADIUS/TLS (see Section 4.1) gives a clearer indication of whether there is an alive RADIUS peer, but it does not solve the defunct back-end problem 🔌. An explicit ability to send Error-Replies, on the RADIUS level (for other RADIUS peer information) and EAP level (for end-user supplicant information), would alleviate these problems, but it is currently not available 🥺.
3.3. Routing Table Complexity 🗺️
The aggregation of RADIUS requests based on the structure of the user's realm implies that realms ending with the same top-level domain are routed to the same server, i.e., to a common administrative domain 🎀. While this is true for country code Top-Level Domains (ccTLDs), which map into national eduroam federations, it is not true for realms residing in generic Top-Level Domains (gTLDs). Realms in gTLDs were historically discouraged because the automatic mapping "realm ending" -> "eduroam federation's server" could not be applied. However, with growing demand from eduroam realm administrators, it became necessary to create exception entries in the forwarding rules; such realms need to be mapped on a realm-by-realm basis to their eduroam federations. Example: "kit.edu" (Karlsruher Institut fuer Technologie) needs to be routed to the German federation server, whereas "iu.edu" (Indiana University) needs to be routed to the USA federation server 🌍.
While the ccTLDs occupy only approximately 50 routing entries in total (and have an upper bound of approximately 200), the potential size of the routing table becomes virtually unlimited if it needs to accommodate all individual entries in .edu, .org, etc. 😱
In addition to that, all these routes need to be synchronized between three international root servers, and the updates need to be applied manually to RADIUS server configuration files. The frequency of the required updates makes this approach fragile and error-prone as the number of entries grows 🥴.
3.4. UDP Issues 🦋
RADIUS is based on UDP, which was a reasonable choice when its main use was with simple Password Authentication Protocol (PAP) requests that required only exactly one packet exchange in each direction 💜.
When transporting EAP over RADIUS, the EAP conversations require multiple round-trips; depending on the total payload size, 8-10 round-trips are not uncommon 🔁. The loss of a single UDP packet will lead to user-visible delays and might result in servers being marked as dead due to the absence of a reply 😤. The proxy path in eduroam consists of several proxies, all of which introduce a very small packet loss probability. That is, the more proxies needed, the higher the failure rate is going to be 📈.
For some EAP types, depending on the exact payload size they carry, RADIUS servers and/or supplicants may choose to put as much EAP data into a single RADIUS packet as the supplicant's Layer 2 medium allows, typically 1500 bytes 📦. In that case, the RADIUS encapsulation around the EAP-Message adds more bytes to the overall RADIUS payload size and in the end exceeds the 1500-byte limit, leading to fragmentation of the UDP datagram on the IP layer. While in theory this is not a problem, in practice there is evidence of misbehaving firewalls that erroneously discard non-first UDP fragments. This ultimately leads to a denial of service for users with such EAP types and that specific configuration 🚫.
One EAP type proved to be particularly problematic: EAP-TLS 😭. While it is possible to configure the EAP server to send smaller chunks of EAP payload to the supplicant (e.g., 1200 bytes, to allow for another 300 bytes of RADIUS overhead without fragmentation), very often the supplicants that send the client certificate do not expose such a configuration detail to the user. Consequently, when the client certificate is over 1500 bytes in size, the EAP-Message will always make use of the maximum possible Layer 2 chunk size, and this introduces fragmentation on the path from EAP peer to EAP server 🧩.
Both of the previously mentioned sources of errors (packet loss and fragment discard) lead to significant frustration for the affected users 😩. Operational experience of eduroam shows that such cases are hard to debug, since they require coordinated cooperation of all eduroam administrators on the authentication path. For that reason, the eduroam community is developing monitoring tools that help to locate fragmentation problems 🔍✨.
Note: For more detailed discussion of these issues, please refer to Section 1.1 of [RFC6613] 💖.
3.5. Insufficient Payload Encryption and EAP Server Validation ✨
Okay so RADIUS was originally only designed to encrypt a few select attributes, mostly User-Password 🔒. With EAP methods that follow [RFC4017], the user's credential isn't sent in User-Password anymore, and way stronger encryption is in use (usually TLS) 💖 that's giving secure.
Still, EAP doesn't encrypt every bit of personal info about the session 😬. Some stuff rides along in plain-text RADIUS attributes. The user's device can be spotted by checking Calling-Station-ID, and the user's location can be worked out from NAS-IP-Address, NAS-Identifier, or Operator-Name 📍. Since those aren't encrypted, even IP-layer third parties can harvest that data 🙈. In a worst-case scenario, that makes mobility profiles possible. Pervasive passive surveillance using this kind of connection metadata, like the recently uncovered incidents involving the US National Security Agency (NSA) and the UK Government Communications Headquarters (GCHQ), becomes possible by tapping RADIUS traffic from an IP hop near a RADIUS aggregation proxy 💀. While this is possible, the authors are not aware whether this has actually been done, but ngl that's still a lot.
These profiles aren't necessarily linkable to an actual user, because EAP allows for anonymous outer identities and protected credential exchanges 🧚. However, practical experience has shown that many users neglect to configure their supplicants in a privacy-preserving way, or their supplicants don't support that at all 😭. For EAP-TLS users especially, EAP-TLS identity protection is not usually implemented and cannot be used. In eduroam, concerned individuals and IdPs that use EAP-TLS use pseudonymous client certificates to get better privacy 🫶.
One way out, at least for EAP types involving a username, is to pursue the creation and deployment of preconfigured supplicant configurations that make all the required settings on user devices before their first connection attempt 🎀. This depends heavily on the remote configuration possibilities of the supplicants though, so it's not a guarantee.
A further threat involves verifying the EAP server's identity 👀. Even though the cryptographic foundation, TLS tunnels, is sound, there's a weakness in the supplicant configuration. Many users don't understand, or aren't willing to invest time into, inspecting server certificates or installing a trusted certification authority (CA). As a result, users may easily be tricked into connecting to an unauthorized EAP server, which leads to their credentials leaking to that unauthorized third party 🚨.
Again, one way out of this particular threat is to pursue the creation and deployment of preconfigured supplicant configurations that make all the required settings on user devices before their first connection attempt 🌸.
Note: There are many different and vendor-proprietary ways to preconfigure a device with the necessary EAP parameters (examples include Apple, Inc.'s "mobileconfig" and Microsoft's "EAPHost" XML schema). Some manufacturers even completely lack any means to distribute EAP configuration data. We believe there is value in defining a common EAP configuration metadata format that could be used across manufacturers, ideally leading to a situation where IEEE 802.1X network end users merely need to apply this configuration file to configure any of their devices securely with the required connection properties 🍓.
Another possible privacy threat involves transporting user-specific attributes in a Reply-Message. If, for example, a RADIUS server sends back a hypothetical RADIUS Vendor-Specific-Attribute User-Role = Student of Computer Science (e.g., for consumption of an SP RADIUS server and subsequent assignment into a "student" VLAN), this information would also be visible to third parties and could be added to the mobility profile 🙈.
The only way to mitigate all information leakage to third parties is to protect the entire RADIUS packet payload, so that IP-layer third parties cannot extract privacy-relevant information 🛡️. RADIUS as specified in RFC 2865 does not offer this possibility though. This motivated [RFC6614]; see Section 4.1 🦋.
4. New Trust Fabric 👑
The operational difficulties with an ever-increasing number of participants (as documented in the previous section) have led to a number of changes to the eduroam architecture. Those changes in turn have led to IETF specifications (as mentioned in the introduction) 🌈.
Note: The enhanced architecture components are fully backwards compatible with the existing installed base, and are, in fact, gradually replacing those parts of it where problems may arise 💅.
Whereas user authentication using IEEE 802.1X and EAP has remained unchanged (i.e., no need for end users to change any configurations), the issues reported in Section 3 have resulted in a major overhaul of the way EAP messages are transported from the RADIUS server of the SP to that of the IdP and back. The two fundamental changes are the use of TCP instead of UDP, and reliance on TLS instead of shared secrets between RADIUS peers, as outlined in [radsec-whitepaper] ✨.
4.1. RADIUS with TLS 🎀
The deficiencies of RADIUS over UDP described in Section 3.4 warranted a search for a replacement of RFC 2865 [RFC2865] for the transport of EAP. By the time this need was understood, the designated successor protocol to RADIUS, Diameter, was already specified by the IETF in its initial version [RFC3588]. However, within the operational constraints of eduroam (listed below), no single combination of software could be found. That is believed to still be true, more than ten years and one revision of Diameter [RFC6733] later 🙃. The constraints are:
- reasonably cheap to deploy on many administrative domains
- supporting the application of Network Access Server Requirements (NASREQ)
- supporting EAP application
- supporting Diameter Redirect
- supporting validation of authentication requests of the most popular EAP types (EAP Tunneled Transport Layer Security (EAP-TTLS), Protected EAP (PEAP), and EAP-TLS)
- possibility to retrieve these credentials from popular back-ends such as MySQL or Microsoft's Active Directory
In addition, no Wi-Fi Access Points at the disposal of eduroam participants supported Diameter, nor did any of the manufacturers have a roadmap towards Diameter support. That is believed to still be true, more than 10 years later 💀. This led to the open question of lossless translation from RADIUS to Diameter and vice versa, which is a question not satisfactorily answered by NASREQ 🤷♀️.
After monitoring the Diameter implementation landscape for a while, it became clear that a solution with better compatibility and a plausible upgrade path from the existing RADIUS hierarchy was needed 🧠. The eduroam community actively engaged in the IETF towards the specification of several enhancements to RADIUS to overcome the limitations mentioned in Section 3. The outcome of this process was [RFC6614] and [DYN-DISC] 🌸.
With its use of TCP instead of UDP, and with its full packet encryption, while maintaining full packet format compatibility with RADIUS/UDP, RADIUS/TLS [RFC6614] allows any given RADIUS link in eduroam to be upgraded without the need of a "flag day" 🏳️🌈✨.
In a first upgrade phase, the classic eduroam hierarchy (forwarding decision made by inspecting the realm) remains intact. That way, RADIUS/TLS merely enhances the underlying transport of the RADIUS datagrams. But this already provides some key advantages 💜:
- explicit peer reachability detection using long-lived TCP sessions
- protection of user credentials and all privacy-relevant RADIUS attributes
RADIUS/TLS connections for the static hierarchy could be realized with the TLS-PSK [RFC4279] operation mode (which effectively provides a 1:1 replacement for RADIUS/UDP's "shared secrets"). But since this operation mode is not widely supported as of yet, all RADIUS/TLS links in eduroam are secured by TLS with X.509 certificates from a set of accredited CAs 🔐.
This first deployment phase does not yet solve the routing table complexity problem (see Section 3.3). This aspect is covered by introducing dynamic discovery for RADIUS/TLS servers 🧚.
4.2. Dynamic Discovery 🔍
When introducing peer discovery, two separate issues had to be addressed:
- how to find the network address of a responsible RADIUS server for a given realm
- how to verify that this realm is an authorized eduroam participant
4.2.1. Discovery of Responsible Server 🗺️
Issue 1 can relatively simply be addressed by putting eduroam-specific service discovery information into the global DNS tree. In eduroam, this is done by using NAPTR records as per the S-NAPTR specification [RFC3958] with a private-use NAPTR service tag (x-eduroam:radius.tls). The usage profile of that NAPTR resource record is that exclusively "S" type delegations are allowed, and that no regular expressions are allowed 📋.
A subsequent lookup of the resulting SRV records will eventually yield hostnames and IP addresses of the authoritative server(s) of a given realm 💖.
Example (wrapped for readability):
> dig -t naptr education.example.
;; ANSWER SECTION:
education.example. 43200 IN NAPTR 100 10 "s"
"x-eduroam:radius.tls" ""
_radsec._tcp.eduroam.example.
> dig -t srv _radsec._tcp.eduroam.example.
;; ANSWER SECTION:
_radsec._tcp.eduroam.example. 43200 IN SRV 0 0 2083
tld1.eduroam.example.
> dig -t aaaa tld1.eduroam.example.
;; ANSWER SECTION:
tld1.eduroam.example. 21751 IN AAAA 2001:db8:1::2
Figure 3: SRV Record LookupFrom the operational experience with this mode of operation, eduroam is pursuing standardization of this approach for generic AAA use cases. The current RADEXT working group document for this is [DYN-DISC] 🎓.
Note: It is worth mentioning that this move to a more complex, flexible system may make the system as a whole more fragile, as compared to the static set up 🙈.
4.2.2. Verifying Server Authorization
okay so here's the catch 🕵️♀️ any organization can slap an x-eduroam NAPTR entry into their DNS and pretend to be the eduroam Identity Provider for a realm they don't own. eduroam is a super diverse crowd but it's still a CLOSED club, so you need extra receipts to prove a realm and its discovered server are actually eduroam participants. bestie, no fake VIPs allowed 💅
The eduroam consortium went with its own PKI that only hands out certificates to authorized eduroam Identity Providers and eduroam Service Providers. And since RADIUS/TLS needs certificates anyway, reusing that PKI was a no-brainer 🧠✨ The PKI lets multiple CAs be trust roots (overseen by a Policy Management Authority), and certificates issued to verified eduroam participants have to be marked with the matching X509v3 Policy OID fields. eduroam RADIUS servers and clients need to check that those OIDs are actually in the incoming certificates. iconic gatekeeping 🫶
The policies and OIDs can be pulled from the "eduPKI Trust Profile for eduroam Certificates" [eduPKI] 📖
4.2.3. Operational Experience
the discovery model is live right now in roughly 10 countries that take part in eduroam, and more than 100 realms are discoverable through their NAPTR records 🌍🎀 the vibe check says it works and scales the way it's supposed to. the only real downside is that running a PKI that isn't local to the national eduroam admins is a whole admin headache 😩 Also, having multiple CAs plus regular Certificate Revocation List updates makes RADIUS servers more complicated to operate. it's giving "more moving parts, more problems" 🙈
4.2.4. Possible Alternatives
there are two alternatives to this dynamic server discovery approach that the eduroam community is keeping an eye on 👀
- DNSSEC + DNS-Based Authentication of Named Entities (DANE) TLSA records
- ABFAB Trust Router
for DNSSEC+DANE TLSA, the biggest perk is that the certificate data itself can live in the DNS 🦋 which could make the PKI infrastructure obsolete if a new home for the server authorization checks can be found. the big catch is that the DANE specifications only cover client-to-server certificate checks, while RADIUS/TLS needs server-to-client verification too 😭
for the ABFAB Trust Router, the biggest perk is that it works without certificates altogether, by negotiating TLS-PSK keys ad hoc 🧚 the downside is that it isn't formally specified yet and nobody understands it as thoroughly as the other solutions. not the vibe we want, ngl 💀
5. Abuse Prevention and Incident Handling ✨
since eduroam is a confederation of autonomous networks, there's really little reason to pass accounting information from the Service Provider to anyone else in general, or to the user's Identity Provider in particular 🙅♀️ so accounting in eduroam is treated as a local matter for the Service Provider. the eduroam compliance statement [eduroam-compliance] actually says accounting traffic [RFC5280] SHOULD NOT be forwarded. no forwarding drama 💅
the eduroam static routing setup works like a filter that blocks accounting traffic coming from misconfigured local RADIUS servers 🛡️ proxy servers are set up to end accounting request traffic by answering Accounting-Requests with an Accounting-Response, so orphaned Accounting-Request messages don't keep getting retransmitted. with dynamic discovery, Identity Providers that can be found through DNS will have to apply these filters themselves. so yes, the Identity Provider RADIUS configuration gets more complex 😤
roaming creates accountability problems, as [RFC4372] (Chargeable User Identity) points out 🔍 the NAS can only see the user's outer identity, which is likely anonymous, so there's no way to link usage to one specific user (who might be using several devices). a NAS that supports [RFC4372] can ask for the Chargeable-User-Identity, and if the authenticating RADIUS server includes it in the Access-Accept message, the NAS can add that value to matching Access-Request packets ✨ eduroam doesn't do any charging, but it can still be useful to spot traffic from one particular user. one big reason is stopping guest-access abuse by people living near university campuses 🏫 Chargeable User Identity (see Section 5.3) is the perfect answer to that problem! however, as of writing, to our knowledge, only one hardware vendor (Meru Networks) implements RFC 4372 on their access points 🙃 for every other vendor, requesting the Chargeable-User-Identity attribute has to happen on the RADIUS server that the access point is connected to. FreeRADIUS supports this in the latest distribution, and Radiator can be retrofitted to do the same 🎀
5.1. Incident Handling
10 years of eduroam and no serious incidents yet 🥹 that could be evidence of solid security design, and it could also suggest that users knowing they're identifiable is a super effective deterrent. it could also mean that eduroam operations lack the proper tools or insight into how the service is actually used and abused, so it's not a free pass 👀 either way, lots of the attack vectors found in open networks, or in networks where access control depends on shared secrets, simply aren't present here, which arguably makes the system way more secure 🔐
here's the countermeasures discussion 📝
the European eduroam Policy Service Definition [eduroam-service-definition] is one example that describes incident scenarios and the actions to take. in this document, though, we're only covering the relevant technical issues 🤓
the first implementation was missing reliable tools for an SP to make its own decision, or for an IdP to add a conditional rule that only applies to one given SP. adding support for Operator-Name and Chargeable-User-Identity (see Section 5.3) to eduroam makes both of these scenarios possible 🎉
5.1.1. Blocking Users on the SP Side
first step in an incident is blocking the user's access to eduroam at the Service Provider 🚫 the roaming user's true identity is probably hidden behind an anonymous or fake outer identity, so the Service Provider can only rely on the user's realm and MAC address. if the Identity Provider already sent a Chargeable-User-Identity (see Section 5.3 for details), that extra info can be used to identify the user more reliably 💜
a first try on the SP side might be blocking by MAC address or outer identity. this blocking can happen before EAP authentication even starts, usually in the first datagram, by acting on the RADIUS attributes EAP-Message/EAP-Response/Identity and Calling-Station-ID. the datagram can be dropped (so the supplicant just notices a time-out), or it can be answered with a RADIUS Access-Reject containing an EAP-Failure. but malicious users can change both their MAC addresses and the local part of their outer identity between connection attempts, so this first attempt isn't enough to lock out a determined user 😤
the second measure is for the SP to let EAP authentication go ahead as normal, then check whether the final Access-Accept response from the RADIUS server contains a Chargeable-User-Identity (CUI). if it does, the SP RADIUS server can be set up to turn every future Access-Accept for that CUI into an Access-Reject/EAP-Failure 🔒 this one is effective AND efficient: it locks out exactly the one user who's supposed to be locked out, with zero side-effects on other users, even from the same realm. chef's kiss 👌
if EAP authentication doesn't reveal a CUI, the SP can't reliably figure out who the user is. the only reliable info to act on is then the realm portion of the user's outer identity. the SP will have to block the entire realm the offending user belongs to. that works, but it isn't efficient: it locks out the user in question, and it causes a DoS side-effect for every other visiting user from that same realm 😬
if there's no CUI handle, SPs that aren't willing to take the drastic step of blocking a whole realm will have to contact the Identity Provider in question and ask them to block the user on the IdP side. that involves humans talking to humans between SP and IdP, so it can't happen in real time 🐌
5.1.2. Blocking Users on the IdP Side
the IdP has the power to disable a user account completely, which blocks that user from accessing eduroam at every site 🏠 if the blocking is requested by an SP (as in the previous section), there may be a more fine-grained option to block access to one specific SP, as long as the SP sends the Operator-Name attribute along with its Access-Requests (see Section 5.2 for details) ✨
if the IdP decides to block the user globally, it's typically done by treating the login attempt as if the credentials were wrong. the entire EAP conversation has to run until the true inner identity is revealed, because before that point the IdP doesn't know which user is trying to authenticate 🕵️♀️ this usually happens at the same moment the credentials are exchanged. instead of checking the credential for validity, or in addition to it, the Identity Provider also checks whether the user's account is (still) eligible for eduroam use, and it will return an Access-Reject/EAP-Failure if it isn't 🚫
there can definitely be times when the SP wanting a user locked out and the user's IdP disagree 🙄 for example, an SP might find massive up-/downloads with file sharing protocols unacceptable under its local policy, and want users who create too much traffic blocked. but the IdP doesn't take offense at that kind of action and wouldn't want to lock its user out of eduroam globally just because of one SP's opinion 💅
without the Operator-Name attribute, there's no way to apply a login restriction only for a given SP and not for eduroam as a whole. eduroam eligibility is an all-or-nothing call for the IdP 😐
if the Operator-Name attribute is present, the IdP can use it to fail the authentication attempt only when the attempt came from SPs that want that blocking 🎯 the Operator-Name attribute is available from the first RADIUS Access-Request datagram onward, but the EAP authentication still needs to be carried out until the true inner identity is known, just like in the global blocking case above. Operator-Name is simply one more piece of info the IdP can use to make its decision 🫶
5.1.3. Communicating Account Blocking to the End User 📵💬
okay so the blocks from 5.1.1 and 5.1.2 both mess with the EAP conversation. ✨ They either cause an early rejection or timeout right at the start, or they flip the result right at the very end. 😭
the supplicant side is where it gets messy 🙈 from the device's POV, these look exactly like an infrastructure failure. an early rejection or timeout could just mean a RADIUS server isn't responding, and a rejection at the end could be user error (wrong password) or server error (credential lookup failed). so it's really hard for the supplicant to show the user a meaningful error. the newly specified EAP type TEAP, Tunnel Extensible Authentication Protocol [RFC7170], can carry fine-grained error reason codes to the supplicant, so that could make things way better later 🌈
the EAP protocol does have one built-in way to talk to the user: its state machine has states for user-visible messages. you can slip an extra EAP-Request/Notification round, plus its acknowledgement, in right before the final EAP-Failure 💌
BUT anecdotal evidence says supplicants usually don't implement that part of the state machine at all 💀 one supplicant is reported to support it, but it just dumps the notification contents into a log file, which is literally no help to the end user 😩
so the reasons for blocking, and how far the blocking goes, get handled out-of-band 🫶 the eduroam user support process says users with authentication problems have to contact their Identity Provider first. the method is up to them (for example, phoning the IdP or emailing through a 3G backup link) 📞 if the IdP is the one that blocked them, the IdP tells the user right away 💅 if the reason is on the SP side, the IdP tells the user the account is in working order and that they need to reach out to the SP's IT support for more info. then that SP-side IT support lets the users know why they were blocked 🎀
5.2. Operator Name 🏷️
the Operator-Name attribute is defined in [RFC5580] as a way to uniquely identify the access site ✨
the eduroam proxy setup means home sites can't tell where their users roam 🕵️♀️ ngl that's great for privacy, but it also makes user support, roaming stats, and blocking offending users way harder 😤
sites in eduroam are encouraged to add Operator-Name using the REALM namespace, which means sending a realm name that the site controls 🌸
adding Operator-Name to eduroam caused one operational problem 💀 attribute ID 126 was already used by some vendors for their own stuff, and it shows up in the attribute dictionaries of several RADIUS server distributions. its syntax was set to Integer, which clashes with the RFC definition (where it's Text). eduroam tests found that servers using Integer for attribute 126 might truncate the value to 4 octets, or even drop the whole RADIUS packet (so authentication just can't happen) 🥲 the eduroam monitoring and test tools go looking for sites with this problem. Section 2.8 of [RFC6929] explains how these packets should be handled 📚
when an SP sends its Operator-Name value, home sites can set up conditional blocking rules that stop certain users from reaching selected sites. that's way less drama than blocking someone from all of eduroam 💖
in eduroam, the Operator Name is also used to generate Chargeable User Identity values 🦋
and honestly? adding Operator-Name is just a simple RADIUS server config change, so it can roll out at a big scale super easily 🍓
5.3. Chargeable User Identity 🪪
the Chargeable-User-Identity (CUI) attribute is defined by RFC 4372 [RFC4372] as the answer to accounting problems that show up when some EAP methods use anonymous identities 🧚 in eduroam, CUI is mainly for incident handling, but it can also make local accounting better ✨
the eduroam policy says a given user's CUI for requests from different sites has to be different, to stop collusion attacks 🔒 so the policy also requires that a CUI request comes with Operator-Name, which is one of the inputs to the CUI generation algorithm. the Operator-Name requirement counts as the "business requirement" in Section 2.1 of RFC 4372 [RFC4372], so it's totally within the RFC 💅
when eduroam started looking at CUI, there were no NAS implementations, so the only option was to move all the CUI support onto the RADIUS server 🖥️
generating a CUI request only needs NUL CUI attributes added to outgoing Access-Requests 🌈 but the real power of CUI shows up in accounting. CUI-based accounting on the server needs the authentication and accounting RADIUS servers that the NAS talks to directly to be the same server, or at least to share a common source of information 🫶 when an Access-Accept is processed, the authenticating RADIUS server has to store the received CUI value together with the device's Calling-Station-Id in a temporary database. when an Accounting-Request comes in, the server updates the packet with the CUI value it reads from that database ✨
if CUI gets widely adopted in eduroam, incident handling at SPs gets way simpler 🔥 per-user local access restrictions become possible 👑 visited sites can also tell the home site about a restriction, pointing to the CUI value, which lets the home site figure out who the user is 🙈 so when the user reports the problem to their home support, the reason is already known 💜
6. Privacy Considerations 🔐
the eduroam architecture was designed with protecting user credentials in mind, as you can probably tell from how far you've read 🫶 still, operational experience has surfaced a few subtler privacy points 🦋
6.1. Collusion of Service Providers 🤝
if users use anonymous outer identities, SPs can't easily collude by linking outer identities to the users visiting their campus 🙌 but that makes it hard to fix abuse or misconfiguration. it's impossible to find the user who's behaving badly or whose system has been compromised 😬
that's why the Chargeable-User-Identity was introduced in eduroam. it's built so that only the user's IdP can uniquely identify the user 🎀 to prevent collusion attacks, the CUI has to be unique per user and per Service Provider 💖
6.2. Exposing User Credentials 🙈
with EAP, user credentials aren't visible to anyone except the user's IdP 🔐 that's only true if a sufficiently secure EAP method is chosen and EAP isn't terminated early 💅
there's one privacy-sensitive user attribute that's necessarily exposed to third parties: the realm the user belongs to 😭 routing in eduroam is based on the realm part of the user identifier. so even if the outer identity in a tunneled EAP method is set to an anonymous identifier, it MUST contain the user's realm 🫣 that means it could still identify someone if their realm has only a few users. this is seen as a reasonable trade-off between privacy and usability ⚖️
6.3. Track Location of Users 📍
access requests can travel through a bunch of proxy RADIUS servers, so the user's home IdP usually can't tell where a user is roaming 🌸
BUT the introduction of Operator-Name and dynamic lookups (direct connections between IdP and SP) gives the home IdP insight into where the user is 👀
7. Security Considerations 🛡️
this section only covers security considerations for using eduroam 🫶 for IEEE 802.1X, RADIUS, and EAP in general, check the specific specs and other literature 📚
7.1. Man-in-the-Middle and Tunneling Attacks 😱
the security of user credentials in eduroam ultimately comes down to EAP server verification during the EAP conversation. that's why the eduroam policy requires that only EAP types capable of mutual authentication are allowed in the infrastructure. it also requires IdPs to publish all the info needed to uniquely identify the server (usually the EAP server's CA certificate and its Common Name or subjectAltName:dNSName) 🔒
in principle, this makes man-in-the-middle attacks impossible, but in practice several attack vectors still exist 💀 most of these holes come from implementation shortcomings in EAP supplicants. some examples:
7.1.1. Verification of Server Name Not Supported 🚨
some supplicants only let you specify which CA issues the EAP server certificate, and they never check its name. so any entity that can get a server certificate from that same CA can set up its own EAP server and trick the end user into handing over their credentials to a fake server 😱
to mitigate this, eduroam Operations suggests using a private CA that only issues certificates to the organization's EAP servers 🏰 then no other entity can get a certificate from that CA, and this supplicant shortcoming stops being a security threat 💅
7.1.2. Neither Specification of CA nor Server Name Checks during Bootstrap 🫠
some supplicants allow insecure bootstrapping. they let you pick a network and accept the incoming server certificate based on its fingerprint 🙃 that certificate then gets saved as trusted for later reconnection attempts. if users are near a fake hotspot during initial provisioning, they can be tricked into submitting their credentials to a fake server, and they'll be branded to only trust that fake server from then on 💀
eduroam Identity Providers are advised to give their users complete setup documentation for their supplicants that skips the insecure bootstrapping shortcut 📝 eduroam Operations also made a tool, eduroam CAT [eduroam-CAT], that sets up correct, complete, and secure settings on many supplicants 🌈
7.1.3. User Does Not Configure CA or Server Name Checks 🔐
okay so bestie, unless automatic provisioning tools like eduroam CAT are being used, it is genuinely cumbersome for users to set up an EAP supplicant securely at first 😭 supplicant UIs literally invite people to take shortcuts like "Don't check server certificate" because that's the easy setup, or they bury the important security settings in super hidden sub-menus 💀 and those shortcuts or missing security parameters make the user subject to man-in-the-middle attacks. not it. 🙅♀️
eduroam IdPs are advised to educate their users on the steps needed for a secure setup 🫶 and eduroam Research and Development is in touch with supplicant developers to improve their user interfaces 💅✨
7.1.4. Tunneling Authentication Traffic to Obfuscate User Origin 🦋
this one is a whole plot twist 😭 there is no link between the EAP outer ("anonymous") identity and the EAP inner ("real") identity. both of them can contain a realm name, and the realms don't have to match 🙈 so it's possible to craft packets with an outer identity of user@RealmB and an inner identity of user@realmA. with eduroam request routing, a Service Provider would assume the user is from realmB and send the request there. then the server at realmB inspects the inner user name, and if proxying is not explicitly disabled for tunneled request content, it may decide to send the tunneled EAP payload to realmA, where the user actually authenticates 🌀 and a CUI value would likely be generated by the server at realmB, even though this is not its user. iconic chaos, honestly 💀
users can craft packets like this to make their identification harder 🕵️♀️ usually the eduroam SP would assume the troublesome user comes from realmB and demand that the user be blocked there. however, the operator of realmB has no control over the user, and can only trace the user back to their real origin if logging of proxied requests is also enabled for EAP tunnel data 📝
eduroam Identity Providers are advised to explicitly disable proxying on the parts of their RADIUS server configuration that process EAP tunnel data. main character IdP energy 👑
7.2. Denial-of-Service Attacks 🌩️
okay so since eduroam's roaming infrastructure is built on IP and RADIUS, it suffers from the usual DoS attack vectors that apply to these protocols 😩
eduroam hotspots are susceptible to typical attacks on edge networks, like rogue Router Advertisements (RAs), rogue DHCP servers, and others 🙃 but lowkey, eduroam hotspots are more robust against malign users' DHCP pool exhaustion than typical open or "captive portal" hotspots 💖 why? because a DHCP address is only leased after a successful authentication. that shrinks the pool of possible attackers to eduroam account holders, instead of the general public 🎀 also, attacks involving ARP spoofing or ARP flooding are reduced to authenticated users too, because an attacker needs to be in possession of a valid WPA2 session key to send traffic on the network 🔑
this section doesn't cover standard threats to edge networks and IP networks in general 🧚 the following sections describe attack vectors specific to eduroam 🍓
7.2.1. Intentional DoS by Malign Individuals 😤
the eduroam infrastructure is more robust against Distributed DoS attacks than typical services reachable on the Internet 🛡️ because triggering authentication traffic can only happen when someone is physically near an eduroam hotspot (be it a wired socket that is IEEE 802.1X enabled or a Wi-Fi Access Point) 📍
however, when they're in the vicinity, an attacker can easily craft authentication attempts that traverse the entire international eduroam infrastructure 🌍 an attacker just needs to choose a realm from another world region than their physical location to trigger Access-Requests that must be processed by the SP, then the SP-side national server, then the world region, then the target world region, then the target national server, then the target IdP server. 😭 as long as the realm actually exists, this is followed by an entire EAP conversation along that path. since they don't have actual credentials, the request will ultimately be rejected, but it still ate up processing power and bandwidth across the entire infrastructure, possibly affecting all international authentication traffic 💀
EAP is a lock-step protocol 🔒 so a single attacker at an eduroam hotspot can only run one EAP conversation after another, and is therefore rate-limited by the round-trip times of the RADIUS chain ⏱️
right now, eduroam processes several hundred thousand successful international roaming authentications per day (and, incidentally, approximately 1.5 times as many Access-Rejects) 📈 with the requirement of physical proximity and the rate-limiting from EAP's lock-step nature, it takes a significant number of attackers and a time-coordinated attack to produce significant load. so far, eduroam Operations has not yet observed critical load conditions that could reasonably be attributed to such an attack 🙌
the introduction of dynamic discovery further eases this problem ✨ authentications will then not traverse all infrastructure servers, which removes the world-region aggregation servers as obvious bottlenecks. any attack would then be limited to between an SP and IdP directly 🫶
7.2.2. DoS as a Side-Effect of Expired Credentials 🗑️
in eduroam Operations, they've observed that a big chunk of (failed) eduroam authentications come from user accounts that were valid once but have since been de-provisioned (for example, when a student has left the university after graduation 🎓). configured eduroam accounts are often kept on user devices, and when a device is near an eduroam hotspot, the operating system will try to connect to this network 📶
as eduroam keeps running, the number of devices with leftover configurations keeps growing, effectively creating a pool of devices that produce unwanted network traffic whenever they can 😵💫
until recently, this didn't get much attention, because that pool was also naturally shrinking as users finally retired their old computing hardware ♻️
recently though, smartphones are set up to use cloud storage and online backup mechanisms that save most, or all, of the device's configuration details with a third party ☁️ when people renew their personal computing hardware, they can restore the old settings onto the new device. it's been observed that expired eduroam accounts can survive forever on user devices that way 🙃 if this trend continues, an always-growing pool of devices will clog up eduroam infrastructure with doomed-to-fail authentication requests 😩
there isn't currently a useful fix for this problem, other than telling users to manually delete their configuration in due time 🧹 possible approaches are:
- Creating a culture of device provisioning where the provisioning profile contains a
ValidUntilproperty, after which the configuration needs to be re-validated or disabled. this requires a data format for provisioning as well as implementation support 📋 - Improvements to supplicant software so that it maintains state over failed authentications. for example, if a previously known working configuration failed to authenticate consistently for 30 calendar days, it should be considered stale and be disabled 🗓️
8. References 📚
8.1. Normative References 💜
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<http://www.rfc-editor.org/info/rfc2865>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
H. Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<http://www.rfc-editor.org/info/rfc3748>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, DOI 10.17487/RFC4279, December 2005,
<http://www.rfc-editor.org/info/rfc4279>.
[RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney,
"Chargeable User Identity", RFC 4372,
DOI 10.17487/RFC4372, January 2006,
<http://www.rfc-editor.org/info/rfc4372>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC5580] Tschofenig, H., Ed., Adrangi, F., Jones, M., Lior, A., and
B. Aboba, "Carrying Location Objects in RADIUS and
Diameter", RFC 5580, DOI 10.17487/RFC5580, August 2009,
<http://www.rfc-editor.org/info/rfc5580>.
[RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote
Authentication Dial In User Service (RADIUS) Protocol",
RFC 5997, DOI 10.17487/RFC5997, August 2010,
<http://www.rfc-editor.org/info/rfc5997>.
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613,
DOI 10.17487/RFC6613, May 2012,
<http://www.rfc-editor.org/info/rfc6613>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, DOI 10.17487/RFC6614, May 2012,
<http://www.rfc-editor.org/info/rfc6614>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>.8.2. Informative References ✨
Okay bestie, these are the background reads 📚 Nothing here is a hard requirement. They're just the receipts for everything the spec name-drops, so you can go deeper whenever you want.
[ABFAB-ARCH]Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. Schaad, "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", Work in Progress, draft-ietf-abfab-arch-13, July 2014. 🦋[dead-realm]Tomasek, J., "Dead-realm marking feature for Radiator RADIUS servers", 2006,<http://www.eduroam.cz/dead-realm/docs/dead-realm.html>. 🌸[DYN-DISC]Winter, S. and M. McCauley, "NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS", Work in Progress, draft-ietf-radext-dynamic-discovery-15, April 2015. 🔍[eduPKI]Delivery of Advanced Network Technology to Europe, "eduPKI Trust Profiles", 2012,<https://www.edupki.org/edupki-pma/edupki-trust-profiles/>. 🔐[eduroam-CAT]Delivery of Advanced Network Technology to Europe, "eduroam CAT", 2012,<https://cat.eduroam.org>. 🛠️[eduroam-compliance]Trans-European Research and Education Networking Association, "eduroam Compliance Statement", October 2011,<http://www.eduroam.org/downloads/docs/eduroam_Compliance_Statement_v1_0.pdf>. 📝[eduroam-homepage]Trans-European Research and Education Networking Association, "eduroam Homepage", 2007,<http://www.eduroam.org/>. 🏠[eduroam-service-definition]GEANT, "eduroam Policy Service Definition", Version 2.8, July 2012,<https://www.eduroam.org/downloads/docs/GN3-12-192_eduroam-policy-service-definition_ver28_26072012.pdf>. 📄[eduroam-start]Wierenga, K., "Subject: proposal for inter NREN roaming", message to the mobility@terena.nl mailing list, initial proposal for what is now called eduroam, 30 May 2002,<http://www.terena.org/activities/tf-mobility/start-of-eduroam.pdf>. 🌱[IEEE.802.1X]IEEE, "IEEE Standard for Local and metropolitan area networks - Port-Based Network Access Control", IEEE 802.1X-2010, DOI 10.1109/ieeestd.2010.5409813,<http://ieeexplore.ieee.org/servlet/opac?punumber=5409757>. ⚡[nrenroaming-select]Trans-European Research and Education Networking Association, "Preliminary selection for inter-NREN roaming", December 2003,<http://www.terena.org/activities/tf-mobility/deliverables/delG/DelG-final.pdf>. 🗂️[radsec-whitepaper]Open System Consultants, "RadSec: a secure, reliable RADIUS Protocol", October 2012,<http://www.open.com.au/radiator/radsec-whitepaper.pdf>. 🔒[RFC3588]Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, DOI 10.17487/RFC3588, September 2003,<http://www.rfc-editor.org/info/rfc3588>. 💜[RFC3958]Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, January 2005,<http://www.rfc-editor.org/info/rfc3958>. 🧭[RFC4017]Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, DOI 10.17487/RFC4017, March 2005,<http://www.rfc-editor.org/info/rfc4017>. 📶[RFC6733]Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012,<http://www.rfc-editor.org/info/rfc6733>. 💫[RFC6929]DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, DOI 10.17487/RFC6929, April 2013,<http://www.rfc-editor.org/info/rfc6929>. ✨[RFC7170]Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, "Tunnel Extensible Authentication Protocol (TEAP) Version 1", RFC 7170, DOI 10.17487/RFC7170, May 2014,<http://www.rfc-editor.org/info/rfc7170>. 🚇[RFC7542]DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015,<http://www.rfc-editor.org/info/rfc7542>. 🪪
Acknowledgments 🫶
The authors want to thank everyone in the Geant Association Task Force on Mobility and Network Middleware, plus the Geant project, for their reviews and contributions. 💖 Extra special thanks go to Jim Schaad for an excellent review of the first version, and to him and Alan DeKok for more reviews. 👑
The eduroam trademark is registered by TERENA. 🎀
Authors' Addresses 📮
Meet the squad who wrote this 💅
Klaas Wierenga
Cisco Systems
Haarlerbergweg 13-17
Amsterdam 1101 CH
The Netherlands
Phone: +31 20 357 1752
Email: klaas@cisco.comStefan Winter
Fondation RESTENA
Maison du Savoir
2, avenue de l'Universite
L-4365 Esch-sur-Alzette
Luxembourg
Phone: +352 424409 1
Fax: +352 422473
Email: stefan.winter@restena.lu
URI: http://www.restena.lu.Tomasz Wolniewicz
Nicolaus Copernicus University
pl. Rapackiego 1
Torun
Poland
Phone: +48-56-611-2750
Fax: +48-56-622-1850
Email: twoln@umk.pl
URI: http://www.home.umk.pl/~twoln/📦 where this page comes from
- ietf: rfc7593 2015-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms