The eduroam Architecture for Network Roaming
RFC 7593
Document | Type |
RFC - Informational
(September 2015; Errata)
Was draft-wierenga-ietf-eduroam (individual)
|
|
---|---|---|---|
Last updated | 2017-03-15 | ||
Stream | ISE | ||
Formats | plain text pdf html bibtex | ||
IETF conflict review | conflict-review-wierenga-ietf-eduroam | ||
Stream | ISE state | Published RFC | |
Consensus Boilerplate | Unknown | ||
Document shepherd | Adrian Farrel | ||
Shepherd write-up | Show (last changed 2015-06-21) | ||
IESG | IESG state | RFC 7593 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) | ||
IANA | IANA review state | IANA OK - No Actions Needed | |
IANA action state | No IANA Actions |
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 . . . . . . . . . . . . . . . . 28Show full document text