tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7593

 
 
 

The eduroam Architecture for Network Roaming

Part 2 of 2, p. 22 to 37
Prev RFC Part

 


prevText      Top      Up      ToC       Page 22 
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

Top      Up      ToC       Page 23 
   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.

Top      Up      ToC       Page 24 
   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.

Top      Up      ToC       Page 25 
   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

Top      Up      ToC       Page 26 
   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.

Top      Up      ToC       Page 27 
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.

Top      Up      ToC       Page 28 
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.

Top      Up      ToC       Page 29 
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.

Top      Up      ToC       Page 30 
   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.

Top      Up      ToC       Page 31 
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.

Top      Up      ToC       Page 32 
   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.

Top      Up      ToC       Page 33 
   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>.

Top      Up      ToC       Page 34 
   [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.

Top      Up      ToC       Page 35 
   [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>.

Top      Up      ToC       Page 36 
   [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.

Top      Up      ToC       Page 37 
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/