idnits 2.17.1 draft-wierenga-ietf-eduroam-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 21, 2014) is 3535 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2866' is defined on line 1442, but no explicit reference was found in the text == Unused Reference: 'RFC4279' is defined on line 1448, but no explicit reference was found in the text == Unused Reference: 'RFC5176' is defined on line 1455, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 1460, but no explicit reference was found in the text == Unused Reference: 'RFC5247' is defined on line 1463, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 1467, but no explicit reference was found in the text == Unused Reference: 'RFC6066' is defined on line 1480, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-radext-dtls' is defined on line 1502, but no explicit reference was found in the text == Unused Reference: 'MD5-attacks' is defined on line 1516, but no explicit reference was found in the text == Unused Reference: 'RFC3539' is defined on line 1521, but no explicit reference was found in the text == Unused Reference: 'RFC4107' is defined on line 1535, but no explicit reference was found in the text == Unused Reference: 'RFC4346' is defined on line 1538, but no explicit reference was found in the text == Unused Reference: 'RFC4953' is defined on line 1541, but no explicit reference was found in the text == Unused Reference: 'RFC6125' is defined on line 1544, but no explicit reference was found in the text == Unused Reference: 'RFC6421' is defined on line 1550, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-15) exists of draft-ietf-radext-dynamic-discovery-11 == Outdated reference: A later version (-15) exists of draft-ietf-radext-nai-06 -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 1 error (**), 0 flaws (~~), 18 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Wierenga 3 Internet-Draft Cisco Systems 4 Intended status: Informational S. Winter 5 Expires: February 22, 2015 RESTENA 6 T. Wolniewicz 7 Nicolaus Copernicus University 8 August 21, 2014 10 The eduroam architecture for network roaming 11 draft-wierenga-ietf-eduroam-04.txt 13 Abstract 15 This document describes the architecture of the eduroam service for 16 federated (wireless) network access in academia. The combination of 17 IEEE 802.1X, EAP and RADIUS that is used in eduroam provides a 18 secure, scalable and deployable service for roaming network access. 19 The successful deployment of eduroam over the last decade in the 20 educational sector may serve as an example for other sectors, hence 21 this document. In particular the initial architectural and standards 22 choices and the changes that were prompted by operational experience 23 are highlighted. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 22, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4 62 1.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4 63 1.4. Solutions that were considered . . . . . . . . . . . . . 5 64 2. Classic Architecture . . . . . . . . . . . . . . . . . . . . 5 65 2.1. Authentication . . . . . . . . . . . . . . . . . . . . . 6 66 2.1.1. IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . 6 67 2.1.2. EAP . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.2. Federation Trust Fabric . . . . . . . . . . . . . . . . . 9 69 2.2.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . 9 70 3. Issues with initial Trust Fabric . . . . . . . . . . . . . . 11 71 3.1. Server Failure Handling . . . . . . . . . . . . . . . . . 12 72 3.2. No error condition signalling . . . . . . . . . . . . . . 13 73 3.3. Routing table complexity . . . . . . . . . . . . . . . . 14 74 3.4. UDP Issues . . . . . . . . . . . . . . . . . . . . . . . 14 75 3.5. Insufficient payload encryption and EAP server validation 15 76 4. New Trust Fabric . . . . . . . . . . . . . . . . . . . . . . 17 77 4.1. RADIUS with TLS . . . . . . . . . . . . . . . . . . . . . 17 78 4.2. Dynamic Discovery . . . . . . . . . . . . . . . . . . . . 19 79 4.2.1. Discovery of responsible server . . . . . . . . . . . 19 80 4.2.2. Verifying server authorisation . . . . . . . . . . . 20 81 4.2.3. Operational Experience . . . . . . . . . . . . . . . 21 82 4.2.4. Possible Alternatives . . . . . . . . . . . . . . . . 21 83 5. Abuse prevention and incident handling . . . . . . . . . . . 21 84 5.1. Incident Handling . . . . . . . . . . . . . . . . . . . . 22 85 5.1.1. Blocking users on the SP side . . . . . . . . . . . . 23 86 5.1.2. Blocking users on the IdP side . . . . . . . . . . . 24 87 5.1.3. Communicating account blocking to the end user . . . 24 88 5.2. Operator Name . . . . . . . . . . . . . . . . . . . . . . 25 89 5.3. Chargeable User Identity . . . . . . . . . . . . . . . . 26 90 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 91 6.1. Collusion of Service Providers . . . . . . . . . . . . . 27 92 6.2. Exposing user credentials . . . . . . . . . . . . . . . . 27 93 6.3. Track location of users . . . . . . . . . . . . . . . . . 28 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 95 7.1. Man in the middle and Tunneling Attacks . . . . . . . . . 28 96 7.1.1. Verification of Server Name not supported . . . . . . 28 97 7.1.2. Neither Specification of CA nor Server Name checks 98 during bootstrap . . . . . . . . . . . . . . . . . . 29 99 7.1.3. User does not configure CA or Server Name checks . . 29 100 7.1.4. Tunneling authentication traffic to obfuscate user 101 origin . . . . . . . . . . . . . . . . . . . . . . . 29 102 7.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 30 103 7.2.1. Intentional DoS by malign individuals . . . . . . . . 30 104 7.2.2. DoS as a side-effect of expired credentials . . . . . 31 105 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 106 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 107 9.1. Normative References . . . . . . . . . . . . . . . . . . 32 108 9.2. Informative References . . . . . . . . . . . . . . . . . 33 109 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 36 110 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 36 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 113 1. Introduction 115 In 2002 the European Research and Education community set out to 116 create a network roaming service for students and employees in 117 academia [eduroam-start]. Now over 10 years later this service has 118 grown to more than 10,000 service locations, serving millions of 119 users on all continents with the exception of Antarctica. 121 This memo serves to explain the considerations for the design of 122 eduroam as well as to document operational experience and resulting 123 changes that led to IETF standardization effort like RADIUS over TCP 124 [RFC6613] and RADIUS with TLS [RFC6614] and that promoted alternative 125 uses of RADIUS like in ABFAB [I-D.ietf-abfab-arch]. Whereas the 126 eduroam service is limited to academia, the eduroam architecture can 127 easily be reused in other environments. 129 First this memo describes the original architecture of eduroam. Then 130 a number of operational problems are presented that surfaced when 131 eduroam gained wide-scale deployment. Lastly, enhancements to the 132 eduroam architecture that mitigate the aforementioned issues are 133 discussed. 135 1.1. Terminology 137 This document uses identity management and privacy terminology from 138 [RFC6973]. In particular, this document uses the terms Identity 139 Provider, Service Provider and identity management. 141 1.2. Notational Conventions 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 Note: Also the policy that eduroam participants subscribe to, 148 expresses the requirements for participation in RFC 2119 language. 150 1.3. Design Goals 152 The guiding design considerations for eduroam were as follows: 154 - Unique identification of users at the edge of the network 156 The access Service Provider (SP) needs to be able to determine 157 whether a user is authorized to use the network resources. 158 Furthermore, in case of abuse of the resources, there is a 159 requirement to be able to identify the user uniquely (with the 160 cooperation of the user's Identity Provider (IdP) operator). 162 - Enable (trusted) guest use 164 In order to enable roaming it should be possible for users of 165 participating institutions to get seamless access to the networks of 166 other institutions. 168 Note: traffic separation between guest users and normal users is 169 possible (for example through the use of VLANs), and indeed widely 170 used in eduroam. 172 - Scalable 174 The infrastructure that is created should scale to a large number of 175 users and organizations without requiring a lot of coordination and 176 other administrative procedures (possibly with the exception of an 177 initial set up). Specifically, it should not be necessary for a user 178 that visits another organization to go through an administrative 179 process. 181 - Easy to install and use 183 It should be easy for both organizations and users to participate in 184 the roaming infrastructure as that may otherwise inhibit wide scale 185 adoption. In particular, there should be no or easy client 186 installation and only one-off configuration. 188 - Secure 189 An important design criterion has been that there needs to be a 190 security association between the end-user and their Identity 191 Provider, eliminating the possibility of credentials theft. The 192 minimal requirements for security are specified in the eduroam policy 193 and subject to change over time. As an additional protection against 194 user errors and negligence, it should be possible for participating 195 Identity Providers to set their own additional requirements for the 196 quality of authentication of their own users without the need for the 197 infrastructure as a whole to implement the same standard. 199 - Privacy preserving 201 The design of the system should provide for user anonymization, i.e. 202 a possibility to hide the user's identity from any third parties, 203 including Service Providers. 205 - Standards based 207 In an infrastructure in which many thousands of organizations 208 participate it is obvious that it should be possible to use equipment 209 from different vendors, therefore it is important to base the 210 infrastructure on open standards. 212 1.4. Solutions that were considered 214 Three architectures were trialed: one based on the use of VPN- 215 technology (deemed secure but not-scalable), one Web captive-portal 216 based (scalable but not secure) and IEEE 802.1X-based, the latter 217 being the basis of what is now the eduroam architecture 218 ([nrenroaming-select]). 220 The chosen architecture is based on: 222 o IEEE 802.1X ([dot1X-standard]) as port based authentication 223 framework using 225 o EAP ([RFC3748]) for integrity and confidentially protected 226 transport of credentials and a 228 o RADIUS ([RFC2865]) hierarchy as trust fabric. 230 2. Classic Architecture 232 Federations, like eduroam, implement essentially two types of direct 233 trust relations (and one indirect). The trust relation between an 234 end-user and the IdP (operated by the home organization of the user) 235 and between the IdP and the SP (in eduroam the operator of the 236 network at the visited location). In eduroam the trust relation 237 between user and IdP is through mutual authentication. IdPs and SP 238 establish trust through the use of a RADIUS hierarchy. 240 These two forms of trust relations in turn provide the transitive 241 trust relation that makes the SP trust the user to use its network 242 resources. 244 2.1. Authentication 246 Authentication in eduroam is achieved by using a combination of IEEE 247 802.1X [dot1X-standard] and EAP [RFC4372] (the latter carried over 248 RADIUS, see below). 250 2.1.1. IEEE 802.1X 252 By using the IEEE 802.1X [dot1X-standard] framework for port-based 253 network authentication, organizations that offer network access (SPs) 254 for visiting (and local) eduroam users can make sure that only 255 authorized users get access. The user (or rather the user's 256 supplicant) sends an access request to the authenticator (wireless 257 access point or switch) at the SP, the authenticator forwards the 258 access request to the authentication server of the SP which in turn 259 proxies the request through the RADIUS hierarchy to the 260 authentication server of the user's home organization (the IdP, see 261 below). 263 Note: The security of the connections between local wireless 264 infrastructure and local RADIUS servers is a part of the local 265 network of each SP, therefore it is out of scope for this document. 266 For completeness it should be stated that security between access 267 points and their controllers is vendor specific, security between 268 controllers (or standalone access points) and local RADIUS servers is 269 based on the typical RADIUS shared secret mechanism. 271 In order for users to be aware of the availability of the eduroam 272 service, an SP that offers wireless network access MUST broadcast the 273 SSID 'eduroam', unless that conflicts with the SSID of another 274 eduroam SP, in which case an SSID starting with "eduroam-" MAY be 275 used. The downside of the latter is that clients will not 276 automatically connect to that SSID, thus losing the seamless 277 connection experience. 279 Note: A direct implication of the common eduroam SSID is that the 280 users cannot distinguish between a connection to the home network and 281 a guest network at another eduroam institution (IEEE 802.11-2012 does 282 have the so-called "Interworking" extensions to make that 283 distinction, but these are not widely implemented yet). Therefore, 284 users should be made aware that they should not assume data 285 confidentiality in the eduroam infrastructure. 287 To protect over-the-air user data confidentiality, IEEE 802.11 288 wireless networks of eduroam SP's MUST deploy WPA2+AES, and MAY 289 additionally support WPA/TKIP as a courtesy to users of legacy 290 hardware. 292 2.1.2. EAP 294 The use of the Extensible Authentication Protocol (EAP) [RFC4372] 295 serves 2 purposes. In the first place a properly chosen EAP-method 296 allows for integrity and confidentiality protected transport of the 297 user credentials to the home organization. Secondly, by having all 298 RADIUS servers transparently proxy access requests regardless of the 299 EAP-method inside the RADIUS packet, the choice of EAP-method is 300 between the 'home' organization of the user and the user, in other 301 words, in principle every authentication form that can be carried 302 inside EAP can be used in eduroam, as long as they adhere to minimal 303 requirements as set forth in the eduroam Service Definition 304 [eduroam-service-definition]. 306 +-----+ 307 / \ 308 / \ 309 / \ 310 / \ 311 ,----------\ | | ,---------\ 312 | SP | | eduroam | | IdP | 313 | +----+ trust fabric +---+ | 314 `------+---' | | '-----+---' 315 | | | | 316 | \ / | 317 | \ / | 318 | \ / | 319 | \ / | 320 +----+ +-----+ +----+ 321 | | 322 | | 323 +---+--+ +--+---+ 324 | | | | 325 +-+------+-+ ___________________________ | | 326 | | O__________________________ ) +------+ 327 +----------+ 328 Host (supplicant) EAP tunnel Authentication server 330 Figure 1: Tunneled EAP 332 Proxying of access requests is based on the outer identity in the 333 EAP-message. Those outer identities MUST be a valid user identifier 334 with a mandatory realm as per [I-D.ietf-radext-nai], i.e. be of the 335 form something@realm or just @realm, where the realm part is the 336 domain name of the domain that the IdP belongs to. In order to 337 preserve credentials protection, participating organizations MUST 338 deploy EAP-methods that provide mutual authentication. For EAP 339 methods that support outer identity, anonymous outer identities are 340 recommended. Most commonly used in eduroam are the so-called 341 tunneled EAP-methods, that first create a server authenticated TLS 342 tunnel through which the user credentials are transmitted. As 343 depicted in Figure 1, the use of a tunneled EAP-method creates a 344 direct logical connection between the supplicant and the 345 authentication server, even though the actual traffic flows through 346 the RADIUS-hierarchy. 348 2.2. Federation Trust Fabric 350 The eduroam federation trust fabric is based on RADIUS. RADIUS trust 351 is based on shared secrets between RADIUS peers. In eduroam any 352 RADIUS message originating from a trusted peer is implicitly assumed 353 to originate from a member of the roaming consortium. 355 2.2.1. RADIUS 357 The eduroam trust fabric consists of a proxy hierarchy of RADIUS 358 servers (organizational, national, global), loosely based on the DNS 359 hierarchy. That is, typically an organizational RADIUS server agrees 360 on a shared secret with a national server and the national server in 361 turn agrees on a shared secret with the root server. Access requests 362 are routed through a chain of RADIUS proxies towards the Identity 363 Provider of the user, and the access accept (or reject) follows the 364 same path back. 366 Note: In some circumstances there are more levels of RADIUS servers, 367 like for example regional or continental servers, but that doesn't 368 change the general model. Also, the packet exchange that is 369 described below requires in reality several round-trips. 371 +-------+ 372 | | 373 | . | 374 | | 375 +---+---+ 376 / | \ 377 +----------------/ | \---------------------+ 378 | | | 379 | | | 380 | | | 381 +--+---+ +--+--+ +----+---+ 382 | | | | | | 383 | .edu | . . . | .nl | . . . | .ac.uk | 384 | | | | | | 385 +--+---+ +--+--+ +----+---+ 386 / | \ | \ | 387 / | \ | \ | 388 / | \ | \ | 389 +-----+ | +-----+ | +------+ | 390 | | | | | | 391 | | | | | | 392 +---+---+ +----+---+ +----+---+ +--+---+ +-----+----+ +-----+-----+ 393 | | | | | | | | | | | | 394 |utk.edu| |utah.edu| |case.edu| |hva.nl| |surfnet.nl| |soton.ac.uk| 395 | | | | | | | | | | | | 396 +----+--+ +--------+ +--------+ +------+ +----+-----+ +-----------+ 397 | | 398 | | 399 +--+--+ +--+--+ 400 | | | | 401 +-+-----+-+ | | 402 | | +-----+ 403 +---------+ 404 user: paul@surfnet.nl surfnet.nl Authentication server 406 Figure 2: eduroam RADIUS hierarchy 408 Routing of access requests to the home IdP is done based on the realm 409 part of the outer identity. For example (see: Figure 2), when user 410 paul@surfnet.nl of SURFnet (surfnet.nl) tries to gain wireless 411 network access at the University of Tennessee at Knoxville (utk.edu) 412 the following happens: 414 o Paul's supplicant transmits an EAP access request to the Access 415 Point (Authenticator) at UTK with outer identity say 416 anonymous@surfnet.nl 418 o The Access Point forwards the EAP message to its Authentication 419 Server (the UTK RADIUS server) 421 o The UTK RADIUS server checks the realm to see if it is a local 422 realm, since it isn't the request is proxied to the .edu RADIUS 423 server 425 o The .edu RADIUS server verifies the realm, and since it is not a 426 in a .edu subdomain it proxies the request to the root server 428 o The root RADIUS server proxies the request to the .nl RADIUS 429 server 431 o The .nl RADIUS server proxies the request to the surfnet.nl server 433 o The surfnet.nl RADIUS server decapsulates the EAP message and 434 verifies the user credentials 436 o The surfnet.nl RADIUS server informs the utk.edu server of the 437 outcome of the authentication request (Access-Accept or Access- 438 Reject) by proxying the outcome through the RADIUS hierarchy in 439 reverse order. 441 o The UTK RADIUS server instructs the UTK Access Point to either 442 accept or reject access based on the outcome of the 443 authentication. 445 Note: The depiction of the root RADIUS server is a simplification. 446 In reality the root server is distributed over 3 continents and each 447 maintains a list of the top level realms that a specific root server 448 is responsible for. This also means that, for intercontinental 449 roaming, there is an extra proxy step from one root server to the 450 other. 452 3. Issues with initial Trust Fabric 454 While the hierarchical RADIUS architecture described in the previous 455 section has served as the basis for eduroam operations for an entire 456 decade, the exponential growth of authentications is expected to lead 457 to, and has in fact in some cases already led to, performance and 458 operations bottlenecks on the aggregation proxies. The following 459 sections describe some of the shortcomings, and the resulting 460 remedies. 462 3.1. Server Failure Handling 464 In eduroam, authentication requests for roaming users are statically 465 routed through pre-configured proxies. The number of proxies varies: 466 in a national roaming case, the number of proxies is typically 1 or 2 467 (some countries deploy regional proxies, which are in turn aggregated 468 by a national proxy); in international roaming, 3 or 4 proxy servers 469 are typically involved (the number may be higher along some routes). 471 RFC2865 [RFC2865] does not define a failover algorithm. In 472 particular, the failure of a server needs to be deduced from the 473 absence of a reply. Operational experience has shown that this has 474 detrimental effects on the infrastructure and end user experience: 476 1. Authentication failure: the first user whose authentication path 477 is along a newly-failed server will experience a long delay and 478 possibly timeout 480 2. Wrongly deduced states: since the proxy chain is longer than 1 481 hop, a failure further along in the authentication path is 482 indistinguishable from a failure in the next hop. 484 3. Inability to determine recovery of a server: only a "live" 485 authentication request sent to a server which is believed 486 inoperable can lead to the discovery that the server is in 487 working order again. This issue has been resolved with RFC5997 488 [RFC5997]. 490 The second point can have significant impact on the operational state 491 of the system in a worst-case scenario: Imagine one realm's home 492 server being inoperable. A user from that realm is trying to roam 493 internationally and tries to authenticate. The RADIUS server on the 494 hotspot location will assume its own national proxy is down, because 495 it does not reply. That national server, being perfectly alive, in 496 turn will assume that the international aggregation proxy is down; 497 which in turn will believe the home country proxy national server is 498 down. None of these assumptions are true. Worse yet: should any of 499 these servers trigger a failover to a redundant backup RADIUS server, 500 it will still not receive a reply, because the request will still be 501 routed to the same defunct home server. Within a short time, all 502 redundant aggregation proxies might be considered defunct by their 503 preceding hop. 505 In the absence of proper next-hop state derivation, some interesting 506 concepts have been introduced by eduroam participants; the most 507 noteworthy being a failover logic which considers up/down states not 508 per next-hop RADIUS peer, but instead per realm (See [dead-realm] for 509 details). As of recent, RFC5997 [RFC5997] implementations and 510 cautious failover parameters make such a worst-case scenario very 511 unlikely to happen, but are still an important issue to consider. 513 3.2. No error condition signalling 515 The RADIUS protocol lacks signalling of error conditions, and the 516 IEEE 802.1X protocol does not allow to convey extended failure 517 reasons to the end-user's device. For eduroam, this creates issues 518 in a twofold way: 520 o The home server may have an operational problem, for example its 521 authentication decisions may depend on an external data source 522 such as ActiveDirectory or an SQL server, and the external data 523 source is unavailable. If the RADIUS interface is still 524 functional, there are two options how to reply to an Access- 525 Request which can't be serviced due to such error conditions: 527 1. Do Not Reply: the inability to reach a conclusion can be 528 treated by not replying to the request. The upside of this 529 approach is that the end-user's software doesn't come to wrong 530 conclusions and won't give unhelpful hints such as "maybe your 531 password is wrong". The downside is that intermediate proxies 532 may come to wrong conclusions because their downstream RADIUS 533 server isn't responding. 535 2. Reply with Reject: in this option, the inability to reach a 536 conclusion is treated like an authentication failure. The 537 upside of this approach is that intermediate proxies maintain 538 a correct view on the reachability state of their RADIUS peer. 539 The downside is that EAP supplicants on end-user devices often 540 react with either false advice ("your password is wrong") or 541 even trigger permanent configuration changes (e.g. the Windows 542 built-in supplicant will delete the credential set from its 543 registry, prompting the user for their password on the next 544 connection attempt). The latter case of Windows is a source 545 of significant helpdesk activity; users may have forgotten 546 their password after initially storing it, but are suddenly 547 prompted again. 549 There have been epic discussions in the eduroam community which of 550 the two approaches is more appropriate; but they were not conclusive. 552 o Similar considerations as above apply when an intermediate proxy 553 does not receive a reply from a downstream RADIUS server. The 554 proxy may either choose not to reply to the original request, 555 leading to retries and its upstream peers coming to wrong 556 conclusions about its own availability; or it may decide to reply 557 with Access-Reject to indicate its own liveliness, but again with 558 implications for the end user. 560 The ability to send Status-Server watchdog requests is only of use 561 after the fact, in case a downstream server doesn't reply (or hasn't 562 been contacted in a long while, so that it's previous working state 563 is stale). The active link-state monitoring of the TCP connection 564 with e.g. RADIUS/TLS (see below) gives a clearer indication whether 565 there is an alive RADIUS peer, but does not solve the defunct backend 566 problem. An explicit ability to send Error-Replies, on the RADIUS 567 (for other RADIUS peer information) and EAP level (for end-user 568 supplicant information), would alleviate these problems but is 569 currently not available. 571 3.3. Routing table complexity 573 The aggregation of RADIUS requests based on the structure of the 574 user's realm implies that realms ending with the same top-level 575 domain are routed to the same server; i.e. to a common administrative 576 domain. While this is true for country code Top Level Domains 577 (ccTLDs), which map into national eduroam federations, it is not true 578 for realms residing in generic Top Level Domains (gTLDs). Realms in 579 gTLDs were historically discouraged because the automatic mapping 580 "realm ending" -> "eduroam federation's server" could not be applied. 581 However, with growing demand from eduroam realm administrators, it 582 became necessary to create exception entries in the forwarding rules; 583 such realms need to be mapped on a realm-by-realm basis to their 584 eduroam federations. Example: "kit.edu" (Karsruher Institut fuer 585 Technologie) needs to be routed to the German federation server, 586 whereas "iu.edu" (Indiana University) needs to be routed to the USA 587 federation server. 589 While the ccTLDs occupy only approx. 50 routing entries in total (and 590 have a upper bound of approx. 200), the potential size of the routing 591 table becomes virtually unlimited if it needs to accomodate all 592 individual entries in .edu, .org, etc. 594 In addition to that, all these routes need to be synchronised between 595 three international root servers, and the updates need to be applied 596 manually to RADIUS server configuration files. The frequency of the 597 required updates makes this approach fragile and error-prone as the 598 number of entries grows. 600 3.4. UDP Issues 602 RADIUS is based on UDP, which was a reasonable choice when its main 603 use was with simple PAP requests which required only exactly one 604 packet exchange in each direction. 606 When transporting EAP over RADIUS, the EAP conversations requires 607 multiple round-trips; depending on the total payload size, 8-10 608 round-trips are not uncommon. The loss of a single UDP packet will 609 lead to user-visible delays and might result in servers being marked 610 as dead due to the absence of a reply. The proxy path in eduroam 611 consists of several proxies, all of which introduce a very small 612 packet loss probability; i.e. the more proxies are needed, the higher 613 the failure rate is going to be. 615 For some EAP types, depending on the exact payload size they carry, 616 RADIUS servers and/or supplicants may choose to fill as much EAP data 617 into a single RADIUS packet as the supplicant's layer 2 medium allows 618 for, typically 1500 Bytes. In that case, the RADIUS encapsulation 619 around the EAP-Message will add more bytes to the overall RADIUS 620 payload size and in the end exceed the 1500 Byte limit, leading to 621 fragmentation of the UDP datagram on the IP layer. While this is not 622 a problem in theory, practice has shown evidence of misbehaving 623 firewalls which erroneously discard non-first UDP fragments, which 624 ultimately leads to a denial of service for users with such EAP types 625 and that specific configuration. 627 One EAP type proved to be particularly problematic: EAP-TLS. While 628 it is possible to configure the EAP server to send smaller chunks of 629 EAP payload to the supplicant (e.g. 1200 Bytes, to allow for another 630 300 Bytes of RADIUS overhead without fragmentation), very often the 631 supplicants which send the client certificate do not expose such a 632 configuration detail to the user. Consequently, when the client 633 certificate is beyond 1500 Bytes in size, the EAP-Message will always 634 make use of the maximum possible layer-2 chunk size, which introduces 635 the fragmentation on the path from EAP peer to EAP server. 637 Both of the previously mentioned sources of errors (packet loss, 638 fragment discard) lead to significant frustration for the affected 639 users. Operational experience of eduroam shows that such cases are 640 hard to debug since they require coordinated cooperation of all 641 eduroam administrators on the authentication path. For that reason 642 the eduroam community is developing monitoring tools that help to 643 locate fragmentation problems. 645 3.5. Insufficient payload encryption and EAP server validation 647 The RADIUS protocol's design foresaw only the encryption of select 648 RADIUS attributes, most notably User-Password. With EAP methods 649 conforming to the requirements of [RFC4017], the user's credential is 650 not transmitted using the User-Password attribute, and stronger 651 encryption than the one for RADIUS' User-Password is in use 652 (typically TLS). 654 Still, the use of EAP does not encrypt all personally identifiable 655 details of the user session as some are carried inside clear-text 656 RADIUS attributes. In particular, the user's device can be 657 identified by inspecting the Calling-Station-ID attribute; and the 658 user's location may be derived from observing NAS-IP-Address, NAS- 659 Identifier or Operator-Name attributes. Since these attributes are 660 not encrypted, even IP-layer third parties can harvest the 661 corresponding data. In a worst-case scenario, this enables the 662 creation of mobility profiles. Pervasive passive surveillance using 663 this connection metadata such as the recently uncovered NSA/GCHQ 664 incidents becomes possible by tapping RADIUS traffic from an IP hop 665 near a RADIUS aggregation proxy. While this is possible, the authors 666 are not aware whether this has actually been done. 668 These profiles are not necessarily linkable to an actual user because 669 EAP allows for the use of anonymous outer identities and protected 670 credential exchanges. However, practical experience has shown that 671 many users neglect to configure their supplicants in a privacy- 672 preserving way or their supplicant doesn't support that. In 673 particular, for EAP-TLS users, the use of EAP-TLS identity protection 674 is not usually implemented and cannot be used. In eduroam, concerned 675 individuals and IdPs which use EAP-TLS are using pseudonymous client 676 certificates to provide for better privacy. 678 One way out, at least for EAP types involving a username, is to 679 pursue the creation and deployment of pre-configured supplicant 680 configurations which makes all the required settings in user devices 681 prior to their first connection attempt; this depends heavily on the 682 remote configuration possibilities of the supplicants though. 684 A further threat involves the verification of the EAP server's 685 identity. Even though the cryptographic foundation, TLS tunnels, is 686 sound, there is a weakness in the supplicant configuration: many 687 users do not understand or are willing to invest time into the 688 inspection of server certificates or the installation of a trusted 689 CA. As a result, users may easily be tricked into connecting to an 690 unauthorized EAP server, ultimately leading to a leak of their 691 credentials to that unauthorized third party. 693 Again, one way out of this particular threat is to pursue the 694 creation and deployment of pre-configured supplicant configurations 695 which makes all the required settings in user devices prior to their 696 first connection attempt. 698 Note: there are many different and vendor-proprietary ways to pre- 699 configure a device with the necessary EAP parameters (examples 700 include Apple, Inc's "mobileconfig" and Microsoft's "EAPHost" XML 701 schema). Some manufacturers even completely lack any means to 702 distribute EAP configuration data. We believe there is value in 703 defining a common EAP configuration metadata format which could be 704 used across manufacturers, ideally leading to a situation where IEEE 705 802.1X network end-users merely need to apply this configuration file 706 to configure any of their devices securely with the required 707 connection properties. 709 Another possible privacy threat involves transport of user-specific 710 attributes in a Reply-Message. If, for example, a RADIUS server 711 sends back a hypothetical RADIUS Vendor-Specific-Attribute "User-Role 712 = Student of Computer Science" (e.g. for consumption of an SP RADIUS 713 server and subsequent assignment into a "student" VLAN), this 714 information would also be visible for third parties and could be 715 added to the mobility profile. 717 The only way out to mitigate all information leakage to third parties 718 is by protecting the entire RADIUS packet payload so that IP-layer 719 third parties cannot extract privacy-relevant information. RFC2865 720 RADIUS does not offer this possibility though. 722 4. New Trust Fabric 724 The operational difficulties with an ever increasing number of 725 participants, as documented in the previous section, have led to a 726 number of changes to the eduroam architecture that in turn have, as 727 mentioned in the introduction, led to standardization effort. 729 Note: The enhanced architecture components are fully backwards 730 compatible with the existing installed base, and are in fact 731 gradually replacing those parts of it where problems may arise. 733 Whereas the user authentication using IEEE 802.1X and EAP has 734 remained unchanged (i.e. no need for end-users to change any 735 configurations), the issues as reported above have resulted in a 736 major overhaul of the way EAP messages are transported from the 737 RADIUS server of the SP to that of the IdP and back. The two 738 fundamental changes are the use of TCP instead of UDP and reliance on 739 TLS instead of shared secrets between RADIUS peers. 741 4.1. RADIUS with TLS 743 The deficiencies of RADIUS over UDP as described in Section 3.4 744 warranted a search for a replacement of RFC2865 [RFC2865] for the 745 transport of EAP. By the time this need was understood, the 746 designated successor protocol to RADIUS, Diameter [RFC3588], was 747 already specified by the IETF. However, within the operational 748 constraints of eduroam: 750 o reasonably cheap to deploy on many administrative domains 752 o supporting NASREQ Application 754 o supporting EAP Application 756 o supporting Diameter Redirect 758 o supporting validation of authentication requests of the most 759 popular EAP types (EAP-TTLS, PEAP, and EAP-TLS) 761 o possibility to retrieve these credentials from popular backends 762 such as Microsoft ActiveDirectory, MySQL 764 no single implementation could be found. In addition to that, no 765 Wireless Access Points at the disposal of eduroam participants 766 supported Diameter, nor did any of the manufacturers have a roadmap 767 towards Diameter support. This led to the open question of lossless 768 translation from RADIUS to Diameter and vice versa; a question not 769 satisfactorily answered by NASREQ. 771 After monitoring the Diameter implementation landscape for a while, 772 it became clear that a solution with better compatibility and a 773 plausible upgrade path from the existing RADIUS hierarchy was needed. 774 The eduroam community actively engaged in the IETF towards the 775 specification of several enhancements to RADIUS to overcome the 776 limitations mentioned in Section 3. The outcome of this process was 777 [RFC6614] and [I-D.ietf-radext-dynamic-discovery]. 779 With its use of TCP instead of UDP, and with its full packet 780 encryption, while maintaining full packet format compatibility with 781 RADIUS/UDP, RADIUS/TLS [RFC6614] allows to upgrade any given RADIUS 782 link in eduroam without the need of a "flag day". 784 In a first upgrade phase, the classic eduroam hierarchy (forwarding 785 decision taken by inspecting the realm) remains intact. That way, 786 RADIUS/TLS merely enhances the underlying transport of the RADIUS 787 datagrams. But this already provides some key advantages: 789 o explicit peer reachability detection using long-lived TCP sessions 791 o protection of user credentials and all privacy-relevant RADIUS 792 attributes 794 RADIUS/TLS connections for the static hierarchy could be realised 795 with the TLS-PSK operation mode (which effectively provides a 1:1 796 replacement for RADIUS/UDP's "shared secrets"), but since this 797 operation mode is not widely supported as of yet, all RADIUS/TLS 798 links in eduroam are secured by TLS with X.509 certificates from a 799 set of accredited CAs. 801 This first deployment phase does not yet solve the routing table 802 complexity problem (see (Section 3.3); this aspect is covered by 803 introducing dynamic discovery for RADIUS/TLS servers. 805 4.2. Dynamic Discovery 807 When introducing peer discovery, two separate issues had to be 808 addressed: 810 1. How to find the network address of a responsible RADIUS server 811 for a given realm? 813 2. How to verify that this realm is an authorized eduroam 814 participant? 816 4.2.1. Discovery of responsible server 818 Issue 1 can relatively simply be addressed by putting eduroam- 819 specific service discovery information into the global DNS tree. In 820 eduroam this is done by using Naming Authority Pointer (NAPTR) 821 records as per the S-NAPTR specification [RFC3958] with a private-use 822 NAPTR service tag ("x-eduroam:radius.tls"). The usage profile of 823 that NAPTR resource record is that exclusively "S" type delegations 824 are allowed, and that no regular expressions are allowed. 826 A subsequent lookup of the resulting SRV records will eventually 827 yield hostnames and IP addresses of the authoritative server(s) of a 828 given realm. 830 Example (wrapped for readability): 832 > dig -t naptr education.example. 834 ;; ANSWER SECTION: 835 education.example. 43200 IN NAPTR 100 10 "s" 836 "x-eduroam:radius.tls" "" 837 _radsec._tcp.eduroam.example. 839 > dig -t srv _radsec._tcp.eduroam.example. 841 ;; ANSWER SECTION: 842 _radsec._tcp.eduroam.example. 43200 IN SRV 0 0 2083 843 tld1.eduroam.example. 845 > dig -t aaaa tld1.eduroam.example. 847 ;; ANSWER SECTION: 848 tld1.eduroam.example. 21751 IN AAAA 2001:db8:1::2 850 Figure 3: SRV record lookup 852 From the operational experience with this mode of operation, eduroam 853 is pursuing standardisation of this approach for generic AAA use 854 cases. The current radext working group document for this is 855 [I-D.ietf-radext-dynamic-discovery]. 857 4.2.2. Verifying server authorisation 859 Any organisation can put "x-eduroam" NAPTR entries into their Domain 860 Name Server, pretending to be eduroam Identity Provider for the 861 corresponding realm. Since eduroam is a service for a heterogeneous, 862 but closed, user group, additional sources of information need to be 863 consulted to verify that a realm with its discovered server is 864 actually an eduroam participant. 866 The eduroam consortium has chosen to deploy a separate PKI 867 infrastructure which issues certificates only to authorised eduroam 868 Identity Providers and eduroam Service Providers. Since certificates 869 are needed for RADIUS/TLS anyway, this was a straightforward 870 solution. The PKI fabric allows multiple CAs as trust roots 871 (overseen by a Policy Management Authority), and requires that 872 certificates which were issued to verified eduroam participants are 873 marked with corresponding "X509v3 Policy OID" fields; eduroam RADIUS 874 servers and clients need to verify the existence of these OIDs in the 875 incoming certificates. 877 The policies and OIDs can be retrieved from the "eduPKI Trust Profile 878 for eduroam Certificates" ([edupki]). 880 4.2.3. Operational Experience 882 The discovery model as described above is currently deployed in 883 approximately 10 countries that participate in eduroam, making more 884 than 100 realms discoverable via their NAPTR records. Experience has 885 shown that the model works and scales as expected; the only drawback 886 being that the additional burden of operating a PKI which is not 887 local to the national eduroam administrators creates significant 888 administrative complexities. Also, the presence of multiple CAs and 889 regular updates of Certificate Revocation Lists makes the operation 890 of RADIUS servers more complex. 892 4.2.4. Possible Alternatives 894 There are two alternatives to the above approach which are monitored 895 by the eduroam community: 897 1. DNSSEC + DANE TLSA records 899 2. ABFAB Trust Router 901 For DNSSEC+DANE TLSA, its biggest advantage is that the certificate 902 data itself can be stored in the DNS - possibly obsoleting the PKI 903 infrastructure *if* a new place for the server authorization checks 904 can be found. Its most significant downside is that the DANE 905 specifications only include client-to-server certificate checks, 906 while RADIUS/TLS requires also server-to-client verification. 908 For the ABFAB Trust Router, the biggest advantage is that it would 909 work without certificates altogether (by negotiating TLS-PSK keys ad- 910 hoc). The downside is that it is currently not formally specified 911 and not as thoroughly understood as any of the other solutions. 913 5. Abuse prevention and incident handling 915 Since the eduroam service is a confederation of autonomous networks, 916 there is little justification for transferring accounting information 917 from the Service Provider to any other in general, or in particular 918 to the Identity Provider of the user. Accounting in eduroam is 919 therefore considered to be a local matter of the Service Provider. 920 The eduroam compliance statement ([eduroam-compliance]) in fact 921 specifies that accounting traffic SHOULD NOT be forwarded. 923 The static routing infrastructure of eduroam acts as a filtering 924 system blocking accounting traffic from misconfigured local RADIUS 925 servers. Proxy servers are configured to terminate accounting 926 request traffic by answering to Accounting-Requests with an 927 Accounting-Response in order to prevent the retransmission of 928 orphaned Accounting-Request messages. With dynamic discovery, 929 Identity Providers which are discoverable via DNS will need to apply 930 these filtering measures themselves. This is an increase in 931 complexity of the Identity Provider RADIUS configuration. 933 Roaming creates accountability problems, as identified by [RFC4372] 934 (Chargeable User Identity). Since the NAS can only see the (likely 935 anonymous) outer identity of the user, it is impossible to correlate 936 usage with a specific user (who may use multiple devices). A NAS 937 that supports this can request the Chargeable-User-Identity and, if 938 supplied by the authenticating RADIUS server in the Access-Accept 939 message, add this value to corresponding Access-Request packets. 940 While eduroam does not have any charging mechanisms, it may still be 941 desirable to identify traffic originating from one particular user. 942 One of the reasons is to prevent abuse of guest access by users 943 living nearby university campuses. Chargeable User Identity (see 944 below) supplies the perfect answer to this problem, however at the 945 moment of writing, to our knowledge only one hardware vendor (Meru 946 Networks) implements RFC4372 on their Access Points. For all other 947 vendors, requesting the Chargeable-User-Identity attribute needs to 948 happen on the RADIUS server to which the Access Point is connected 949 to. FreeRADIUS supports this ability in the latest distribution, and 950 Radiator can be retrofitted to do the same. 952 5.1. Incident Handling 954 10 years of experience with eduroam have not exposed any serious 955 incident. This may be taken as evidence for proper security design 956 as well as suggest that awareness of users that they are 957 identifiable, acts as an effective deterrent. It could of course 958 also mean that eduroam operations lack the proper tools or insight 959 into the actual use and potential abuse of the service. In any case, 960 many of the attack vectors that exist in open networks or networks 961 where access control is based on shared secrets are not present, 962 arguably leading to a much more secure system. 964 The European eduroam policy Service Definition 965 [eduroam-service-definition], as an example, describes incident 966 scenarios and actions to be taken, in this document we present the 967 relevant technical issues. 969 The initial implementation has been lacking reliable tools for an SP 970 to make it's own decision or for an IdP to introduce a conditional 971 rule applying only to a given SP. The introduction of support for 972 Operator-Name and Chargeable-User-Identity (see below) to eduroam 973 makes both of these scenarios possible. 975 5.1.1. Blocking users on the SP side 977 The first action in the case of an incident is to block the user's 978 access to eduroam at the Service Provider. Since the roaming user's 979 true identity is likely hidden behind an anonymous/fake outer 980 identity, the Service Provider can only rely on the realm of the user 981 and his MAC address; if the Identity Provider has already sent a 982 Chargeable-User-Identity (see Section 5.3 for details), then this 983 extra information can be used to identify the user more reliably. 985 A first attempt at the SP side may be to block based on the MAC 986 address or outer identity. This blocking can be executed before the 987 EAP authentication occurs - typically in the first datagram, acting 988 on the RADIUS attributes EAP-Message/EAP-Response/Identity and 989 Calling-Station-ID. The datagram can either be dropped (supplicant 990 notices a time-out) or replied-to with a RADIUS Access-Reject 991 containing an EAP-Failure. Since malicious users can change both 992 their MAC addresses and the local part of their outer identity 993 between connection attempts, this first attempt is not sufficient to 994 lock out a determined user. 996 As a second measure, the SP can let the EAP authentication proceed as 997 normal, and verify whether the final Access-Accept response from the 998 RADIUS server contains a Chargeable-User-Identity (CUI). If so, the 999 SP RADIUS server can be configured to turn all future Access- Accepts 1000 for this CUI into an Access-Reject/EAP-Failure. This measure is 1001 effective and efficient: it locks out exactly the one user which is 1002 supposed to be locked out, and has no side-effects on other users, 1003 even from the same realm. 1005 If the EAP authentication does not reveal a CUI, the SP can not 1006 reliably determine the user in question. The only reliable 1007 information to act upon is then the realm portion of the outer 1008 identity of the user. The SP will need to resort to blocking the 1009 entire realm that the offending user belongs to. This can be done at 1010 the EAP-Message/EAP-Repsonse/Identity stage as described above). 1011 This is effective, but not efficient: it locks out the user in 1012 question, but has a DoS side-effect on all other visiting users from 1013 the same realm. 1015 In the absence of a CUI handle, SPs which are not willing to take the 1016 drastic step of blocking an entire realm will be forced to contact 1017 the Identity Provider in question and demand that the user be blocked 1018 at the IdP side. This involves human interaction between SP and IdP 1019 is not possible in real-time. 1021 5.1.2. Blocking users on the IdP side 1023 The IdP has the power to disable a user account altogether, thus 1024 blocking this user from accessing eduroam in all sites. If blocking 1025 the user is done due a request of an SP (as per the previous 1026 section), there may be a more fine-grained possibility to block 1027 access to a specific SP - if the SP in question sends the Operator- 1028 Name attribute along with his Access-Requests (see Section 5.2 for 1029 details). 1031 If the IdP decides to block the user globally, this is typically done 1032 by treating the login attempt as if the credentials were wrong: the 1033 entire EAP conversation needs to be executed to the point where the 1034 true inner identity is revealed (before that, the IdP does not know 1035 yet which user is attempting to authenticate). This typically 1036 coincides with the point in time where credentials are exchanged. 1037 Instead, or in addition to, checking the credential for validity, the 1038 Identity Provider also checks whether the user's account is (still) 1039 eligible for eduroam use and will return an Access- Reject/EAP- 1040 Failure if not. 1042 There may well be cases where opinions between the SP desiring a user 1043 lockout and the IdP of the user differ. E.g. an SP might consider 1044 massive amounts of up-/downloads with file sharing protocols 1045 unacceptable as per local policy, and desire blocking of users that 1046 create too much traffic - but the IdP does not take offense on such 1047 actions and would not want to lock his user out of eduroam globally 1048 because of this one SP's opinion. 1050 In the absence of the Operator-Name attribute, there is no way to 1051 apply a login restriction only for a given SP and not eduroam as a 1052 whole; eduroam eligibility is an all-or-nothing decision for the IdP. 1054 If the Operator-Name attribute is present, the IdP can use this 1055 information to fail the authentication attempt only if the attempt 1056 originated from SPs which desire such blocking. Even though the 1057 Operator-Name attribute is available from the first RADIUS Access- 1058 Request datagram onwards, the EAP authentication needs to be carried 1059 out until the true inner identity is known just as in the global 1060 blocking case above. The Operator-Name is simply an additional piece 1061 of information which the IdP can use to make its decision. 1063 5.1.3. Communicating account blocking to the end user 1065 All the measures above alter the EAP conversation. They either 1066 create a premature rejection or timeout at the start of the 1067 conversation, or change the outcome of the authentication attempt at 1068 the very end of the conversation. 1070 On the supplicant side, these alterations are undistinguishable from 1071 an infrastructure failure: a premature rejection or timeout could be 1072 due to a RADIUS server being unresponsive, and a rejection at the end 1073 of the conversation could be either user error (wrong password) or 1074 server error (credential lookup failed). For the supplicant, it is 1075 thus difficult to communicate a meaningful error to the user. The 1076 newly specified EAP type TEAP, "Tunnel Extensible Authentication 1077 Protocol" [RFC7170] has a means to transport fine-grained error 1078 reason codes to the supplicant; this has the potential to improve the 1079 situation in the future. 1081 The EAP protocol foresees one mechanism to provide such user- 1082 interactive communication: the EAP state machine contains states 1083 which allow user-visible communication: an extra round of EAP- 1084 Request/Notification and the corresponding acknowledgement can be 1085 injected before the final EAP-Failure. 1087 However, anecdotal evidence suggests that supplicants typically do 1088 not implement this part of the EAP state machine at all. One 1089 supplicant is reported to support it, but only logs the contents of 1090 the notification in a log file - which is not at all helpful for the 1091 end user. 1093 The discovery of reasons and scope of account blocking are thus left 1094 as an out-of-band action. The eduroam user support process requires 1095 that users with authentication problems contact their Identity 1096 Provider as a first measure (via unspecified means, e.g. they could 1097 phone their IdP or send an email via a 3G backup link). If the 1098 Identity Provider is the one which blocked their access, the user 1099 will immediately be informed by them. If the reason for blocking is 1100 at the SP side, the Identity Provider will instead inform the user 1101 that the account is in working order and that the user needs to 1102 contact the SP IT support to get further insight. In that case, that 1103 SP-side IT support will notify the users about the reasons for 1104 blocking. 1106 5.2. Operator Name 1108 The Operator-Name attribute is defined in [RFC5580] as a means of 1109 unique identification of the access site. 1111 The Proxy infrastructure of eduroam makes it impossible for home 1112 sites to tell where their users roam to. While this may be seen as a 1113 positive aspect enhancing user's privacy, it also makes user support, 1114 roaming statistics and blocking offending user's access to eduroam 1115 significantly harder. 1117 Sites participating in eduroam are encouraged to add the Operator- 1118 Name attribute using the REALM namespace, i.e. sending a realm name 1119 under control of the given site. 1121 The introduction of Operator-Name in eduroam has identified one 1122 operational problem - the identifier 126 assigned to this attribute 1123 has been previously used by some vendors for their specific purposes 1124 and has been included in attribute dictionaries of several RADIUS 1125 server distributions. Since the syntax of this hijacked attribute 1126 had been set to Integer, this introduces a syntax clash with the the 1127 RFC definition (OctetString). Operational tests in eduroam have 1128 shown that servers using the Integer syntax for attribute 126 may 1129 either truncate the value to 4 octets or even drop the entire RADIUS 1130 packet (thus making authentication impossible). The eduroam 1131 monitoring and eduroam test tools try to locate problematic sites. 1133 When a Service Provider sends its Operator-Name value, it creates a 1134 possibility for the home sites to set up conditional blocking rules, 1135 depriving certain users of access to selected sites. Such action 1136 will cause much less concern than blocking users from all of eduroam. 1138 In eduroam the Operator Name is also used for the generation of 1139 Chargeable User Identity values. 1141 The addition of Operator-Name is a straightforward configuration of 1142 the RADIUS server and may be easily introduced on a large scale. 1144 5.3. Chargeable User Identity 1146 The Chargeable-User-Identity (CUI) attribute is defined by RFC4372 1147 [RFC4372] as an answer to accounting problems caused by the use of 1148 anonymous identity in some EAP methods. In eduroam the primary use 1149 of CUI is in incident handling, but it can also enhance local 1150 accounting. 1152 The eduroam policy requires that a given user's CUI generated for 1153 requests originating from different sites should be different (to 1154 prevent collusion attacks). The eduroam policy thus mandates that a 1155 CUI request be accompanied by the Operator-Name attribute, which is 1156 used as one of the inputs for the CUI generation algorithm. The 1157 Operator-Name requirement is considered to be the "business 1158 requirement" described in Section 2.1 of RFC4372 [RFC4372] and hence 1159 conforms to the RFC. 1161 When eduroam started considering using CUI, there were no NAS 1162 implementations, therefore the only solution was moving all CUI 1163 support to the RADIUS server. 1165 CUI request generation requires only the addition of NUL CUI 1166 attributes to outgoing Access-Requests, however the real strength of 1167 CUI comes with accounting. Implementation of CUI based accounting in 1168 the server requires that the authentication and accounting RADIUS 1169 servers used directly by the NAS are actually the same or at least 1170 have access to a common source of information. Upon processing of an 1171 Access-Accept the authenticating RADIUS server must store the 1172 received CUI value together with the device's Calling-Station-Id in a 1173 temporary database. Upon receipt of an Accounting-Request, the 1174 server needs to update the packet with the CUI value read from the 1175 database. 1177 A wide introduction of CUI support in eduroam will significantly 1178 simplify incident handling at Service Providers. Introducing local, 1179 per-user access restriction will be possible. Visited sites will 1180 also be able to notify the home site about the introduction of such a 1181 restriction, pointing to the CUI value and thus making it possible 1182 for the home site to identify the user. When the user reports the 1183 problem at his home support, the reason will be already known. 1185 6. Privacy Considerations 1187 The eduroam architecture has been designed with protection of user 1188 credentials in mind as may be clear from the discussion above. 1189 However, operational experience has revealed some more subtle points 1190 with regards to privacy. 1192 6.1. Collusion of Service Providers 1194 If users use anonymous outer identities, SPs cannot easily collude by 1195 linking outer identities to users that are visiting their campus. 1196 This poses however problems with remediation of abuse or 1197 misconfiguration. It is impossible to find the user that exhibits 1198 unwanted behaviour or whose system has been compromised. 1200 For that reason the Chargeable-User-Identity has been introduced in 1201 eduroam, constructed so that only the IdP of the user can uniquely 1202 identify the user. In order to prevent collusion attacks that CUI is 1203 required to be unique per user per Service Provider. 1205 6.2. Exposing user credentials 1207 Through the use of EAP, user credentials are not visible to anyone 1208 but the IdP of the user. That is, if a sufficiently secure EAP- 1209 method is chosen. 1211 There is one privacy sensitive user attribute that is necessarily 1212 exposed to third parties and that is the realm the user belongs to. 1214 Routing in eduroam is based on the realm part of the user identifier, 1215 so even though the outer identity in a tunneled EAP-method may be set 1216 to an anonymous identifier it MUST contain the realm of the user, and 1217 may thus lead to identifying the user if the realm in question 1218 contains few users. This is considered a reasonable trade-of between 1219 user privacy and usability. 1221 6.3. Track location of users 1223 Due to the fact that access requests (potentially) travel through a 1224 number of proxy RADIUS servers, the home IdP of the user typically 1225 cannot tell where a user roams to. 1227 The introduction of Operator-Name and dynamic lookups (i.e. direct 1228 connections between IdP and SP) however, give the home IdP insight 1229 into the location of the user. 1231 7. Security Considerations 1233 This section addresses only security considerations associated with 1234 the use of eduroam. For considerations relating to IEEE 802.1X, 1235 RADIUS and EAP in general, the reader is referred to the respective 1236 specification and to other literature. 1238 7.1. Man in the middle and Tunneling Attacks 1240 The security of user credentials in eduroam ultimately lies within 1241 the EAP server verification during the EAP conversation. Therefore, 1242 the eduroam policy mandates that only EAP types capable of mutual 1243 authentication are allowed in the infrastructure, and requires that 1244 IdPs publish all information that is required to uniquely identify 1245 the server (i.e. usually the EAP server's CA certificate and its 1246 Common Name or subjectAltName:dNSName). 1248 While this in principle makes Man-in-the-middle attacks impossible, 1249 practice has shown that several attack vectors exist nonetheless. 1250 Most of these deficiencies are due to implementation shortcomings in 1251 EAP supplicants. Examples: 1253 7.1.1. Verification of Server Name not supported 1255 Some supplicants only allow to specify which CA issues the EAP server 1256 certificate; it's name is not checked. As a result, any entity that 1257 is able to get a server certificate from the same CA can create its 1258 own EAP server and trick the end user to submit his credentials to 1259 that fake server. 1261 As a mitigation to that problem, eduroam Operations suggests the use 1262 of a private CA which exclusively issues certificates to the 1263 organisation's EAP servers. In that case, no other entity will get a 1264 certificate from the CA and the above supplicant shortcoming does not 1265 present a security threat any more. 1267 7.1.2. Neither Specification of CA nor Server Name checks during 1268 bootstrap 1270 Some supplicants allow for insecure bootstrapping in that they allow 1271 to simply select a network and accept the incoming server 1272 certificate, identified by its fingerprint. The certificate is then 1273 saved as trusted for later re-connection attempts. If users are near 1274 a fake hotspot during initial provisioning, they may be tricked to 1275 submit their credentials to a fake server; and furthermore will be 1276 branded to trust only that fake server in the future. 1278 eduroam Identity Providers are advised to provide their users with 1279 complete documentation for setup of their supplicants without the 1280 shortcut of insecure bootstrapping. In addition, eduroam Operations 1281 has created a tool which makes correct, complete and secure settings 1282 on many supplicants: eduroam CAT ([eduroam-cat] ). 1284 7.1.3. User does not configure CA or Server Name checks 1286 Unless automatic provisioning tools such as eduroam CAT are used, it 1287 is cumbersome for users to initially configure an EAP supplicant 1288 securely. User Inferfaces of supplicants often invite the users to 1289 take shortcuts ("Don't check server certificate") which are easier to 1290 setup or hide important security settings in badly accessible sub- 1291 menus. Such shortcuts or security parameter ommissions make the user 1292 subject to man-in-the-middle attacks. 1294 eduroam IdPs are advised to educate their users regarding the 1295 necessary steps towards a secure setup. eduroam Research and 1296 Development is in touch with supplicant developers to improve their 1297 User Interfaces. 1299 7.1.4. Tunneling authentication traffic to obfuscate user origin 1301 There is no link between the EAP outer ("anonymous") identity and the 1302 EAP inner ("real") identity. In particular, they can both contain a 1303 realm name, and the realms need not be identical. It is possible to 1304 craft packets with an outer identity of user@RealmB, and an inner 1305 identity of user@realmA. With the eduroam request routing, a Service 1306 Provider would assume that the user is from realmB and send the 1307 request there. The server at realm B inspects the inner user name, 1308 and if proxying is not explicitly disabled for tunneled request 1309 content, may decide to send the tunneled EAP payload to realmA, where 1310 the user authenticates. A CUI value would likely be generated by the 1311 server at realmB, even though this is not its user. 1313 Users can craft such packets to make their identification harder; 1314 usually, the eduroam SP would assume the troublesome user to 1315 originate from realmB and demand there that the user be blocked. The 1316 operator of realmB however has no control over the user, and can only 1317 trace back the user to his real origin if logging of proxied requests 1318 is also enabled for EAP tunnel data. 1320 eduroam Identity Providers are advised to explicitly disable proxying 1321 on the parts of their RADIUS server configuration which processes EAP 1322 tunnel data. 1324 7.2. Denial of Service Attacks 1326 Since eduroam's roaming infrastructure is based on IP and RADIUS, it 1327 suffers from the usual DoS attack vectors that apply to these 1328 protocols. 1330 The eduroam hotspots are susceptible to typical attacks on consumer 1331 edge networks, such as rogue RA, rogue DHCP servers, and others. 1332 Notably, eduroam hotspots are more robust against malign users' DHCP 1333 pool exhaustion than typical open or "captive portal" hotspots, 1334 because a DHCP address is only leased after a successful 1335 authentication, which reduces the pool of possible attackers to 1336 eduroam account holders (as opposed to the general public). 1337 Furthermore, attacks involving ARP spoofing or ARP flooding are also 1338 reduced to authenticated users, because an attacker needs to be in 1339 possession of a valid WPA2 session key to be able to send traffic on 1340 the network. 1342 This section does not discuss standard threats to consumer edge 1343 networks and IP networks in general. The following sections describe 1344 attack vectors specific to eduroam. 1346 7.2.1. Intentional DoS by malign individuals 1348 The eduroam infrastructure is more robust against Distributed DoS 1349 attacks than typical services which are reachable on the internet 1350 because triggering authentication traffic can only be done when 1351 physically being in proximity of an eduroam hotspot (be it a wired 1352 IEEE 802.1X enabled socket or a Wi-Fi Access Point). 1354 However, when being in the vicinity, it is easy to craft 1355 authentication attempts that traverse the entire international 1356 eduroam infrastructure; an attacker merely needs to choose a realm 1357 from another world region than his physical location to trigger 1358 Access-Requests which need to be processed by the SP, then SP-side 1359 national, then world region, then target world region, then target 1360 national, then target IdP server. So long as the realm actually 1361 exists, this will be followed by an entire EAP conversation on that 1362 path. Not having actual credentials, the request will ultimately be 1363 rejected; but it consumed processing power and bandwidth across the 1364 entire infrastructure, possibly affecting all international 1365 authentication traffic. 1367 EAP is a lock-step protocol. A single attacker at an eduroam hotspot 1368 can only execute one EAP conversation after another, and is thus 1369 rate-limited by round-trip times of the RADIUS chain. 1371 Currently eduroam processes several hundred thousands of successful 1372 international roaming authentications per day (and, incidentally, 1373 approximately 1.5 times as many Access-Rejects). With the 1374 requirement of physical proximity, and the rate-limiting induced by 1375 EAP's lock-step nature, it requires a significant amount of attackers 1376 and a time-coordinated attack to produce significant load. So far 1377 eduroam Operations has not yet observed critical load conditions 1378 which could reasonably be attributed to such an attack. 1380 The introduction of dynamic discovery further eases this problem, as 1381 authentications will then not traverse all infrastructure servers, 1382 removing the world-region aggregation servers as obvious bottlenecks. 1383 Any attack would then be limited between an SP and IdP directly. 1385 7.2.2. DoS as a side-effect of expired credentials 1387 In eduroam Operations it is observed that a significant portion of 1388 (failed) eduroam authentications is due to user accounts which were 1389 once valid, but have in the meantime been de-provisioned (e.g. if a 1390 student has left the university after graduation). Configured 1391 eduroam accounts are often retained on the user devices, and when in 1392 the vicinity of an eduroam hotspot, the user device's operating 1393 system will attempt to connect to this network. 1395 As operation of eduroam continues, the amount of devices with left- 1396 over configurations is growing, effectively creating a pool of 1397 devices which produce unwanted network traffic whenever they can. 1399 Up until recently, this problem did not emerge with much prominence, 1400 because there is also a natural shrinking of that pool of devices due 1401 to users finally de-commissioning their old computing hardware. 1403 As of recent, particularly smartphones are programmed to make use of 1404 cloud storage and online backup mechanisms which save most, or all, 1405 configuration details of the device with a third-party. When 1406 renewing their personal computing hardware, users can restore the old 1407 settings onto the new device. It has been observed that expired 1408 eduroam accounts can survive perpetually on user devices that way. 1409 If this trend continues, it can be pictured that an always-growing 1410 pool of devices will clog up eduroam infrastructure with doomed-to- 1411 fail authentication requests. 1413 There is not currently a useful remedy to this problem, other than 1414 instructing users to manually delete their configuration in due time. 1415 Possible approaches to this problem are: 1417 o Creating a culture of device provisioning where the provisioning 1418 profile contains a "ValidUntil" property, after which the 1419 configuration needs to be re-validated or disabled. This requires 1420 a data format for provisioning as well as implementation support. 1422 o Improvements to supplicant software so that it maintains state 1423 over failed authentications. E.g. if a previously known-working 1424 configuration failed to authenticate consistently for 30 calendar 1425 days, it should be considered stale and be disabled. 1427 8. IANA Considerations 1429 There are no IANA Considerations 1431 9. References 1433 9.1. Normative References 1435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1436 Requirement Levels", BCP 14, RFC 2119, March 1997. 1438 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1439 "Remote Authentication Dial In User Service (RADIUS)", RFC 1440 2865, June 2000. 1442 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1444 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1445 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1446 3748, June 2004. 1448 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 1449 for Transport Layer Security (TLS)", RFC 4279, December 1450 2005. 1452 [RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, 1453 "Chargeable User Identity", RFC 4372, January 2006. 1455 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 1456 Aboba, "Dynamic Authorization Extensions to Remote 1457 Authentication Dial In User Service (RADIUS)", RFC 5176, 1458 January 2008. 1460 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1461 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1463 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1464 Authentication Protocol (EAP) Key Management Framework", 1465 RFC 5247, August 2008. 1467 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1468 Housley, R., and W. Polk, "Internet X.509 Public Key 1469 Infrastructure Certificate and Certificate Revocation List 1470 (CRL) Profile", RFC 5280, May 2008. 1472 [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. 1473 Aboba, "Carrying Location Objects in RADIUS and Diameter", 1474 RFC 5580, August 2009. 1476 [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote 1477 Authentication Dial In User Service (RADIUS) Protocol", 1478 RFC 5997, August 2010. 1480 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1481 Extension Definitions", RFC 6066, January 2011. 1483 [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012. 1485 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 1486 "Transport Layer Security (TLS) Encryption for RADIUS", 1487 RFC 6614, May 2012. 1489 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1490 Morris, J., Hansen, M., and R. Smith, "Privacy 1491 Considerations for Internet Protocols", RFC 6973, July 1492 2013. 1494 9.2. Informative References 1496 [I-D.ietf-abfab-arch] 1497 Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. 1498 Schaad, "Application Bridging for Federated Access Beyond 1499 Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work 1500 in progress), July 2014. 1502 [I-D.ietf-radext-dtls] 1503 DeKok, A., "DTLS as a Transport Layer for RADIUS", draft- 1504 ietf-radext-dtls-13 (work in progress), July 2014. 1506 [I-D.ietf-radext-dynamic-discovery] 1507 Winter, S. and M. McCauley, "NAI-based Dynamic Peer 1508 Discovery for RADIUS/TLS and RADIUS/DTLS", draft-ietf- 1509 radext-dynamic-discovery-11 (work in progress), March 1510 2014. 1512 [I-D.ietf-radext-nai] 1513 DeKok, A., "The Network Access Identifier", draft-ietf- 1514 radext-nai-06 (work in progress), June 2014. 1516 [MD5-attacks] 1517 Black, J., Cochran, M., and T. Highland, "A Study of the 1518 MD5 Attacks: Insights and Improvements", October 2006, 1519 . 1521 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 1522 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 1524 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1525 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1527 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 1528 Service Location Using SRV RRs and the Dynamic Delegation 1529 Discovery Service (DDDS)", RFC 3958, January 2005. 1531 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1532 Authentication Protocol (EAP) Method Requirements for 1533 Wireless LANs", RFC 4017, March 2005. 1535 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1536 Key Management", BCP 107, RFC 4107, June 2005. 1538 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1539 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1541 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 1542 4953, July 2007. 1544 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1545 Verification of Domain-Based Application Service Identity 1546 within Internet Public Key Infrastructure Using X.509 1547 (PKIX) Certificates in the Context of Transport Layer 1548 Security (TLS)", RFC 6125, March 2011. 1550 [RFC6421] Nelson, D., "Crypto-Agility Requirements for Remote 1551 Authentication Dial-In User Service (RADIUS)", RFC 6421, 1552 November 2011. 1554 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1555 "Tunnel Extensible Authentication Protocol (TEAP) Version 1556 1", RFC 7170, May 2014. 1558 [dead-realm] 1559 Tomasek, J., "Dead-realm marking feature for Radiator 1560 RADIUS servers", 2006, 1561 . 1563 [dot1X-standard] 1564 IEEE, "IEEE std 802.1X-2010", February 2010, 1565 . 1568 [edupki] Delivery of Advanced Network Technology to Europe, 1569 "eduPKI", 2012, . 1572 [eduroam-cat] 1573 Delivery of Advanced Network Technology to Europe, 1574 "eduroam CAT", 2012, . 1576 [eduroam-compliance] 1577 Trans-European Research and Education Networking 1578 Association, "eduroam compliance statement", 2011, 1579 . 1582 [eduroam-homepage] 1583 Trans-European Research and Education Networking 1584 Association, "eduroam Homepage", 2007, 1585 . 1587 [eduroam-policy] 1588 Delivery of Advanced Network Technology to Europe, 1589 "European Confederation eduroam policy", 2011, 1590 . 1593 [eduroam-service-definition] 1594 Delivery of Advanced Network Technology to Europe, 1595 "European eduroam policy Service Definition", 2011, 1596 . 1599 [eduroam-start] 1600 Wierenga, K., "Initial proposal for what is now called 1601 eduroam", 2002, . 1604 [geant2] Delivery of Advanced Network Technology to Europe, 1605 "European Commission Information Society and Media: 1606 GEANT2", 2008, . 1608 [nrenroaming-select] 1609 Trans-European Research and Education Networking 1610 Association, "Preliminary selection for inter-NREN 1611 roaming", 2003, . 1614 [radsec-whitepaper] 1615 Open System Consultants, "RadSec - a secure, reliable 1616 RADIUS Protocol", May 2005, 1617 . 1619 [radsecproxy-impl] 1620 Venaas, S., "radsecproxy Project Homepage", 2007, 1621 . 1623 [terena] TERENA, "Trans-European Research and Education Networking 1624 Association", 2008, . 1626 Appendix A. Acknowledgments 1628 The authors would like to thank the participants in the TERENA Task 1629 Force on Mobility and Network Middleware as well as the Geant project 1630 for their reviews and contributions. Special thanks go to Jim Schaad 1631 for doing an excellent review of the first version. 1633 The eduroam trademark is registered by TERENA. 1635 Appendix B. Changes 1637 This section to be removed prior to publication. 1639 o 00 Initial Revision 1640 o 01 Added Dynamic Discovery, addressed review comments 1642 o 02 Cosmetic changes 1644 o 03 Even More Cosmetic Changes 1646 o 04 Included review comments from Jim Schaad 1648 Authors' Addresses 1650 Klaas Wierenga 1651 Cisco Systems 1652 Haarlerbergweg 13-19 1653 Amsterdam 1101 CH 1654 The Netherlands 1656 Phone: +31 20 357 1752 1657 Email: klaas@cisco.com 1659 Stefan Winter 1660 Fondation RESTENA 1661 6, rue Richard Coudenhove-Kalergi 1662 Luxembourg 1359 1663 Luxembourg 1665 Phone: +352 424409 1 1666 Fax: +352 422473 1667 Email: stefan.winter@restena.lu 1668 URI: http://www.restena.lu. 1670 Tomasz Wolniewicz 1671 Nicolaus Copernicus University 1672 pl. Rapackiego 1 1673 Torun 1674 Poland 1676 Phone: +48-56-611-2750 1677 Fax: +48-56-622-1850 1678 Email: twoln@umk.pl 1679 URI: http://www.home.umk.pl/~twoln/