GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7593

Independent Submission K. Wierenga Request for Comments: 7593 Cisco Systems Category: Informational S. Winter ISSN: 2070-1721 RESTENA

                                                         T. Wolniewicz
                                        Nicolaus Copernicus University
                                                        September 2015
            The eduroam Architecture for Network Roaming

Abstract

 This document describes the architecture of the eduroam service for
 federated (wireless) network access in academia.  The combination of
 IEEE 802.1X, the Extensible Authentication Protocol (EAP), and RADIUS
 that is used in eduroam provides a secure, scalable, and deployable
 service for roaming network access.  The successful deployment of
 eduroam over the last decade in the educational sector may serve as
 an example for other sectors, hence this document.  In particular,
 the initial architectural choices and selection of standards are
 described, along with the changes that were prompted by operational
 experience.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This is a contribution to the RFC Series, independently of any other
 RFC stream.  The RFC Editor has chosen to publish this document at
 its discretion and makes no statement about its value for
 implementation or deployment.  Documents approved for publication by
 the RFC Editor are not a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7593.

Wierenga, et al. Informational [Page 1] RFC 7593 eduroam September 2015

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) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to 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

Wierenga, et al. Informational [Page 2] RFC 7593 eduroam September 2015

   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  . . . . . . . . . . . . . . . . . . . . . . .  37

1. Introduction

 In 2002, the European Research and Education community set out to
 create a network roaming service for students and employees in
 academia [eduroam-start].  Now, over 10 years later, this service has
 grown to more than 10,000 service locations, serving millions of
 users on all continents with the exception of Antarctica.
 This memo serves to explain the considerations for the design of
 eduroam as well as to document operational experience and resulting
 changes that led to IETF specifications such as RADIUS over TCP
 [RFC6613] and RADIUS with TLS [RFC6614] and that promoted alternative
 uses of RADIUS like in Application Bridging for Federated Access
 Beyond web (ABFAB) [ABFAB-ARCH].  Whereas the eduroam service is
 limited to academia, the eduroam architecture can easily be reused in
 other environments.
 First, this memo describes the original architecture of eduroam
 [eduroam-homepage].  Then, a number of operational problems are
 presented that surfaced when eduroam gained wide-scale deployment.
 Lastly, enhancements to the eduroam architecture that mitigate the
 aforementioned issues are discussed.

1.1. Terminology

 This document uses identity management and privacy terminology from
 [RFC6973].  In particular, this document uses the terms "Identity
 Provider", "Service Provider", and "identity management".

Wierenga, et al. Informational [Page 3] RFC 7593 eduroam September 2015

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 interpreted as described in RFC 2119 [RFC2119].
 Note: Also, the policy to which eduroam participants subscribe
 expresses the requirements for participation in RFC 2119 language.

1.3. Design Goals

 The guiding design considerations for eduroam were as follows:
  1. Unique identification of users at the edge of the network
    The access Service Provider (SP) needs to be able to determine
    whether a user is authorized to use the network resources.
    Furthermore, in case of abuse of the resources, there is a
    requirement to be able to identify the user uniquely (with the
    cooperation of the user's Identity Provider (IdP) operator).
  1. Enable (trusted) guest use
    In order to enable roaming, it should be possible for users of
    participating institutions 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 indeed
    widely used in eduroam.
  1. Scalable
    The infrastructure that is created should scale to a large number
    of users and organizations without requiring a lot of coordination
    and other administrative procedures (possibly with the exception
    of an initial setup).  Specifically, it should not be necessary
    for a user that visits another organization to go through an
    administrative process.
  1. Easy to install and use
    It should be easy for both organizations and users to participate
    in the roaming infrastructure; otherwise, it may inhibit wide-
    scale adoption.  In particular, there should be no client
    installation (or it should be easy) and only one-time
    configuration.

Wierenga, et al. Informational [Page 4] RFC 7593 eduroam September 2015

  1. Secure
    An important design criterion has been that there needs to be a
    security association between the end user and their Identity
    Provider, eliminating the possibility of credential theft.  The
    minimal requirements for security are specified in the eduroam
    policy and subject to change over time.  As an additional
    protection against user errors and negligence, it should be
    possible for participating Identity Providers to add their own
    requirements for the quality of authentication of their own users
    without the need for the infrastructure as a whole to implement
    the same requirements.
  1. Privacy preserving
    The design of the system should provide for user anonymization,
    i.e., a possibility to hide the user's identity from any third
    parties, including Service Providers.
  1. Standards based
    In an infrastructure in which many thousands of organizations
    participate, it is obvious that it should be possible to use
    equipment from different vendors; therefore, it is important to
    build the infrastructure using open standards.

1.4. Solutions That Were Considered

 Three architectures were trialed: one based on the use of 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 latter being the basis of what is now the eduroam
 architecture.  An overview of the candidate architectures and their
 relative merits can be found in [nrenroaming-select].
 The chosen architecture is based on:
 o  IEEE 802.1X [IEEE.802.1X] as the port-based authentication
    framework using
 o  EAP [RFC3748] for integrity-protected and confidential transport
    of credentials and
 o  a RADIUS [RFC2865] hierarchy as the trust fabric.

Wierenga, et al. Informational [Page 5] RFC 7593 eduroam September 2015

2. Classic Architecture

 Federations, like eduroam, implement essentially two types of direct
 trust relations (and one indirect).  The trust relation between an
 end user and the IdP (operated by the home organization of the user)
 and between the IdP and the SP (in eduroam, the operator of the
 network at the visited location).  In eduroam, the trust relation
 between the user and IdP is through mutual authentication.  IdPs and
 the SP establish trust through the use of a RADIUS hierarchy.
 These two forms of trust relations in turn provide the transitive
 trust relation that makes the SP trust the user to use its network
 resources.

2.1. Authentication

 Authentication in eduroam is achieved by using a combination of IEEE
 802.1X [IEEE.802.1X] and EAP [RFC4372] (the latter carried over
 RADIUS for guest access; see Section 2.2).

2.1.1. IEEE 802.1X

 By using the IEEE 802.1X [IEEE.802.1X] framework for port-based
 network authentication, organizations that offer network access (SPs)
 for visiting (and local) eduroam users can make sure that only
 authorized users get access.  The user (or rather the user's
 supplicant) sends an access request to the authenticator (Wi-Fi
 Access Point or switch) at the SP, the authenticator forwards the
 access request to the authentication server of the SP, that in turn
 proxies the request 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 a part of the local
 network of each SP; therefore, it is out of scope for this document.
 For completeness, it should be stated that 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 be aware of the availability of the eduroam
 service, an SP that offers wireless network access MUST broadcast the
 Service Set Identifier (SSID) 'eduroam', unless that conflicts with
 the SSID of another eduroam SP, in which case, an SSID starting with
 "eduroam-" MAY be used.  The downside of the latter is that clients
 will not automatically connect to that SSID, thus losing the seamless
 connection experience.

Wierenga, et al. Informational [Page 6] RFC 7593 eduroam September 2015

 Note: A direct implication of the common eduroam SSID is that the
 users cannot distinguish between a connection to the 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 be 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 use of the Extensible Authentication Protocol (EAP) [RFC4372]
 serves two purposes.  In the first place, a properly chosen EAP
 method allows for integrity-protected and confidential transport of
 the user credentials to the home organization.  Secondly, by having
 all RADIUS servers transparently proxy access requests, regardless of
 the EAP method inside the RADIUS packet, the choice of EAP method is
 between the 'home' organization of the user and the user.  In other
 words, in principle, every authentication form that can be carried
 inside EAP can be used in eduroam, as long as they adhere to minimal
 requirements as set forth in the eduroam Policy Service Definition
 [eduroam-service-definition].

Wierenga, et al. Informational [Page 7] RFC 7593 eduroam September 2015

                             +-----+
                            /       \
                           /         \
                          /           \
                         /             \
        ,----------\    |               |   ,---------\
        |    SP    |    |    eduroam    |   |    IdP  |
        |          +----+  trust fabric +---+         |
        `------+---'    |               |   '-----+---'
               |        |               |         |
               |         \             /          |
               |          \           /           |
               |           \         /            |
               |            \       /             |
          +----+             +-----+              +----+
          |                                            |
          |                                            |
      +---+--+                                      +--+---+
      |      |                                      |      |
    +-+------+-+    ___________________________     |      |
    |          |   O__________________________ )    +------+
    +----------+
    Host (supplicant)      EAP tunnel       Authentication server
                        Figure 1: Tunneled EAP
 Proxying 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.  In order to
 preserve credential protection, participating organizations MUST
 deploy EAP methods that provide mutual authentication.  For EAP
 methods that support outer identity, anonymous outer identities are
 recommended.  Most commonly used in eduroam are the so-called
 tunneled EAP methods that first create a server-authenticated TLS
 [RFC5246] tunnel through which the user credentials are transmitted.
 As depicted in Figure 1, the use of 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 based on RADIUS.  RADIUS trust
 is based on shared secrets between RADIUS peers.  In eduroam, any
 RADIUS message originating from a trusted peer is implicitly assumed
 to originate from a member of the roaming consortium.

Wierenga, et al. Informational [Page 8] RFC 7593 eduroam September 2015

 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 consists of a proxy hierarchy of RADIUS
 servers (organizational, national, global) that is loosely based on
 the DNS hierarchy.  That is, typically an organizational RADIUS
 server agrees on a shared secret with a national server, and the
 national server in turn agrees on a shared secret with the root
 server.  Access requests are routed through a chain of RADIUS proxies
 towards the Identity Provider of the user, 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 that is
 described below requires, in reality, several round-trips.

Wierenga, et al. Informational [Page 9] RFC 7593 eduroam September 2015

                                +-------+
                                |       |
                                |   .   |
                                |       |
                                +---+---+
                                  / | \
                +----------------/  |  \---------------------+
                |                   |                        |
                |                   |                        |
                |                   |                        |
             +--+---+            +--+--+                +----+---+
             |      |            |     |                |        |
             | .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 Hierarchy
 Routing of access requests to the home IdP is done 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 gain wireless
 network access at the University of Tennessee at Knoxville (utk.edu)
 the following happens:
 o  Paul's supplicant transmits an EAP access request to the Access
    Point (Authenticator) at UTK with outer identity of
    anonymous@surfnet.nl.

Wierenga, et al. Informational [Page 10] RFC 7593 eduroam September 2015

 o  The Access Point forwards the EAP message to its Authentication
    Server (the UTK RADIUS server).
 o  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.
 o  The .edu RADIUS server verifies the realm; since it is not in a
    .edu subdomain, it proxies the request to the root server.
 o  The root RADIUS server proxies the request to the .nl RADIUS
    server, since the ".nl" domain is known to the root server.
 o  The .nl RADIUS server proxies the request to the surfnet.nl
    server, since it knows the SURFnet server.
 o  The surfnet.nl RADIUS server decapsulates the EAP message and
    verifies the user credentials, since the user is known to SURFnet.
 o  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 through the RADIUS hierarchy in
    reverse order.
 o  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.

3. Issues with Initial Trust Fabric

 While the hierarchical RADIUS architecture described in the previous
 section has served as the basis for eduroam operations for an entire
 decade, the exponential growth of authentications is expected to lead
 to, and has in fact in some cases already led to, performance and
 operations bottlenecks on the aggregation proxies.  The following
 sections describe some of the shortcomings and the resulting
 remedies.

Wierenga, et al. Informational [Page 11] RFC 7593 eduroam September 2015

3.1. Server Failure Handling

 In eduroam, authentication requests for roaming users are statically
 routed through preconfigured proxies.  The number of proxies varies:
 in a national roaming case, the number of proxies is typically 1 or 2
 (some countries deploy regional proxies, which are in turn aggregated
 by a national proxy); in international roaming, 3 or 4 proxy servers
 are typically involved (the number may be higher along some routes).
 RFC 2865 [RFC2865] does not define a failover algorithm.  In
 particular, the failure of a server needs to be deduced from the
 absence of a reply.  Operational experience has shown that this has
 detrimental effects on the infrastructure and end-user experience:
 1.  Authentication failure: the first user whose authentication path
     is along a newly failed server will experience a long delay and
     possibly timeout
 2.  Wrongly deduced states: since the proxy chain is longer than one
     hop, a failure further along in the authentication path is
     indistinguishable from a failure in the next hop.
 3.  Inability to determine recovery of a server: only a "live"
     authentication request sent to a server that is believed to be
     inoperable can lead to the discovery that the server is in
     working order again.  This issue has been resolved with RFC 5997
     [RFC5997].
 The second point can have significant impact on the operational state
 of the system in a worst-case scenario: imagine one realm's home
 server being inoperable.  A user from that realm is trying to roam
 internationally and tries to authenticate.  The RADIUS server on 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 proxy national server is down.
 None of these assumptions are true.  Worse yet: in case of failover
 to a back-up next-hop RADIUS server, also that server will be marked
 as being defunct, since through that server 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 being 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 RFC 5997 [RFC5997] and

Wierenga, et al. Informational [Page 12] RFC 7593 eduroam September 2015

 cautious failover parameters make false "downs" unlikely to happen,
 as long as every hop implements RFC 5997.  In that case, dead realm
 detection serves mainly to prevent proxying of 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 of extended failure reasons
 to the end user's device.  For eduroam, this creates two issues:
 o  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 the
    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:
    1.  Do Not Reply: The inability to reach a conclusion can be
        handled by not replying to the request.  The upside of this
        approach 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.
    2.  Reply with Reject: In this option, the inability to reach a
        conclusion is treated like an authentication failure.  The
        upside of this approach 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 (e.g., 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; 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

Wierenga, et al. Informational [Page 13] RFC 7593 eduroam September 2015

 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
 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 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.

Wierenga, et al. Informational [Page 14] RFC 7593 eduroam September 2015

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 will add more bytes to the overall RADIUS
 payload size and in the end exceed 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].

Wierenga, et al. Informational [Page 15] RFC 7593 eduroam September 2015

3.5. Insufficient Payload Encryption and EAP Server Validation

 The RADIUS protocol's design foresaw only the encryption of select
 RADIUS attributes, most notably User-Password.  With EAP methods
 conforming to the requirements of [RFC4017], the user's credential is
 not transmitted using the User-Password attribute, and stronger
 encryption than the one for RADIUS User-Password is in use (typically
 TLS).
 Still, the use of EAP does not encrypt all personally identifiable
 details of the user session, as some are carried inside cleartext
 RADIUS attributes.  In particular, the user's device can be
 identified by inspecting the Calling-Station-ID attribute; and the
 user's location may be derived from observing NAS-IP-Address, NAS-
 Identifier, or Operator-Name attributes.  Since these attributes are
 not encrypted, even IP-layer third parties can harvest the
 corresponding data.  In a worst-case scenario, this enables the
 creation of mobility profiles.  Pervasive passive surveillance using
 this connection metadata such as the recently uncovered incidents in
 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.
 These profiles are not necessarily linkable to an actual user because
 EAP allows for the use of 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.  In
 particular, for EAP-TLS users, the use of EAP-TLS identity protection
 is not usually implemented and cannot be used.  In eduroam, concerned
 individuals and IdPs that use EAP-TLS are using pseudonymous client
 certificates to provide for 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 in user devices
 prior to their first connection attempt; this depends heavily on the
 remote configuration possibilities of the supplicants though.
 A further threat involves the verification of the EAP server's
 identity.  Even though the cryptographic foundation, TLS tunnels, is
 sound, there is a weakness in the supplicant configuration: many
 users do not understand or are not willing to invest time into the
 inspection of server certificates or the installation of a trusted
 certification authority (CA).  As a result, users may easily be

Wierenga, et al. Informational [Page 16] RFC 7593 eduroam September 2015

 tricked into connecting to an unauthorized EAP server, ultimately
 leading to a leak of their credentials 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 in user devices prior to 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 transport of 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 for third parties and could be
 added to the mobility profile.
 The only way to mitigate all information leakage to third parties is
 by protecting 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 that 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 the user authentication using IEEE 802.1X and EAP has
 remained unchanged (i.e., no need for end users to change any
 configurations), the issues as reported in Section 3 have resulted in

Wierenga, et al. Informational [Page 17] RFC 7593 eduroam September 2015

 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 as 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 intial version [RFC3588].  However,
 within the operational constraints of eduroam (listed below), no
 single combination of software could be found (and that is believed
 to still be true, more than ten years and one revision of Diameter
 [RFC6733] later).  The constraints are:
 o  reasonably cheap to deploy on many administrative domains
 o  supporting the application of Network Access Server Requirements
    (NASREQ)
 o  supporting EAP application
 o  supporting Diameter Redirect
 o  supporting validation of authentication requests of the most
    popular EAP types (EAP Tunneled Transport Layer Security
    (EAP-TTLS), Protected EAP (PEAP), and EAP-TLS)
 o  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 (and 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 -- 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].

Wierenga, et al. Informational [Page 18] RFC 7593 eduroam September 2015

 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:
 o  explicit peer reachability detection using long-lived TCP sessions
 o  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:
 1.  how to find the network address of a responsible RADIUS server
     for a given realm
 2.  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.

Wierenga, et al. Informational [Page 19] RFC 7593 eduroam September 2015

 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 Lookup
 From 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

 Any organization can put "x-eduroam" NAPTR entries into their Domain
 Name Server, pretending to be the eduroam Identity Provider for the
 corresponding realm.  Since eduroam is a service for a heterogeneous,
 but closed, user group, additional sources of information need to be
 consulted to verify that a realm with its discovered server is
 actually an eduroam participant.
 The eduroam consortium has chosen to deploy a separate PKI that
 issues certificates only to authorized eduroam Identity Providers and
 eduroam Service Providers.  Since certificates are needed for RADIUS/

Wierenga, et al. Informational [Page 20] RFC 7593 eduroam September 2015

 TLS anyway, it was a straightforward solution to reuse the PKI for
 that.  The PKI fabric allows multiple CAs as trust roots (overseen by
 a Policy Management Authority) and requires that certificates that
 were issued to verified eduroam participants are marked with
 corresponding "X509v3 Policy OID" fields; eduroam RADIUS servers and
 clients need to verify the existence of these OIDs in the incoming
 certificates.
 The policies and OIDs can be retrieved from the "eduPKI Trust Profile
 for eduroam Certificates" [eduPKI].

4.2.3. Operational Experience

 The discovery model is currently deployed in approximately 10
 countries that participate in eduroam, making more than 100 realms
 discoverable via their NAPTR records.  Experience has shown that the
 model works and scales as expected, the only drawback being that the
 additional burden of operating a PKI that is not local to the
 national eduroam administrators creates significant administrative
 complexities.  Also, the presence of multiple CAs and regular updates
 of Certificate Revocation Lists makes the operation of RADIUS servers
 more complex.

4.2.4. Possible Alternatives

 There are two alternatives to this approach to dynamic server
 discovery that are monitored by the eduroam community:
 1.  DNSSEC + DNS-Based Authentication of Named Entities (DANE) TLSA
     records
 2.  ABFAB Trust Router
 For DNSSEC+DANE TLSA, the biggest advantage is that the certificate
 data itself can be stored in the DNS -- possibly obsoleting the PKI
 infrastructure *if* a new place for the server authorization checks
 can be found.  Its most significant downside is that the DANE
 specifications only include client-to-server certificate checks,
 while RADIUS/TLS requires also server-to-client verification.
 For the ABFAB Trust Router, the biggest advantage is that it would
 work without certificates altogether (by negotiating TLS-PSK keys ad
 hoc).  The downside is that it is currently not formally specified
 and not as thoroughly understood as any of the other solutions.

Wierenga, et al. Informational [Page 21] RFC 7593 eduroam September 2015

5. Abuse Prevention and Incident Handling

 Since the eduroam service is a confederation of autonomous networks,
 there is little justification for transferring accounting information
 from the Service Provider to any other (in general) or to the
 Identity Provider of the user (in particular).  Accounting in eduroam
 is therefore considered to be a local matter of the Service Provider.
 The eduroam compliance statement [eduroam-compliance] in fact
 specifies that accounting traffic [RFC5280] SHOULD NOT be forwarded.
 The static routing infrastructure of eduroam acts as a filtering
 system blocking accounting traffic from misconfigured local RADIUS
 servers.  Proxy servers are configured to terminate accounting
 request traffic by answering to Accounting-Requests with an
 Accounting-Response in order to prevent the retransmission of
 orphaned Accounting-Request messages.  With dynamic discovery,
 Identity Providers that are discoverable via DNS will need to apply
 these filtering measures themselves.  This is an increase in
 complexity of the Identity Provider RADIUS configuration.
 Roaming creates accountability problems, as identified by [RFC4372]
 (Chargeable User Identity).  Since the NAS can only see the (likely
 anonymous) outer identity of the user, it is impossible to correlate
 usage with a specific user (who may use multiple devices).  A NAS
 that supports [RFC4372] can request the Chargeable-User-Identity and,
 if supplied by the authenticating RADIUS server in the Access-Accept
 message, add this value to corresponding Access-Request packets.
 While eduroam does not have any charging mechanisms, it may still be
 desirable to identify traffic originating from one particular user.
 One of the reasons is to prevent abuse of guest access by users
 living near university campuses.  Chargeable User Identity (see
 Section 5.3) supplies the perfect answer to this problem; however, at
 the time of writing, to our knowledge, only one hardware vendor (Meru
 Networks) implements RFC 4372 on their access points.  For all other
 vendors, requesting the Chargeable-User-Identity attribute needs to
 happen on the RADIUS server to which the access point is connected
 to.  FreeRADIUS supports this ability in the latest distribution, and
 Radiator can be retrofitted to do the same.

5.1. Incident Handling

 10 years of experience with eduroam have not exposed any serious
 incident.  This may be taken as evidence for proper security design
 as well as suggest that users' awareness that they are identifiable
 acts as an effective deterrent.  It could of course also mean that
 eduroam operations lack the proper tools or insight into the actual
 use and potential abuse of the service.  In any case, many of the

Wierenga, et al. Informational [Page 22] RFC 7593 eduroam September 2015

 attack vectors that exist in open networks or networks where access
 control is based on shared secrets are not present, arguably leading
 to a much more secure system.
 Below is a discussion of countermeasures that are taken in eduroam.
 The European eduroam Policy Service Definition
 [eduroam-service-definition], as an example, describes incident
 scenarios and actions to be taken; in this document, we present the
 relevant technical issues.
 The initial implementation has been lacking reliable tools for an SP
 to make its own decision or for an IdP to introduce a conditional
 rule applying only to a given SP.  The introduction of 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

 The first action in the case of an incident is to block the user's
 access to eduroam at the Service Provider.  Since the roaming user's
 true identity is likely hidden behind an anonymous/fake outer
 identity, the Service Provider can only rely on the realm of the user
 and his MAC address; if the Identity Provider has already sent a
 Chargeable-User-Identity (see Section 5.3 for details), then this
 extra information can be used to identify the user more reliably.
 A first attempt at the SP side may be to block based on the MAC
 address or outer identity.  This blocking can be executed before the
 EAP authentication occurs -- typically in the first datagram, acting
 on the RADIUS attributes EAP-Message/EAP-Response/Identity and
 Calling-Station-ID.  The datagram can either be dropped (supplicant
 notices a time-out) or replied to with a RADIUS Access-Reject
 containing an EAP-Failure.  Since malicious users can change both
 their MAC addresses and the local part of their outer identity
 between connection attempts, this first attempt is not sufficient to
 lock out a determined user.
 As a second measure, the SP can let the EAP authentication proceed as
 normal, and verify whether the final Access-Accept response from the
 RADIUS server contains a Chargeable-User-Identity (CUI).  If so, the
 SP RADIUS server can be configured to turn all future Access-Accepts
 for this CUI into an Access-Reject/EAP-Failure.  This measure is
 effective and efficient: it locks out exactly the one user that is
 supposed to be locked out, and it has no side-effects on other users,
 even from the same realm.

Wierenga, et al. Informational [Page 23] RFC 7593 eduroam September 2015

 If the EAP authentication does not reveal a CUI, the SP cannot
 reliably determine the user in question.  The only reliable
 information to act upon is then the realm portion of the outer
 identity of the user.  The SP will need to resort to blocking the
 entire realm that the offending user belongs to.  This is effective,
 but not efficient: it locks out the user in question, but has a DoS
 side-effect on all other visiting users from the same realm.
 In the absence of a CUI handle, SPs that are not willing to take the
 drastic step of blocking an entire realm will be forced to contact
 the Identity Provider in question and demand that the user be blocked
 at the IdP side.  This involves human interaction between SP and IdP
 and is not possible in real-time.

5.1.2. Blocking Users on the IdP Side

 The IdP has the power to disable a user account altogether, thus
 blocking this user from accessing eduroam in all sites.  If blocking
 the user is done due a request of an SP (as per the previous
 section), there may be a more fine-grained possibility to block
 access to a specific SP -- if the SP in question sends the Operator-
 Name attribute along with his Access-Requests (see Section 5.2 for
 details).
 If the IdP decides to block the user globally, this is typically done
 by treating the login attempt as if the credentials were wrong: the
 entire EAP conversation needs to be executed to the point where the
 true inner identity is revealed (before that, the IdP does not know
 yet which user is attempting to authenticate).  This typically
 coincides with the point in time where credentials are exchanged.
 Instead of, or in addition to, checking the credential for validity,
 the Identity Provider also checks whether the user's account is
 (still) eligible for eduroam use and will return an Access-Reject/
 EAP-Failure if not.
 There may well be cases where opinions between the SP desiring a user
 lockout and the IdP of the user differ.  For example, an SP might
 consider massive amounts of up-/downloads with file sharing protocols
 unacceptable as per local policy, and desire blocking of users that
 create too much traffic -- but the IdP does not take offense on such
 actions and would not want to lock his user out of eduroam globally
 because of this one SP's opinion.
 In the absence of the Operator-Name attribute, there is no way to
 apply a login restriction only for a given SP and not eduroam as a
 whole; eduroam eligibility is an all-or-nothing decision for the IdP.

Wierenga, et al. Informational [Page 24] RFC 7593 eduroam September 2015

 If the Operator-Name attribute is present, the IdP can use this
 information to fail the authentication attempt only if the attempt
 originated from SPs that desire such blocking.  Even though the
 Operator-Name attribute is available from the first RADIUS Access-
 Request datagram onwards, the EAP authentication needs to be carried
 out until the true inner identity is known just as in the global
 blocking case above.  The Operator-Name is simply an additional piece
 of information that the IdP can use to make its decision.

5.1.3. Communicating Account Blocking to the End User

 The measures described in Sections 5.1.1 and 5.1.2 alter the EAP
 conversation.  They either create a premature rejection or timeout at
 the start of the conversation or change the outcome of the
 authentication attempt at the very end of the conversation.
 On the supplicant side, these alterations are indistinguishable from
 an infrastructure failure: a premature rejection or timeout could be
 due to a RADIUS server being unresponsive, and a rejection at the end
 of the conversation could be either user error (wrong password) or
 server error (credential lookup failed).  For the supplicant, it is
 thus difficult to communicate a meaningful error to the user.  The
 newly specified EAP type TEAP, Tunnel Extensible Authentication
 Protocol [RFC7170], has a means to transport fine-grained error
 reason codes to the supplicant; this has the potential to improve the
 situation in the future.
 The EAP protocol foresees one mechanism to provide such user-
 interactive communication: the EAP state machine contains states that
 allow user-visible communication.  An extra round of EAP-Request/
 Notification and the corresponding acknowledgement can be injected
 before the final EAP-Failure.
 However, anecdotal evidence suggests that supplicants typically do
 not implement this part of the EAP state machine at all.  One
 supplicant is reported to support it, but only logs the contents of
 the notification in a log file -- which is not at all helpful for the
 end user.
 The discovery of reasons and scope of account blocking are thus left
 as an out-of-band action.  The eduroam user support process requires
 that users with authentication problems contact their Identity
 Provider as a first measure (via unspecified means, e.g., they could
 phone their IdP or send an email via a 3G backup link).  If the
 Identity Provider is the one that blocked their access, the user will
 immediately be informed by them.  If the reason for blocking is at
 the SP side, the Identity Provider will instead inform the user that

Wierenga, et al. Informational [Page 25] RFC 7593 eduroam September 2015

 the account is in working order and that the user needs to contact
 the SP IT support to get further insight.  In that case, that SP-side
 IT support will notify the users about the reasons for blocking.

5.2. Operator Name

 The Operator-Name attribute is defined in [RFC5580] as a means of
 unique identification of the access site.
 The Proxy infrastructure of eduroam makes it impossible for home
 sites to tell where their users roam.  While this may be seen as a
 positive aspect enhancing user's privacy, it also makes user support,
 roaming statistics, and blocking offending user's access to eduroam
 significantly harder.
 Sites participating in eduroam are encouraged to add the Operator-
 Name attribute using the REALM namespace, i.e., sending a realm name
 under control of the given site.
 The introduction of Operator-Name in eduroam has led to the
 identification of one operational problem -- the identifier 126
 assigned to this attribute has been previously used by some vendors
 for their specific purposes and has been included in attribute
 dictionaries of several RADIUS server distributions.  Since the
 syntax of this hijacked attribute had been set to Integer, this
 introduces a syntax clash with the RFC definition (which defines it
 as Text).  Operational tests in eduroam have shown that servers using
 the Integer syntax for attribute 126 may either truncate the value to
 4 octets or even drop the entire RADIUS packet (thus making
 authentication impossible).  The eduroam monitoring and eduroam test
 tools try to locate problematic sites.  Section 2.8 of [RFC6929]
 clarifies the handling of these packets.
 When a Service Provider sends its Operator-Name value, it creates a
 possibility for the home sites to set up conditional blocking rules,
 depriving certain users of access to selected sites.  Such action
 will cause much less concern than blocking users from all of eduroam.
 In eduroam, the Operator Name is also used for the generation of
 Chargeable User Identity values.
 The addition of Operator-Name is a straightforward configuration of
 the RADIUS server and may be easily introduced on a large scale.

Wierenga, et al. Informational [Page 26] RFC 7593 eduroam September 2015

5.3. Chargeable User Identity

 The Chargeable-User-Identity (CUI) attribute is defined by RFC 4372
 [RFC4372] as an answer to accounting problems caused by the use of
 anonymous identity in some EAP methods.  In eduroam, the primary use
 of CUI is in incident handling, but it can also enhance local
 accounting.
 The eduroam policy requires that a given user's CUI generated for
 requests originating from different sites should be different (to
 prevent collusion attacks).  The eduroam policy thus mandates that a
 CUI request be accompanied by the Operator-Name attribute, which is
 used as one of the inputs for the CUI generation algorithm.  The
 Operator-Name requirement is considered to be the "business
 requirement" described in Section 2.1 of RFC 4372 [RFC4372] and hence
 conforms to the RFC.
 When eduroam started considering using CUI, there were no NAS
 implementations; therefore, the only solution was moving all CUI
 support to the RADIUS server.
 CUI request generation requires only the addition of NUL CUI
 attributes to outgoing Access-Requests; however, the real strength of
 CUI comes with accounting.  Implementation of CUI-based accounting in
 the server requires that the authentication and accounting RADIUS
 servers used directly by the NAS are actually the same or at least
 have access to a common source of information.  Upon processing of an
 Access-Accept, the authenticating RADIUS server must store the
 received CUI value together with the device's Calling-Station-Id in a
 temporary database.  Upon receipt of an Accounting-Request, the
 server needs to update the packet with the CUI value read from the
 database.
 A wide introduction of CUI support in eduroam will significantly
 simplify incident handling at Service Providers.  Introducing local,
 per-user access restriction will be possible.  Visited sites will
 also be able to notify the home site about the introduction of such a
 restriction, pointing to the CUI value and thus making it possible
 for the home site to identify the user.  When the user reports the
 problem at his home support, the reason will be already known.

Wierenga, et al. Informational [Page 27] RFC 7593 eduroam September 2015

6. Privacy Considerations

 The eduroam architecture has been designed with protection of user
 credentials in mind, as may be clear from reading this far.  However,
 operational experience has revealed some more subtle points with
 regards to privacy.

6.1. Collusion of Service Providers

 If users use anonymous outer identities, SPs cannot easily collude by
 linking outer identities to users that are visiting their campus.
 However, this poses problems with remediation of abuse or
 misconfiguration.  It is impossible to find the user that exhibits
 unwanted behaviour or whose system has been compromised.
 For that reason, the Chargeable-User-Identity has been introduced in
 eduroam, constructed so that only the IdP of the user can uniquely
 identify the user.  In order to prevent collusion attacks, that CUI
 is required to be unique per user and per Service Provider.

6.2. Exposing User Credentials

 Through the use of EAP, user credentials are not visible to anyone
 but the IdP of the user.  That is, if a sufficiently secure EAP
 method is chosen and EAP is not terminated prematurely.
 There is one privacy sensitive user attribute that is necessarily
 exposed to third parties and that is the realm the user belongs to.
 Routing in eduroam is based on the realm part of the user identifier,
 so even though the outer identity in a tunneled EAP method may be set
 to an anonymous identifier, it MUST contain the realm of the user,
 and may thus lead to identifying the user if the realm in question
 contains few users.  This is considered a reasonable trade-off
 between user privacy and usability.

6.3. Track Location of Users

 Due to the fact that access requests (potentially) travel through a
 number of proxy RADIUS servers, the home IdP of the user typically
 cannot tell where a user roams.
 However, the introduction of Operator-Name and dynamic lookups (i.e.,
 direct connections between IdP and SP) gives the home IdP insight
 into the location of the user.

Wierenga, et al. Informational [Page 28] RFC 7593 eduroam September 2015

7. Security Considerations

 This section addresses only security considerations associated with
 the use of eduroam.  For considerations relating to IEEE 802.1X,
 RADIUS, and EAP in general, the reader is referred to the respective
 specification and to other literature.

7.1. Man-in-the-Middle and Tunneling Attacks

 The security of user credentials in eduroam ultimately lies within
 the EAP server verification during the EAP conversation.  Therefore,
 the eduroam policy mandates that only EAP types capable of mutual
 authentication are allowed in the infrastructure, and requires that
 IdPs publish all information that is required to uniquely identify
 the server (i.e., usually the EAP server's CA certificate and its
 Common Name or subjectAltName:dNSName).
 While in principle this makes man-in-the-middle attacks impossible,
 in practice several attack vectors exist nonetheless.  Most of these
 deficiencies are due to implementation shortcomings in EAP
 supplicants.  Examples:

7.1.1. Verification of Server Name Not Supported

 Some supplicants only allow specifying which CA issues the EAP server
 certificate; its name is not checked.  As a result, any entity that
 is able to get a server certificate from the same CA can create its
 own EAP server and trick the end user to submit his credentials to
 that fake server.
 As a mitigation to that problem, eduroam Operations suggests the use
 of a private CA that exclusively issues certificates to the
 organization's EAP servers.  In that case, no other entity will get a
 certificate from the CA and this supplicant shortcoming does not
 present a security threat any more.

7.1.2. Neither Specification of CA nor Server Name Checks during

      Bootstrap
 Some supplicants allow for insecure bootstrapping in that they allow
 the simple selection of a network the acceptance of the incoming
 server certificate, identified by its fingerprint.  The certificate
 is then saved as trusted for later reconnection attempts.  If users
 are near a fake hotspot during initial provisioning, they may be
 tricked to submit their credentials to a fake server; furthermore,
 they will be branded to trust only that fake server in the future.

Wierenga, et al. Informational [Page 29] RFC 7593 eduroam September 2015

 eduroam Identity Providers are advised to provide their users with
 complete documentation for setup of their supplicants without the
 shortcut of insecure bootstrapping.  In addition, eduroam Operations
 has created a tool that makes correct, complete, and secure settings
 on many supplicants: eduroam CAT [eduroam-CAT].

7.1.3. User Does Not Configure CA or Server Name Checks

 Unless automatic provisioning tools such as eduroam CAT are used, it
 is cumbersome for users to initially configure an EAP supplicant
 securely.  User interfaces of supplicants often invite the users to
 take shortcuts ("Don't check server certificate") that are easier to
 set up or hide important security settings in badly accessible sub-
 menus.  Such shortcuts or security parameter omissions make the user
 subject to man-in-the-middle attacks.
 eduroam IdPs are advised to educate their users regarding the
 necessary steps towards a secure setup. 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

 There is no link between the EAP outer ("anonymous") identity and the
 EAP inner ("real") identity.  In particular, they can both contain a
 realm name, and the realms need not be identical.  It is possible to
 craft packets with an outer identity of user@RealmB, and an inner
 identity of user@realmA.  With the eduroam request routing, a Service
 Provider would assume that the user is from realmB and send the
 request there.  The server at realmB inspects the inner user name,
 and if proxying is not explicitly disabled for tunneled request
 content, may decide to send the tunneled EAP payload to realmA, where
 the user authenticates.  A CUI value would likely be generated by the
 server at realmB, even though this is not its user.
 Users can craft such packets to make their identification harder;
 usually, the eduroam SP would assume that the troublesome user
 originates from realmB and demand there that the user be blocked.
 However, the operator of realmB has no control over the user and can
 only trace back the user to his 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.

Wierenga, et al. Informational [Page 30] RFC 7593 eduroam September 2015

7.2. Denial-of-Service Attacks

 Since eduroam's roaming infrastructure is based on IP and RADIUS, it
 suffers from the usual DoS attack vectors that apply to these
 protocols.
 The eduroam hotspots are susceptible to typical attacks on edge
 networks, such as rogue Router Advertisements (RAs), rogue DHCP
 servers, and others.  Notably, eduroam hotspots are more robust
 against malign users' DHCP pool exhaustion than typical open or
 "captive portal" hotspots, because a DHCP address is only leased
 after a successful authentication, thereby reducing the pool of
 possible attackers to eduroam account holders (as opposed to the
 general public).  Furthermore, attacks involving ARP spoofing or ARP
 flooding are also reduced to authenticated users, because an attacker
 needs to be in possession of a valid WPA2 session key to be able to
 send traffic on the network.
 This section does not discuss 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 that are reachable on the Internet
 because triggering authentication traffic can only be done when
 physically in proximity of an eduroam hotspot (be it a wired socket
 that is IEEE 802.1X enabled or a Wi-Fi Access Point).
 However, when in the vicinity, an attacker can easily craft
 authentication attempts that traverse the entire international
 eduroam infrastructure; an attacker merely needs to choose a realm
 from another world region than his physical location to trigger
 Access-Requests that need to be processed by the SP, then SP-side
 national, then world region, then target world region, then target
 national, then target IdP server.  So long as the realm actually
 exists, this will be followed by an entire EAP conversation on that
 path.  Not having actual credentials, the request will ultimately be
 rejected, but it consumed processing power and bandwidth across the
 entire infrastructure, possibly affecting all international
 authentication traffic.
 EAP is a lock-step protocol.  A single attacker at an eduroam hotspot
 can only execute one EAP conversation after another and is thus rate-
 limited by round-trip times of the RADIUS chain.

Wierenga, et al. Informational [Page 31] RFC 7593 eduroam September 2015

 Currently, eduroam processes several hundred thousands of 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 induced by
 EAP's lock-step nature, it requires a significant amount 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, as
 authentications will then not traverse all infrastructure servers,
 removing the world-region aggregation servers as obvious bottlenecks.
 Any attack would then be limited between an SP and IdP directly.

7.2.2. DoS as a Side-Effect of Expired Credentials

 In eduroam Operations, it is observed that a significant portion of
 (failed) eduroam authentications is due to user accounts that were
 once valid but have in the meantime been de-provisioned (e.g., if a
 student has left the university after graduation).  Configured
 eduroam accounts are often retained on the user devices, and when in
 the vicinity of an eduroam hotspot, the user device's operating
 system will attempt to connect to this network.
 As operation of eduroam continues, the amount of devices with
 leftover configurations is growing, effectively creating a pool of
 devices that produce unwanted network traffic whenever they can.
 Until recently, this problem did not emerge with much prominence,
 because there is also a natural shrinking of that pool of devices due
 to users finally decommissioning their old computing hardware.
 Recently, smartphones are programmed to make use of cloud storage and
 online backup mechanisms that save most, or all, configuration
 details of the device with a third party.  When renewing their
 personal computing hardware, users can restore the old settings onto
 the new device.  It has been observed that expired eduroam accounts
 can survive perpetually on user devices that way.  If this trend
 continues, it can be pictured that an always-growing pool of devices
 will clog up eduroam infrastructure with doomed-to-fail
 authentication requests.

Wierenga, et al. Informational [Page 32] RFC 7593 eduroam September 2015

 There is not currently a useful remedy to this problem, other than
 instructing users to manually delete their configuration in due time.
 Possible approaches to this problem are:
 o  Creating a culture of device provisioning where the provisioning
    profile contains a "ValidUntil" property, after which the
    configuration needs to be re-validated or disabled.  This requires
    a data format for provisioning as well as implementation support.
 o  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>.

Wierenga, et al. Informational [Page 33] RFC 7593 eduroam September 2015

 [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

 [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.

Wierenga, et al. Informational [Page 34] RFC 7593 eduroam September 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>.

Wierenga, et al. Informational [Page 35] RFC 7593 eduroam September 2015

 [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 would like to thank the participants in the Geant
 Association Task Force on Mobility and Network Middleware as well as
 the Geant project for their reviews and contributions.  Special
 thanks go to Jim Schaad for doing an excellent review of the first
 version and to him and Alan DeKok for additional reviews.
 The eduroam trademark is registered by TERENA.

Wierenga, et al. Informational [Page 36] RFC 7593 eduroam September 2015

Authors' Addresses

 Klaas Wierenga
 Cisco Systems
 Haarlerbergweg 13-17
 Amsterdam  1101 CH
 The Netherlands
 Phone: +31 20 357 1752
 Email: klaas@cisco.com
 Stefan 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/

Wierenga, et al. Informational [Page 37]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7593.txt · Last modified: 2015/09/25 23:13 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki